Network Working Group Y. Rekhter, Ed.
Request for Comments: 4271 T. Li, Ed.
Obsoletes: 1771 S. Hares, Ed.
Category: Standards Track January 2006
Network Working Group Y. Rekhter, Ed.
Request for Comments: 4271 T. Li, Ed.
Obsoletes: 1771 S. Hares, Ed.
Category: Standards Track January 2006
A Border Gateway Protocol 4 (BGP-4)
边界网关协议4（BGP-4）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.
本文讨论边界网关协议（BGP），它是一种自治系统间路由协议。
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.
BGP语音系统的主要功能是与其他BGP系统交换网络可达性信息。该网络可达性信息包括可达性信息所遍历的自治系统（ASE）列表上的信息。这些信息足以为这种可达性构建AS连接图，从中可以修剪路由循环，并且在AS级别，可以强制执行一些策略决策。
BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.
BGP-4提供了一组支持无类域间路由（CIDR）的机制。这些机制包括支持将一组目的地作为IP前缀进行广告，并消除BGP中网络“类”的概念。BGP-4还引入了允许路由聚合的机制，包括AS路径聚合。
This document obsoletes RFC 1771.
本文件废除了RFC 1771。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Definition of Commonly Used Terms ..........................4
1.2. Specification of Requirements ..............................6
2. Acknowledgements ................................................6
3. Summary of Operation ............................................7
3.1. Routes: Advertisement and Storage ..........................9
3.2. Routing Information Base ..................................10
4. Message Formats ................................................11
4.1. Message Header Format .....................................12
4.2. OPEN Message Format .......................................13
4.3. UPDATE Message Format .....................................14
4.4. KEEPALIVE Message Format ..................................21
4.5. NOTIFICATION Message Format ...............................21
5. Path Attributes ................................................23
5.1. Path Attribute Usage ......................................25
5.1.1. ORIGIN .............................................25
5.1.2. AS_PATH ............................................25
5.1.3. NEXT_HOP ...........................................26
5.1.4. MULTI_EXIT_DISC ....................................28
5.1.5. LOCAL_PREF .........................................29
5.1.6. ATOMIC_AGGREGATE ...................................29
5.1.7. AGGREGATOR .........................................30
6. BGP Error Handling. ............................................30
6.1. Message Header Error Handling .............................31
6.2. OPEN Message Error Handling ...............................31
6.3. UPDATE Message Error Handling .............................32
6.4. NOTIFICATION Message Error Handling .......................34
6.5. Hold Timer Expired Error Handling .........................34
6.6. Finite State Machine Error Handling .......................35
6.7. Cease .....................................................35
6.8. BGP Connection Collision Detection ........................35
7. BGP Version Negotiation ........................................36
8. BGP Finite State Machine (FSM) .................................37
8.1. Events for the BGP FSM ....................................38
8.1.1. Optional Events Linked to Optional Session
Attributes .........................................38
8.1.2. Administrative Events ..............................42
8.1.3. Timer Events .......................................46
8.1.4. TCP Connection-Based Events ........................47
8.1.5. BGP Message-Based Events ...........................49
8.2. Description of FSM ........................................51
8.2.1. FSM Definition .....................................51
8.2.1.1. Terms "active" and "passive" ..............52
8.2.1.2. FSM and Collision Detection ...............52
8.2.1.3. FSM and Optional Session Attributes .......52
8.2.1.4. FSM Event Numbers .........................53
1. Introduction ....................................................4
1.1. Definition of Commonly Used Terms ..........................4
1.2. Specification of Requirements ..............................6
2. Acknowledgements ................................................6
3. Summary of Operation ............................................7
3.1. Routes: Advertisement and Storage ..........................9
3.2. Routing Information Base ..................................10
4. Message Formats ................................................11
4.1. Message Header Format .....................................12
4.2. OPEN Message Format .......................................13
4.3. UPDATE Message Format .....................................14
4.4. KEEPALIVE Message Format ..................................21
4.5. NOTIFICATION Message Format ...............................21
5. Path Attributes ................................................23
5.1. Path Attribute Usage ......................................25
5.1.1. ORIGIN .............................................25
5.1.2. AS_PATH ............................................25
5.1.3. NEXT_HOP ...........................................26
5.1.4. MULTI_EXIT_DISC ....................................28
5.1.5. LOCAL_PREF .........................................29
5.1.6. ATOMIC_AGGREGATE ...................................29
5.1.7. AGGREGATOR .........................................30
6. BGP Error Handling. ............................................30
6.1. Message Header Error Handling .............................31
6.2. OPEN Message Error Handling ...............................31
6.3. UPDATE Message Error Handling .............................32
6.4. NOTIFICATION Message Error Handling .......................34
6.5. Hold Timer Expired Error Handling .........................34
6.6. Finite State Machine Error Handling .......................35
6.7. Cease .....................................................35
6.8. BGP Connection Collision Detection ........................35
7. BGP Version Negotiation ........................................36
8. BGP Finite State Machine (FSM) .................................37
8.1. Events for the BGP FSM ....................................38
8.1.1. Optional Events Linked to Optional Session
Attributes .........................................38
8.1.2. Administrative Events ..............................42
8.1.3. Timer Events .......................................46
8.1.4. TCP Connection-Based Events ........................47
8.1.5. BGP Message-Based Events ...........................49
8.2. Description of FSM ........................................51
8.2.1. FSM Definition .....................................51
8.2.1.1. Terms "active" and "passive" ..............52
8.2.1.2. FSM and Collision Detection ...............52
8.2.1.3. FSM and Optional Session Attributes .......52
8.2.1.4. FSM Event Numbers .........................53
8.2.1.5. FSM Actions that are Implementation
Dependent .................................53
8.2.2. Finite State Machine ...............................53
9. UPDATE Message Handling ........................................75
9.1. Decision Process ..........................................76
9.1.1. Phase 1: Calculation of Degree of Preference .......77
9.1.2. Phase 2: Route Selection ...........................77
9.1.2.1. Route Resolvability Condition .............79
9.1.2.2. Breaking Ties (Phase 2) ...................80
9.1.3. Phase 3: Route Dissemination .......................82
9.1.4. Overlapping Routes .................................83
9.2. Update-Send Process .......................................84
9.2.1. Controlling Routing Traffic Overhead ...............85
9.2.1.1. Frequency of Route Advertisement ..........85
9.2.1.2. Frequency of Route Origination ............85
9.2.2. Efficient Organization of Routing Information ......86
9.2.2.1. Information Reduction .....................86
9.2.2.2. Aggregating Routing Information ...........87
9.3. Route Selection Criteria ..................................89
9.4. Originating BGP routes ....................................89
10. BGP Timers ....................................................90
Appendix A. Comparison with RFC 1771 .............................92
Appendix B. Comparison with RFC 1267 .............................93
Appendix C. Comparison with RFC 1163 .............................93
Appendix D. Comparison with RFC 1105 .............................94
Appendix E. TCP Options that May Be Used with BGP ................94
Appendix F. Implementation Recommendations .......................95
Appendix F.1. Multiple Networks Per Message .........95
Appendix F.2. Reducing Route Flapping ...............96
Appendix F.3. Path Attribute Ordering ...............96
Appendix F.4. AS_SET Sorting ........................96
Appendix F.5. Control Over Version Negotiation ......96
Appendix F.6. Complex AS_PATH Aggregation ...........96
Security Considerations ...........................................97
IANA Considerations ...............................................99
Normative References .............................................101
Informative References ...........................................101
8.2.1.5. FSM Actions that are Implementation
Dependent .................................53
8.2.2. Finite State Machine ...............................53
9. UPDATE Message Handling ........................................75
9.1. Decision Process ..........................................76
9.1.1. Phase 1: Calculation of Degree of Preference .......77
9.1.2. Phase 2: Route Selection ...........................77
9.1.2.1. Route Resolvability Condition .............79
9.1.2.2. Breaking Ties (Phase 2) ...................80
9.1.3. Phase 3: Route Dissemination .......................82
9.1.4. Overlapping Routes .................................83
9.2. Update-Send Process .......................................84
9.2.1. Controlling Routing Traffic Overhead ...............85
9.2.1.1. Frequency of Route Advertisement ..........85
9.2.1.2. Frequency of Route Origination ............85
9.2.2. Efficient Organization of Routing Information ......86
9.2.2.1. Information Reduction .....................86
9.2.2.2. Aggregating Routing Information ...........87
9.3. Route Selection Criteria ..................................89
9.4. Originating BGP routes ....................................89
10. BGP Timers ....................................................90
Appendix A. Comparison with RFC 1771 .............................92
Appendix B. Comparison with RFC 1267 .............................93
Appendix C. Comparison with RFC 1163 .............................93
Appendix D. Comparison with RFC 1105 .............................94
Appendix E. TCP Options that May Be Used with BGP ................94
Appendix F. Implementation Recommendations .......................95
Appendix F.1. Multiple Networks Per Message .........95
Appendix F.2. Reducing Route Flapping ...............96
Appendix F.3. Path Attribute Ordering ...............96
Appendix F.4. AS_SET Sorting ........................96
Appendix F.5. Control Over Version Negotiation ......96
Appendix F.6. Complex AS_PATH Aggregation ...........96
Security Considerations ...........................................97
IANA Considerations ...............................................99
Normative References .............................................101
Informative References ...........................................101
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.
边界网关协议（BGP）是一种自治系统间路由协议。
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability, from which routing loops may be pruned and, at the AS level, some policy decisions may be enforced.
BGP语音系统的主要功能是与其他BGP系统交换网络可达性信息。该网络可达性信息包括可达性信息所遍历的自治系统（ASE）列表上的信息。这些信息足以为这种可达性构建AS连接图，从中可以修剪路由循环，并且在AS级别可以强制执行一些策略决策。
BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.
BGP-4提供了一组支持无类域间路由（CIDR）的机制[RFC1518，RFC1519]。这些机制包括支持将一组目的地作为IP前缀进行广告，并消除BGP中网络“类”的概念。BGP-4还引入了允许路由聚合的机制，包括AS路径聚合。
Routing information exchanged via BGP supports only the destination-based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and cannot) be enforced using BGP. BGP can support only those policies conforming to the destination-based forwarding paradigm.
通过BGP交换的路由信息仅支持基于目的地的转发范例，该范例假定路由器仅基于包的IP报头中携带的目的地地址转发包。这反过来反映了可以（也不能）使用BGP实施的一组策略决策。BGP只能支持符合基于目的地的转发模式的策略。
This section provides definitions for terms that have a specific meaning to the BGP protocol and that are used throughout the text.
本节提供了对BGP协议具有特定含义且贯穿全文的术语定义。
Adj-RIB-In The Adj-RIBs-In contains unprocessed routing information that has been advertised to the local BGP speaker by its peers.
中的Adj RIB中的Adj RIB包含未经处理的路由信息，该信息已由其对等方播发给本地BGP扬声器。
Adj-RIB-Out The Adj-RIBs-Out contains the routes for advertisement to specific peers by means of the local speaker's UPDATE messages.
Adj RIB Out Adj RIB Out包含通过本地说话人的更新消息向特定对等方发布广告的路线。
Autonomous System (AS) The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASes. Since this classic definition was developed, it has become common for a single AS to
自治系统（AS）自治系统的经典定义是在单一技术管理下的一组路由器，使用内部网关协议（IGP）和通用度量来确定如何在AS内路由数据包，并使用AS间路由协议来确定如何将数据包路由到其他AS。自从这个经典的定义被开发出来后，它已经成为一个单一的AS-to的常见定义
use several IGPs and, sometimes, several sets of metrics within an AS. The use of the term Autonomous System stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASes to have a single coherent interior routing plan, and presents a consistent picture of the destinations that are reachable through it.
在AS中使用多个IGP，有时使用多组度量。术语“自治系统”的使用强调了这样一个事实，即即使在使用多个IGP和指标时，AS的管理在其他ASE看来似乎具有单个一致的内部路由计划，并且呈现了可通过其到达的目的地的一致图像。
BGP Identifier A 4-octet unsigned integer that indicates the BGP Identifier of the sender of BGP messages. A given BGP speaker sets the value of its BGP Identifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined upon startup and is the same for every local interface and BGP peer.
BGP标识符表示BGP消息发送方的BGP标识符的4个八位无符号整数。给定的BGP扬声器将其BGP标识符的值设置为分配给该BGP扬声器的IP地址。BGP标识符的值在启动时确定，并且对于每个本地接口和BGP对等方都是相同的。
BGP speaker A router that implements BGP.
BGP扬声器实现BGP的路由器。
EBGP External BGP (BGP connection between external peers).
EBGP外部BGP（外部对等方之间的BGP连接）。
External peer Peer that is in a different Autonomous System than the local system.
与本地系统不同的自治系统中的外部对等点。
Feasible route An advertised route that is available for use by the recipient.
可行路线可供收件人使用的广告路线。
IBGP Internal BGP (BGP connection between internal peers).
IBGP内部BGP（内部对等方之间的BGP连接）。
Internal peer Peer that is in the same Autonomous System as the local system.
与本地系统位于同一自治系统中的内部对等点。
IGP Interior Gateway Protocol - a routing protocol used to exchange routing information among routers within a single Autonomous System.
IGP内部网关协议-用于在单个自治系统内的路由器之间交换路由信息的路由协议。
Loc-RIB The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process.
Loc RIB Loc RIB包含本地BGP发言人决策过程选择的路线。
NLRI Network Layer Reachability Information.
NLRI网络层可达性信息。
Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of
路由将一组目的地与这些目的地的路径属性配对的信息单元。一套
destinations are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message. The path is the information reported in the path attributes field of the same UPDATE message.
目的地是IP地址包含在更新消息的网络层可达性信息（NLRI）字段中的一个IP地址前缀中的系统。路径是在同一更新消息的路径属性字段中报告的信息。
RIB Routing Information Base.
RIB路由信息库。
Unfeasible route A previously advertised feasible route that is no longer available for use.
不可行路线以前公布的不再可用的可行路线。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document was originally published as [RFC1267] in October 1991, jointly authored by Kirk Lougheed and Yakov Rekhter.
本文件最初于1991年10月作为[RFC1267]出版，由柯克·洛赫德和亚科夫·雷克特共同撰写。
We would like to express our thanks to Guy Almes, Len Bosack, and Jeffrey C. Honig for their contributions to the earlier version (BGP-1) of this document.
我们要感谢Guy Almes、Len Bosack和Jeffrey C.Honig对本文件早期版本（BGP-1）的贡献。
We would like to specially acknowledge numerous contributions by Dennis Ferguson to the earlier version of this document.
我们要特别感谢丹尼斯·弗格森（Dennis Ferguson）对本文件早期版本的众多贡献。
We would like to explicitly thank Bob Braden for the review of the earlier version (BGP-2) of this document, and for his constructive and valuable comments.
我们要明确感谢Bob Braden对本文件早期版本（BGP-2）的审查，以及他提出的建设性和有价值的意见。
We would also like to thank Bob Hinden, Director for Routing of the Internet Engineering Steering Group, and the team of reviewers he assembled to review the earlier version (BGP-2) of this document. This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted with a strong combination of toughness, professionalism, and courtesy.
我们还要感谢互联网工程指导小组负责人Bob Hinden，以及他为审查本文件早期版本（BGP-2）而召集的审查小组。这支由黛博拉·埃斯特林、米洛·梅丁、约翰·莫伊、拉迪亚·帕尔曼、玛莎·斯特鲁普、迈克·圣约翰斯和保罗·丘奇亚组成的团队，表现出坚韧、专业和礼貌的强大组合。
Certain sections of the document borrowed heavily from IDRP [IS10747], which is the OSI counterpart of BGP. For this, credit should be given to the ANSI X3S3.3 group chaired by Lyman Chapin and to Charles Kunzinger, who was the IDRP editor within that group.
该文件的某些部分大量借用了IDRP[IS10747]，IDRP是BGP的OSI副本。为此，应归功于由Lyman Chapin主持的ANSI X3S3.3小组和该小组内的IDRP编辑Charles Kunzinger。
We would also like to thank Benjamin Abarbanel, Enke Chen, Edward Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey Haas, Dimitry Haskin, Stephen Kent, John Krawczyk, David LeRoy, Dan Massey, Jonathan Natale, Dan Pei, Mathew Richardson, John Scudder, John Stewart III, Dave Thaler, Paul Traina, Russ White, Curtis Villamizar, and Alex Zinin for their comments.
我们还要感谢本杰明·阿巴巴内尔、恩克·陈、爱德华·克拉布、迈克·克雷伦、文森特·吉列、埃里克·格雷、杰弗里·哈斯、迪米特里·哈斯金、斯蒂芬·肯特、约翰·克劳奇克、大卫·勒罗伊、丹·梅西、乔纳森·纳塔莱、丹·贝伊、马修·理查森、约翰·斯卡德尔、约翰·斯图尔特三世、戴夫·泰勒、保罗·特拉纳、罗斯·怀特、柯蒂斯·维拉米扎、，和Alex Zinin的评论。
We would like to specially acknowledge Andrew Lange for his help in preparing the final version of this document.
我们要特别感谢Andrew Lange在编制本文件最终版本方面的帮助。
Finally, we would like to thank all the members of the IDR Working Group for their ideas and the support they have given to this document.
最后，我们要感谢IDR工作组的所有成员对本文件的想法和支持。
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP (as defined in [RFC904]) and EGP usage in the NSFNET Backbone (as described in [RFC1092] and [RFC1093]). For more BGP-related information, see [RFC1772], [RFC1930], [RFC1997], and [RFC2858].
边界网关协议（BGP）是一种自治系统间路由协议。它建立在EGP（定义见[RFC904]）和NSFNET主干网中EGP使用（定义见[RFC1092]和[RFC1093]）的经验基础上。有关BGP的更多信息，请参阅[RFC1772]、[RFC1930]、[RFC1997]和[RFC2858]。
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity, from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.
BGP语音系统的主要功能是与其他BGP系统交换网络可达性信息。该网络可达性信息包括可达性信息所遍历的自治系统（ASE）列表上的信息。这些信息足以构建AS连接图，从中可以修剪路由循环，并且在AS级别可以执行一些策略决策。
In the context of this document, we assume that a BGP speaker advertises to its peers only those routes that it uses itself (in this context, a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document.
在本文档的上下文中，我们假设BGP演讲者仅向其对等方播发其使用的那些路由（在此上下文中，如果BGP演讲者是最首选的BGP路由并用于转发，则称其“使用”BGP路由）。所有其他情况均不在本文件范围内。
In the context of this document, the term "IP address" refers to an IP Version 4 address [RFC791].
在本文件上下文中，术语“IP地址”指IP版本4地址[RFC791]。
Routing information exchanged via BGP supports only the destination-based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and cannot) be enforced using BGP. Note that some policies cannot be supported by the destination-based forwarding paradigm, and thus require techniques such as source routing (aka explicit routing) to be enforced. Such policies cannot be enforced using BGP either. For example, BGP does not enable one AS to send
通过BGP交换的路由信息仅支持基于目的地的转发范例，该范例假定路由器仅基于包的IP报头中携带的目的地地址转发包。这反过来反映了可以（也不能）使用BGP实施的一组策略决策。请注意，某些策略不能由基于目的地的转发范例支持，因此需要实施源路由（也称为显式路由）等技术。使用BGP也无法强制执行此类策略。例如，BGP不启用一个AS发送
traffic to a neighboring AS for forwarding to some destination (reachable through but) beyond that neighboring AS, intending that the traffic take a different route to that taken by the traffic originating in the neighboring AS (for that same destination). On the other hand, BGP can support any policy conforming to the destination-based forwarding paradigm.
发送到相邻AS的流量，用于转发到该相邻AS之外的某个目的地（可通过but到达），意图使该流量采用与源自相邻AS的流量（对于该相同目的地）不同的路由。另一方面，BGP可以支持符合基于目的地的转发范例的任何策略。
BGP-4 provides a new set of mechanisms for supporting Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix and eliminating the concept of a network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.
BGP-4提供了一组新的机制来支持无类域间路由（CIDR）[RFC1518，RFC1519]。这些机制包括支持将一组目的地作为IP前缀进行广告，并消除BGP中网络“类”的概念。BGP-4还引入了允许路由聚合的机制，包括AS路径聚合。
This document uses the term `Autonomous System' (AS) throughout. The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASes. Since this classic definition was developed, it has become common for a single AS to use several IGPs and, sometimes, several sets of metrics within an AS. The use of the term Autonomous System stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASes to have a single coherent interior routing plan and presents a consistent picture of the destinations that are reachable through it.
本文件通篇使用“自治系统”（AS）一词。自治系统的经典定义是在单一技术管理下的一组路由器，使用内部网关协议（IGP）和通用度量来确定如何在AS内路由数据包，并使用AS间路由协议来确定如何将数据包路由到其他AS。自这一经典定义被开发以来，单个AS使用多个IGP，有时在AS中使用多组度量已经变得很常见。术语“自治系统”的使用强调了这样一个事实，即即使在使用多个IGP和指标时，AS的管理在其他ASE看来似乎有一个单一的一致内部路由计划，并呈现了可通过它到达的目的地的一致图像。
BGP uses TCP [RFC793] as its transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing. BGP listens on TCP port 179. The error notification mechanism used in BGP assumes that TCP supports a "graceful" close (i.e., that all outstanding data will be delivered before the connection is closed).
BGP使用TCP[RFC793]作为其传输协议。这消除了实现显式更新分段、重传、确认和排序的需要。BGP侦听TCP端口179。BGP中使用的错误通知机制假设TCP支持“正常”关闭（即，所有未完成的数据都将在连接关闭之前交付）。
A TCP connection is formed between two systems. They exchange messages to open and confirm the connection parameters.
在两个系统之间形成TCP连接。它们交换消息以打开和确认连接参数。
The initial data flow is the portion of the BGP routing table that is allowed by the export policy, called the Adj-Ribs-Out (see 3.2). Incremental updates are sent as the routing tables change. BGP does not require a periodic refresh of the routing table. To allow local policy changes to have the correct effect without resetting any BGP connections, a BGP speaker SHOULD either (a) retain the current version of the routes advertised to it by all of its peers for the duration of the connection, or (b) make use of the Route Refresh extension [RFC2918].
初始数据流是导出策略允许的BGP路由表的一部分，称为Adj RIB Out（参见3.2）。随着路由表的更改，将发送增量更新。BGP不需要定期刷新路由表。为了允许本地策略更改在不重置任何BGP连接的情况下产生正确的效果，BGP演讲者应（a）在连接期间保留所有对等方向其公布的路由的当前版本，或（b）使用路由刷新扩展[RFC2918]。
KEEPALIVE messages may be sent periodically to ensure that the connection is live. NOTIFICATION messages are sent in response to errors or special conditions. If a connection encounters an error condition, a NOTIFICATION message is sent and the connection is closed.
KEEPALIVE消息可以定期发送，以确保连接处于活动状态。通知消息是针对错误或特殊情况发送的。如果连接遇到错误情况，将发送通知消息并关闭连接。
A peer in a different AS is referred to as an external peer, while a peer in the same AS is referred to as an internal peer. Internal BGP and external BGP are commonly abbreviated as IBGP and EBGP.
不同AS中的对等点称为外部对等点，而相同AS中的对等点称为内部对等点。内部BGP和外部BGP通常缩写为IBGP和EBGP。
If a particular AS has multiple BGP speakers and is providing transit service for other ASes, then care must be taken to ensure a consistent view of routing within the AS. A consistent view of the interior routes of the AS is provided by the IGP used within the AS. For the purpose of this document, it is assumed that a consistent view of the routes exterior to the AS is provided by having all BGP speakers within the AS maintain IBGP with each other.
如果一个特定的AS有多个BGP扬声器，并为其他AS提供中转服务，则必须注意确保AS内的路由视图一致。AS内部使用的IGP提供了AS内部路线的一致视图。在本文件中，假设AS内的所有BGP扬声器彼此保持IBGP，从而提供AS外部路线的一致视图。
This document specifies the base behavior of the BGP protocol. This behavior can be, and is, modified by extension specifications. When the protocol is extended, the new behavior is fully documented in the extension specifications.
本文档指定了BGP协议的基本行为。扩展规范可以并且正在修改此行为。当协议被扩展时，新的行为将完全记录在扩展规范中。
For the purpose of this protocol, a route is defined as a unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix that is carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message, and the path is the information reported in the path attributes field of the same UPDATE message.
在本协议中，路由被定义为将一组目的地与这些目的地的路径属性配对的信息单元。目的地集是其IP地址包含在更新消息的网络层可达性信息（NLRI）字段中携带的一个IP地址前缀中的系统，并且路径是同一更新消息的路径属性字段中报告的信息。
Routes are advertised between BGP speakers in UPDATE messages. Multiple routes that have the same path attributes can be advertised in a single UPDATE message by including multiple prefixes in the NLRI field of the UPDATE message.
在更新消息中公布BGP扬声器之间的路由。通过在更新消息的NLRI字段中包含多个前缀，可以在单个更新消息中通告具有相同路径属性的多个路由。
Routes are stored in the Routing Information Bases (RIBs): namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out, as described in Section 3.2.
路由存储在路由信息库（RIB）中：即第3.2节所述的Adj RIB in、Loc RIB和Adj RIB Out。
If a BGP speaker chooses to advertise a previously received route, it MAY add to, or modify, the path attributes of the route before advertising it to a peer.
如果BGP演讲者选择公布先前接收到的路由，它可以在向对等方公布之前添加或修改路由的路径属性。
BGP provides mechanisms by which a BGP speaker can inform its peers that a previously advertised route is no longer available for use. There are three methods by which a given BGP speaker can indicate that a route has been withdrawn from service:
BGP提供了一种机制，通过这种机制，BGP演讲者可以通知其对等方先前公布的路由不再可用。有三种方法可以让给定的BGP扬声器指示路由已退出服务：
a) the IP prefix that expresses the destination for a previously advertised route can be advertised in the WITHDRAWN ROUTES field in the UPDATE message, thus marking the associated route as being no longer available for use,
a) 表示先前公布的路由的目的地的IP前缀可以在更新消息中的撤回路由字段中公布，从而将相关路由标记为不再可用，
b) a replacement route with the same NLRI can be advertised, or
b) 可以公布具有相同NLRI的替换路由，或者
c) the BGP speaker connection can be closed, which implicitly removes all routes the pair of speakers had advertised to each other from service.
c) BGP扬声器连接可以关闭，这会隐式地从服务中删除这对扬声器相互通告的所有路由。
Changing the attribute(s) of a route is accomplished by advertising a replacement route. The replacement route carries new (changed) attributes and has the same address prefix as the original route.
更改路由的属性是通过公布替换路由来完成的。替换路由具有新的（更改的）属性，并且具有与原始路由相同的地址前缀。
The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts:
BGP扬声器中的路由信息库（RIB）由三个不同的部分组成：
a) Adj-RIBs-In: The Adj-RIBs-In stores routing information learned from inbound UPDATE messages that were received from other BGP speakers. Their contents represent routes that are available as input to the Decision Process.
a) Adj RIB In：Adj RIB In存储从其他BGP扬声器接收的入站更新消息中学习的路由信息。它们的内容表示可作为决策过程输入的路由。
b) Loc-RIB: The Loc-RIB contains the local routing information the BGP speaker selected by applying its local policies to the routing information contained in its Adj-RIBs-In. These are the routes that will be used by the local BGP speaker. The next hop for each of these routes MUST be resolvable via the local BGP speaker's Routing Table.
b) Loc RIB：Loc RIB包含BGP演讲者通过将其本地策略应用于其Adj RIB中包含的路由信息而选择的本地路由信息。这些是本地BGP扬声器将使用的路由。每个路由的下一跳必须可通过本地BGP扬声器的路由表解析。
c) Adj-RIBs-Out: The Adj-RIBs-Out stores information the local BGP speaker selected for advertisement to its peers. The routing information stored in the Adj-RIBs-Out will be carried in the local BGP speaker's UPDATE messages and advertised to its peers.
c) Adj-Robbs Out：Adj-Robbs Out存储本地BGP扬声器选择用于向其对等方发布广告的信息。Adj输出中存储的路由信息将在本地BGP说话人的更新消息中携带，并向其对等方发布。
In summary, the Adj-RIBs-In contains unprocessed routing information that has been advertised to the local BGP speaker by its peers; the Loc-RIB contains the routes that have been selected by the local BGP
总之，Adj肋骨In包含由其对等方向本地BGP说话者通告的未经处理的路由信息；Loc RIB包含本地BGP选择的路由
speaker's Decision Process; and the Adj-RIBs-Out organizes the routes for advertisement to specific peers (by means of the local speaker's UPDATE messages).
发言人的决策过程；Adj-Out（通过本地说话人的更新消息）将广告路由组织到特定的对等方。
Although the conceptual model distinguishes between Adj-RIBs-In, Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an implementation must maintain three separate copies of the routing information. The choice of implementation (for example, 3 copies of the information vs 1 copy with pointers) is not constrained by the protocol.
尽管概念模型区分了Adj加强筋In、Loc加强筋和Adj加强筋Out，但这并不意味着也不要求实现必须维护路由信息的三个单独副本。实现的选择（例如，信息的3个副本与带指针的1个副本）不受协议的限制。
Routing information that the BGP speaker uses to forward packets (or to construct the forwarding table used for packet forwarding) is maintained in the Routing Table. The Routing Table accumulates routes to directly connected networks, static routes, routes learned from the IGP protocols, and routes learned from BGP. Whether a specific BGP route should be installed in the Routing Table, and whether a BGP route should override a route to the same destination installed by another source, is a local policy decision, and is not specified in this document. In addition to actual packet forwarding, the Routing Table is used for resolution of the next-hop addresses specified in BGP updates (see Section 5.1.3).
BGP扬声器用于转发数据包（或构建用于数据包转发的转发表）的路由信息保存在路由表中。路由表累积到直接连接网络的路由、静态路由、从IGP协议学习的路由以及从BGP学习的路由。是否应在路由表中安装特定的BGP路由，以及BGP路由是否应覆盖到另一个源安装的相同目标的路由，这是本地策略决定，本文档中未指定。除了实际的数据包转发外，路由表还用于解析BGP更新中指定的下一跳地址（见第5.1.3节）。
This section describes message formats used by BGP.
本节介绍BGP使用的消息格式。
BGP messages are sent over TCP connections. A message is processed only after it is entirely received. The maximum message size is 4096 octets. All implementations are required to support this maximum message size. The smallest message that may be sent consists of a BGP header without a data portion (19 octets).
BGP消息通过TCP连接发送。消息只有在完全接收后才被处理。最大消息大小为4096个八位字节。所有实现都需要支持此最大消息大小。可发送的最小消息由不带数据部分的BGP报头（19个八位字节）组成。
All multi-octet fields are in network byte order.
所有多个八位字节字段均按网络字节顺序排列。
Each message has a fixed-size header. There may or may not be a data portion following the header, depending on the message type. The layout of these fields is shown below:
每封邮件都有一个固定大小的标题。根据消息类型，报头后面可能有数据部分，也可能没有数据部分。这些字段的布局如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker:
标记：
This 16-octet field is included for compatibility; it MUST be set to all ones.
该16个八位组字段是为了兼容性而包含的；它必须设置为“所有”。
Length:
长度：
This 2-octet unsigned integer indicates the total length of the message, including the header in octets. Thus, it allows one to locate the (Marker field of the) next message in the TCP stream. The value of the Length field MUST always be at least 19 and no greater than 4096, and MAY be further constrained, depending on the message type. "padding" of extra data after the message is not allowed. Therefore, the Length field MUST have the smallest value required, given the rest of the message.
此2-octet无符号整数表示消息的总长度，包括以八位字节表示的标头。因此，它允许定位TCP流中的下一条消息（标记字段）。长度字段的值必须始终至少为19且不大于4096，并且可以根据消息类型进行进一步约束。不允许在消息后“填充”额外数据。因此，给定消息的其余部分，长度字段必须具有所需的最小值。
Type:
类型：
This 1-octet unsigned integer indicates the type code of the message. This document defines the following type codes:
此1-octet无符号整数表示消息的类型代码。本文件定义了以下类型代码：
1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
1-打开2-更新3-通知4-保留
[RFC2918] defines one more type code.
[RFC2918]定义了一个或多个类型代码。
After a TCP connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back.
TCP连接建立后，每一方发送的第一条消息是开放消息。如果打开的消息是可接受的，则返回确认打开的KEEPALIVE消息。
In addition to the fixed-size BGP header, the OPEN message contains the following fields:
除了固定大小的BGP标头外，打开消息还包含以下字段：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
版本：
This 1-octet unsigned integer indicates the protocol version number of the message. The current BGP version number is 4.
此1-octet无符号整数表示消息的协议版本号。当前BGP版本号为4。
My Autonomous System:
我的自主系统：
This 2-octet unsigned integer indicates the Autonomous System number of the sender.
这个2-octet无符号整数表示发送方的自治系统号。
Hold Time:
保持时间：
This 2-octet unsigned integer indicates the number of seconds the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, a BGP speaker MUST calculate the value of the Hold Timer by using the smaller of its configured Hold Time and the Hold Time received in the OPEN message. The Hold Time MUST be either zero or at least three seconds. An implementation MAY reject connections on the basis of the Hold
此2-octet无符号整数表示发送方建议保留计时器值的秒数。收到打开消息后，BGP扬声器必须使用其配置的保持时间和打开消息中接收到的保持时间中的较小者来计算保持计时器的值。保持时间必须为零或至少三秒。实现可以基于保持拒绝连接
Time. The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages from the sender.
时间计算的值表示从发送方接收连续的KEEPALIVE和/或UPDATE消息之间可能经过的最大秒数。
BGP Identifier:
BGP标识符：
This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Identifier to an IP address that is assigned to that BGP speaker. The value of the BGP Identifier is determined upon startup and is the same for every local interface and BGP peer.
此4个八位无符号整数表示发送方的BGP标识符。给定的BGP扬声器将其BGP标识符的值设置为分配给该BGP扬声器的IP地址。BGP标识符的值在启动时确定，并且对于每个本地接口和BGP对等方都是相同的。
Optional Parameters Length:
可选参数长度：
This 1-octet unsigned integer indicates the total length of the Optional Parameters field in octets. If the value of this field is zero, no Optional Parameters are present.
此1-octet无符号整数表示可选参数字段的总长度（以八位字节为单位）。如果此字段的值为零，则不存在可选参数。
Optional Parameters:
可选参数：
This field contains a list of optional parameters, in which each parameter is encoded as a <Parameter Type, Parameter Length, Parameter Value> triplet.
此字段包含可选参数列表，其中每个参数都编码为<parameter Type，parameter Length，parameter Value>三元组。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Parameter Type is a one octet field that unambiguously identifies individual parameters. Parameter Length is a one octet field that contains the length of the Parameter Value field in octets. Parameter Value is a variable length field that is interpreted according to the value of the Parameter Type field.
参数类型是一个八位字节字段，可以明确标识各个参数。参数长度是一个八位字节字段，包含参数值字段的八位字节长度。参数值是根据参数类型字段的值解释的可变长度字段。
[RFC3392] defines the Capabilities Optional Parameter.
[RFC3392]定义了能力可选参数。
The minimum length of the OPEN message is 29 octets (including the message header).
打开消息的最小长度为29个八位字节（包括消息头）。
UPDATE messages are used to transfer routing information between BGP peers. The information in the UPDATE message can be used to construct a graph that describes the relationships of the various Autonomous Systems. By applying rules to be discussed, routing
更新消息用于在BGP对等方之间传输路由信息。更新消息中的信息可用于构建描述各种自治系统关系的图。通过应用待讨论的规则，路由
information loops and some other anomalies may be detected and removed from inter-AS routing.
信息循环和一些其他异常可能会被检测到，并从AS间路由中删除。
An UPDATE message is used to advertise feasible routes that share common path attributes to a peer, or to withdraw multiple unfeasible routes from service (see 3.1). An UPDATE message MAY simultaneously advertise a feasible route and withdraw multiple unfeasible routes from service. The UPDATE message always includes the fixed-size BGP header, and also includes the other fields, as shown below (note, some of the shown fields may not be present in every UPDATE message):
更新消息用于向对等方公布共享公共路径属性的可行路由，或从服务中撤回多个不可行路由（见3.1）。更新消息可同时公布可行路由并从服务中撤回多个不可行路由。更新消息始终包括固定大小的BGP标头，还包括其他字段，如下所示（注意，某些显示的字段可能不会出现在每个更新消息中）：
+-----------------------------------------------------+
| Withdrawn Routes Length (2 octets) |
+-----------------------------------------------------+
| Withdrawn Routes (variable) |
+-----------------------------------------------------+
| Total Path Attribute Length (2 octets) |
+-----------------------------------------------------+
| Path Attributes (variable) |
+-----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+-----------------------------------------------------+
+-----------------------------------------------------+
| Withdrawn Routes Length (2 octets) |
+-----------------------------------------------------+
| Withdrawn Routes (variable) |
+-----------------------------------------------------+
| Total Path Attribute Length (2 octets) |
+-----------------------------------------------------+
| Path Attributes (variable) |
+-----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+-----------------------------------------------------+
Withdrawn Routes Length:
回收路线长度：
This 2-octets unsigned integer indicates the total length of the Withdrawn Routes field in octets. Its value allows the length of the Network Layer Reachability Information field to be determined, as specified below.
此2个八位字节的无符号整数表示以八位字节为单位的已撤销路由字段的总长度。其值允许确定网络层可达性信息字段的长度，如下所述。
A value of 0 indicates that no routes are being withdrawn from service, and that the WITHDRAWN ROUTES field is not present in this UPDATE message.
值0表示没有从服务中撤回路由，并且此更新消息中不存在撤回路由字段。
Withdrawn Routes:
撤销路线：
This is a variable-length field that contains a list of IP address prefixes for the routes that are being withdrawn from service. Each IP address prefix is encoded as a 2-tuple of the form <length, prefix>, whose fields are described below:
这是一个可变长度字段，其中包含正在退出服务的路由的IP地址前缀列表。每个IP地址前缀都编码为<length，prefix>形式的2元组，其字段描述如下：
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
The use and the meaning of these fields are as follows:
这些字段的用途和含义如下：
a) Length:
a) 长度：
The Length field indicates the length in bits of the IP address prefix. A length of zero indicates a prefix that matches all IP addresses (with prefix, itself, of zero octets).
长度字段以位表示IP地址前缀的长度。长度为零表示与所有IP地址匹配的前缀（前缀本身为零个八位字节）。
b) Prefix:
b) 前缀：
The Prefix field contains an IP address prefix, followed by the minimum number of trailing bits needed to make the end of the field fall on an octet boundary. Note that the value of trailing bits is irrelevant.
前缀字段包含IP地址前缀，后跟使字段结尾位于八位字节边界上所需的最小尾随位数。请注意，尾随位的值是无关的。
Total Path Attribute Length:
路径属性总长度：
This 2-octet unsigned integer indicates the total length of the Path Attributes field in octets. Its value allows the length of the Network Layer Reachability field to be determined as specified below.
此2-octet无符号整数表示路径属性字段的总长度（以八位字节为单位）。其值允许按照以下规定确定网络层可达性字段的长度。
A value of 0 indicates that neither the Network Layer Reachability Information field nor the Path Attribute field is present in this UPDATE message.
值0表示此更新消息中既不存在网络层可达性信息字段，也不存在路径属性字段。
Path Attributes:
路径属性：
A variable-length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple <attribute type, attribute length, attribute value> of variable length.
每个更新消息中都存在一个长度可变的路径属性序列，但仅携带已撤销路由的更新消息除外。每个路径属性都是长度可变的三重<attribute type，attribute length，attribute value>。
Attribute Type is a two-octet field that consists of the Attribute Flags octet, followed by the Attribute Type Code octet.
属性类型是一个两个八位字节字段，由属性标志八位字节组成，后跟属性类型代码八位字节。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0).
属性标志八位字节的高阶位（位0）是可选位。它定义属性是可选的（如果设置为1）还是已知的（如果设置为0）。
The second high-order bit (bit 1) of the Attribute Flags octet is the Transitive bit. It defines whether an optional attribute is transitive (if set to 1) or non-transitive (if set to 0).
属性标志八位字节的第二高位（第1位）是可传递位。它定义可选属性是可传递的（如果设置为1）还是不可传递的（如果设置为0）。
For well-known attributes, the Transitive bit MUST be set to 1. (See Section 5 for a discussion of transitive attributes.)
对于已知属性，可传递位必须设置为1。（有关传递属性的讨论，请参见第5节。）
The third high-order bit (bit 2) of the Attribute Flags octet is the Partial bit. It defines whether the information contained in the optional transitive attribute is partial (if set to 1) or complete (if set to 0). For well-known attributes and for optional non-transitive attributes, the Partial bit MUST be set to 0.
属性标志八位字节的第三高位（第2位）是部分位。它定义可选传递属性中包含的信息是部分（如果设置为1）还是完整（如果设置为0）。对于已知属性和可选非传递属性，部分位必须设置为0。
The fourth high-order bit (bit 3) of the Attribute Flags octet is the Extended Length bit. It defines whether the Attribute Length is one octet (if set to 0) or two octets (if set to 1).
属性标志八位字节的第四高位（第3位）是扩展长度位。它定义属性长度是一个八位字节（如果设置为0）还是两个八位字节（如果设置为1）。
The lower-order four bits of the Attribute Flags octet are unused. They MUST be zero when sent and MUST be ignored when received.
属性标志八位字节的低位四位未使用。它们在发送时必须为零，在接收时必须忽略。
The Attribute Type Code octet contains the Attribute Type Code. Currently defined Attribute Type Codes are discussed in Section 5.
属性类型代码八位字节包含属性类型代码。第5节讨论了当前定义的属性类型代码。
If the Extended Length bit of the Attribute Flags octet is set to 0, the third octet of the Path Attribute contains the length of the attribute data in octets.
如果属性标志八位字节的扩展长度位设置为0，则路径属性的第三个八位字节包含以八位字节为单位的属性数据长度。
If the Extended Length bit of the Attribute Flags octet is set to 1, the third and fourth octets of the path attribute contain the length of the attribute data in octets.
如果属性标志八位字节的扩展长度位设置为1，则路径属性的第三个和第四个八位字节包含八位字节中属性数据的长度。
The remaining octets of the Path Attribute represent the attribute value and are interpreted according to the Attribute Flags and the Attribute Type Code. The supported Attribute Type Codes, and their attribute values and uses are as follows:
路径属性的其余八位字节表示属性值，并根据属性标志和属性类型代码进行解释。支持的属性类型代码及其属性值和用途如下：
a) ORIGIN (Type Code 1):
a) 原产地（类型代码1）：
ORIGIN is a well-known mandatory attribute that defines the origin of the path information. The data octet can assume the following values:
原点是一个众所周知的强制属性，它定义了路径信息的原点。数据八位字节可以采用以下值：
Value Meaning
价值意义
0 IGP - Network Layer Reachability Information is interior to the originating AS
0 IGP-网络层可达性信息位于原始AS内部
1 EGP - Network Layer Reachability Information learned via the EGP protocol [RFC904]
1 EGP-通过EGP协议学习的网络层可达性信息[RFC904]
2 INCOMPLETE - Network Layer Reachability Information learned by some other means
2不完全-通过其他方法学习的网络层可达性信息
Usage of this attribute is defined in 5.1.1.
5.1.1中定义了该属性的用法。
b) AS_PATH (Type Code 2):
b) AS_路径（类型代码2）：
AS_PATH is a well-known mandatory attribute that is composed of a sequence of AS path segments. Each AS path segment is represented by a triple <path segment type, path segment length, path segment value>.
AS_PATH是一个众所周知的强制属性，由一系列AS路径段组成。每个AS路径段由三个<path segment type、path segment length、path segment value>表示。
The path segment type is a 1-octet length field with the following values defined:
路径段类型是一个1-octet长度字段，定义了以下值：
Value Segment Type
值段类型
1 AS_SET: unordered set of ASes a route in the UPDATE message has traversed
1 AS_SET：更新消息中的路由所经过的无序集合
2 AS_SEQUENCE: ordered set of ASes a route in the UPDATE message has traversed
2 AS_序列：更新消息中路由已遍历的有序ASE集
The path segment length is a 1-octet length field, containing the number of ASes (not the number of octets) in the path segment value field.
路径段长度是一个1-octet长度字段，包含路径段值字段中的ASE数（而不是八位字节数）。
The path segment value field contains one or more AS numbers, each encoded as a 2-octet length field.
路径段值字段包含一个或多个AS编号，每个编号编码为2个八位组长度字段。
Usage of this attribute is defined in 5.1.2.
5.1.2中定义了该属性的用法。
c) NEXT_HOP (Type Code 3):
c) 下一跳（类型代码3）：
This is a well-known mandatory attribute that defines the (unicast) IP address of the router that SHOULD be used as the next hop to the destinations listed in the Network Layer Reachability Information field of the UPDATE message.
这是一个众所周知的强制属性，它定义了路由器的（单播）IP地址，该地址应用作到更新消息的网络层可达性信息字段中列出的目的地的下一个跃点。
Usage of this attribute is defined in 5.1.3.
5.1.3中定义了该属性的用法。
d) MULTI_EXIT_DISC (Type Code 4):
d) 多出口光盘（类型代码4）：
This is an optional non-transitive attribute that is a four-octet unsigned integer. The value of this attribute MAY be used by a BGP speaker's Decision Process to discriminate among multiple entry points to a neighboring autonomous system.
这是一个可选的非传递属性，它是一个四个八位无符号整数。BGP说话人的决策过程可以使用该属性的值来区分相邻自治系统的多个入口点。
Usage of this attribute is defined in 5.1.4.
5.1.4中定义了该属性的用法。
e) LOCAL_PREF (Type Code 5):
e) 本地优先（类型代码5）：
LOCAL_PREF is a well-known attribute that is a four-octet unsigned integer. A BGP speaker uses it to inform its other internal peers of the advertising speaker's degree of preference for an advertised route.
LOCAL_PREF是一个众所周知的属性，它是一个四个八位无符号整数。BGP演讲者使用它通知其其他内部同行广告演讲者对广告路线的偏好程度。
Usage of this attribute is defined in 5.1.5.
5.1.5中定义了该属性的用法。
f) ATOMIC_AGGREGATE (Type Code 6)
f) 原子聚合（类型代码6）
ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0.
原子_聚合是众所周知的长度为0的任意属性。
Usage of this attribute is defined in 5.1.6.
5.1.6中定义了该属性的用法。
g) AGGREGATOR (Type Code 7)
g) 聚合器（类型代码7）
AGGREGATOR is an optional transitive attribute of length 6. The attribute contains the last AS number that formed the aggregate route (encoded as 2 octets), followed by the IP address of the BGP speaker that formed the aggregate route (encoded as 4 octets). This SHOULD be the same address as the one used for the BGP Identifier of the speaker.
聚合器是长度为6的可选传递属性。该属性包含形成聚合路由的最后一个AS编号（编码为2个八位字节），后跟形成聚合路由的BGP扬声器的IP地址（编码为4个八位字节）。该地址应与用于说话人BGP标识符的地址相同。
Usage of this attribute is defined in 5.1.7.
5.1.7中定义了该属性的用法。
Network Layer Reachability Information:
网络层可达性信息：
This variable length field contains a list of IP address prefixes. The length, in octets, of the Network Layer Reachability Information is not encoded explicitly, but can be calculated as:
此可变长度字段包含IP地址前缀列表。网络层可达性信息的长度（以八位字节为单位）未明确编码，但可计算为：
UPDATE message Length - 23 - Total Path Attributes Length - Withdrawn Routes Length
更新消息长度-23-路径属性总长度-撤回路由长度
where UPDATE message Length is the value encoded in the fixed-size BGP header, Total Path Attribute Length, and Withdrawn Routes Length are the values encoded in the variable part of the UPDATE message, and 23 is a combined length of the fixed-size BGP header, the Total Path Attribute Length field, and the Withdrawn Routes Length field.
其中，更新消息长度是在固定大小BGP报头中编码的值，总路径属性长度和撤回路由长度是在更新消息的可变部分中编码的值，23是固定大小BGP报头、总路径属性长度字段和撤回路由长度字段的组合长度。
Reachability information is encoded as one or more 2-tuples of the form <length, prefix>, whose fields are described below:
可达性信息编码为<length，prefix>形式的一个或多个2元组，其字段描述如下：
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
The use and the meaning of these fields are as follows:
这些字段的用途和含义如下：
a) Length:
a) 长度：
The Length field indicates the length in bits of the IP address prefix. A length of zero indicates a prefix that matches all IP addresses (with prefix, itself, of zero octets).
长度字段以位表示IP地址前缀的长度。长度为零表示与所有IP地址匹配的前缀（前缀本身为零个八位字节）。
b) Prefix:
b) 前缀：
The Prefix field contains an IP address prefix, followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of the trailing bits is irrelevant.
前缀字段包含一个IP地址前缀，后跟足够的尾随位，以使字段的结尾落在八位字节边界上。请注意，尾随位的值是无关的。
The minimum length of the UPDATE message is 23 octets -- 19 octets for the fixed header + 2 octets for the Withdrawn Routes Length + 2 octets for the Total Path Attribute Length (the value of Withdrawn Routes Length is 0 and the value of Total Path Attribute Length is 0).
更新消息的最小长度为23个八位字节——固定报头的19个八位字节+撤回路由长度的2个八位字节+总路径属性长度的2个八位字节（撤回路由长度的值为0，总路径属性长度的值为0）。
An UPDATE message can advertise, at most, one set of path attributes, but multiple destinations, provided that the destinations share these attributes. All path attributes contained in a given UPDATE message apply to all destinations carried in the NLRI field of the UPDATE message.
一条更新消息最多可以通告一组路径属性，但如果目标共享这些属性，则可以通告多个目标。给定更新消息中包含的所有路径属性适用于更新消息的NLRI字段中携带的所有目的地。
An UPDATE message can list multiple routes that are to be withdrawn from service. Each such route is identified by its destination (expressed as an IP prefix), which unambiguously identifies the route in the context of the BGP speaker - BGP speaker connection to which it has been previously advertised.
更新消息可以列出要退出服务的多个路由。每个这样的路由都由其目的地（表示为IP前缀）来标识，该目的地在BGP speaker-BGP speaker连接的上下文中明确标识了该路由，而该BGP speaker连接之前已被通告到该路由。
An UPDATE message might advertise only routes that are to be withdrawn from service, in which case the message will not include path attributes or Network Layer Reachability Information. Conversely, it may advertise only a feasible route, in which case the WITHDRAWN ROUTES field need not be present.
更新消息可能只公布要从服务中撤回的路由，在这种情况下，消息将不包括路径属性或网络层可达性信息。相反，它可能只公布可行的路线，在这种情况下，撤回的路线字段不需要存在。
An UPDATE message SHOULD NOT include the same address prefix in the WITHDRAWN ROUTES and Network Layer Reachability Information fields. However, a BGP speaker MUST be able to process UPDATE messages in this form. A BGP speaker SHOULD treat an UPDATE message of this form as though the WITHDRAWN ROUTES do not contain the address prefix.
更新消息不应在撤回的路由和网络层可达性信息字段中包含相同的地址前缀。但是，BGP发言人必须能够处理此表单中的更新消息。BGP发言人应将此表单的更新消息视为撤回的路由不包含地址前缀。
BGP does not use any TCP-based, keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more frequently than one per second. An implementation MAY adjust the rate at which it sends KEEPALIVE messages as a function of the Hold Time interval.
BGP不使用任何基于TCP的保持活动机制来确定对等点是否可访问。相反，在对等方之间交换KEEPALIVE消息的频率足够高，不会导致保持计时器过期。KEEPALIVE消息之间合理的最长时间是保持时间间隔的三分之一。KEEPALIVE消息的发送频率不得超过每秒一次。实现可以根据保持时间间隔调整发送KEEPALIVE消息的速率。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
如果协商的保持时间间隔为零，则不得发送定期的KEEPALIVE消息。
A KEEPALIVE message consists of only the message header and has a length of 19 octets.
KEEPALIVE消息仅由消息头组成，长度为19个八位字节。
A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent.
当检测到错误情况时，将发送通知消息。BGP连接在发送后立即关闭。
In addition to the fixed-size BGP header, the NOTIFICATION message contains the following fields:
除了固定大小的BGP标头外，通知消息还包含以下字段：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code | Error subcode | Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code | Error subcode | Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code:
错误代码：
This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined:
此1-octet无符号整数表示通知的类型。已定义以下错误代码：
Error Code Symbolic Name Reference
错误代码符号名称引用
1 Message Header Error Section 6.1
1消息头错误第6.1节
2 OPEN Message Error Section 6.2
2打开消息错误第6.2节
3 UPDATE Message Error Section 6.3
3更新消息错误第6.3节
4 Hold Timer Expired Section 6.5
4第6.5节中的保持计时器过期
5 Finite State Machine Error Section 6.6
5有限状态机错误第6.6节
6 Cease Section 6.7
6.第6.7节
Error subcode:
错误子代码：
This 1-octet unsigned integer provides more specific information about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field.
此1-octet无符号整数提供有关报告错误性质的更具体信息。每个错误代码可能有一个或多个与之关联的错误子代码。如果未定义适当的错误子代码，则错误子代码字段将使用零（非特定）值。
Message Header Error subcodes:
消息头错误子代码：
1 - Connection Not Synchronized. 2 - Bad Message Length. 3 - Bad Message Type.
1-连接未同步。2-错误的消息长度。3-错误消息类型。
OPEN Message Error subcodes:
打开消息错误子代码：
1 - Unsupported Version Number. 2 - Bad Peer AS. 3 - Bad BGP Identifier. 4 - Unsupported Optional Parameter. 5 - [Deprecated - see Appendix A]. 6 - Unacceptable Hold Time.
1-不支持的版本号。2-坏同龄人。3-错误的BGP标识符。4-不支持的可选参数。5-[已弃用-见附录A]。6-不可接受的保持时间。
UPDATE Message Error subcodes:
更新消息错误子代码：
1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid ORIGIN Attribute. 7 - [Deprecated - see Appendix A]. 8 - Invalid NEXT_HOP Attribute. 9 - Optional Attribute Error. 10 - Invalid Network Field. 11 - Malformed AS_PATH.
1-格式不正确的属性列表。2-无法识别的已知属性。3-缺少已知属性。4-属性标志错误。5-属性长度错误。6-无效的原始属性。7-[已弃用-见附录A]。8-下一跳属性无效。9-可选属性错误。10-无效的网络字段。11-格式不正确的AS_路径。
Data:
数据：
This variable-length field is used to diagnose the reason for the NOTIFICATION. The contents of the Data field depend upon the Error Code and Error Subcode. See Section 6 for more details.
此可变长度字段用于诊断通知的原因。数据字段的内容取决于错误代码和错误子代码。详见第6节。
Note that the length of the Data field can be determined from the message Length field by the formula:
请注意，数据字段的长度可以通过以下公式从消息长度字段中确定：
Message Length = 21 + Data Length
消息长度=21+数据长度
The minimum length of the NOTIFICATION message is 21 octets (including message header).
通知消息的最小长度为21个八位字节（包括消息头）。
This section discusses the path attributes of the UPDATE message.
本节讨论更新消息的路径属性。
Path attributes fall into four separate categories:
路径属性分为四个单独的类别：
1. Well-known mandatory. 2. Well-known discretionary. 3. Optional transitive. 4. Optional non-transitive.
1. 众所周知，这是强制性的。2.众所周知的自由裁量权。3.可选及物动词。4.可选的非传递的。
BGP implementations MUST recognize all well-known attributes. Some of these attributes are mandatory and MUST be included in every UPDATE message that contains NLRI. Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message.
BGP实现必须识别所有已知属性。其中一些属性是必需的，必须包含在包含NLRI的每个更新消息中。其他的是自由裁量的，可能会也可能不会在特定的更新消息中发送。
Once a BGP peer has updated any well-known attributes, it MUST pass these attributes to its peers in any updates it transmits.
一旦BGP对等机更新了任何已知的属性，它必须在传输的任何更新中将这些属性传递给它的对等机。
In addition to well-known attributes, each path MAY contain one or more optional attributes. It is not required or expected that all BGP implementations support all optional attributes. The handling of an unrecognized optional attribute is determined by the setting of the Transitive bit in the attribute flags octet. Paths with unrecognized transitive optional attributes SHOULD be accepted. If a path with an unrecognized transitive optional attribute is accepted and passed to other BGP peers, then the unrecognized transitive optional attribute of that path MUST be passed, along with the path, to other BGP peers with the Partial bit in the Attribute Flags octet set to 1. If a path with a recognized, transitive optional attribute is accepted and passed along to other BGP peers and the Partial bit in the Attribute Flags octet is set to 1 by some previous AS, it MUST NOT be set back to 0 by the current AS. Unrecognized non-transitive optional attributes MUST be quietly ignored and not passed along to other BGP peers.
除了众所周知的属性外，每个路径还可以包含一个或多个可选属性。并非所有BGP实现都需要或期望支持所有可选属性。无法识别的可选属性的处理由属性标志八位字节中可传递位的设置决定。应接受具有无法识别的可传递可选属性的路径。如果接受具有无法识别的可传递可选属性的路径并将其传递给其他BGP对等方，则该路径的无法识别的可传递可选属性必须与该路径一起传递给属性标志八位组中的部分位设置为1的其他BGP对等方。如果接受具有可识别的可传递可选属性的路径并将其传递给其他BGP对等方，并且属性标志八位字节中的部分位由某个先前的AS设置为1，则当前AS不得将其设置回0。无法识别的非传递可选属性必须悄悄忽略，并且不能传递给其他BGP对等方。
New, transitive optional attributes MAY be attached to the path by the originator or by any other BGP speaker in the path. If they are not attached by the originator, the Partial bit in the Attribute Flags octet is set to 1. The rules for attaching new non-transitive optional attributes will depend on the nature of the specific attribute. The documentation of each new non-transitive optional attribute will be expected to include such rules (the description of the MULTI_EXIT_DISC attribute gives an example). All optional attributes (both transitive and non-transitive), MAY be updated (if appropriate) by BGP speakers in the path.
发起者或路径中的任何其他BGP演讲者可以将新的可传递可选属性附加到路径。如果发起者未附加它们，则属性标志八位字节中的部分位设置为1。附加新的非传递可选属性的规则将取决于特定属性的性质。每个新的非传递性可选属性的文档都应包含此类规则（MULTI_EXIT_DISC属性的描述给出了一个示例）。所有可选属性（可传递和不可传递）可由路径中的BGP扬声器更新（如果适用）。
The sender of an UPDATE message SHOULD order path attributes within the UPDATE message in ascending order of attribute type. The receiver of an UPDATE message MUST be prepared to handle path attributes within UPDATE messages that are out of order.
更新消息的发件人应按属性类型的升序排列更新消息中的路径属性。更新消息的接收者必须准备好处理顺序错误的更新消息中的路径属性。
The same attribute (attribute with the same type) cannot appear more than once within the Path Attributes field of a particular UPDATE message.
同一属性（具有相同类型的属性）不能在特定更新消息的路径属性字段中出现多次。
The mandatory category refers to an attribute that MUST be present in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE message. Attributes classified as optional for the purpose of the protocol extension mechanism may be purely discretionary, discretionary, required, or disallowed in certain contexts.
如果更新消息中包含NLRI，则强制类别是指IBGP和EBGP交换中必须存在的属性。出于协议扩展机制的目的，被归类为可选的属性在某些情况下可能是完全自由裁量、自由裁量、必需或不允许的。
attribute EBGP IBGP ORIGIN mandatory mandatory AS_PATH mandatory mandatory NEXT_HOP mandatory mandatory MULTI_EXIT_DISC discretionary discretionary LOCAL_PREF see Section 5.1.5 required ATOMIC_AGGREGATE see Section 5.1.6 and 9.1.4 AGGREGATOR discretionary discretionary
属性EBGP IBGP ORIGIN mandatory AS_PATH mandatory NEXT_HOP mandatory MULTI_EXIT_DISC decreative LOCAL_PREF见第5.1.5节所需原子聚合见第5.1.6节和第9.1.4节聚合器decreative decreative
The usage of each BGP path attribute is described in the following clauses.
每个BGP路径属性的用法在以下条款中描述。
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is generated by the speaker that originates the associated routing information. Its value SHOULD NOT be changed by any other speaker.
来源是一个众所周知的强制属性。“来源”属性由发出相关路由信息的说话人生成。它的价值不应被任何其他发言者改变。
AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. The components of this list can be AS_SETs or AS_SEQUENCEs.
AS_PATH是众所周知的强制属性。此属性标识此更新消息中包含的路由信息所经过的自治系统。此列表的组件可以是作为\u集合或作为\u序列。
When a BGP speaker propagates a route it learned from another BGP speaker's UPDATE message, it modifies the route's AS_PATH attribute based on the location of the BGP speaker to which the route will be sent:
当一个BGP扬声器传播它从另一个BGP扬声器的更新消息中学习到的路由时，它会根据路由将被发送到的BGP扬声器的位置修改路由的AS_PATH属性：
a) When a given BGP speaker advertises the route to an internal peer, the advertising speaker SHALL NOT modify the AS_PATH attribute associated with the route.
a) 当给定BGP演讲者向内部对等方播发路由时，播发演讲者不得修改与路由相关联的AS_路径属性。
b) When a given BGP speaker advertises the route to an external peer, the advertising speaker updates the AS_PATH attribute as follows:
b) 当给定BGP演讲者向外部对等方播发路由时，播发演讲者更新AS_PATH属性，如下所示：
1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message). If the act of prepending will cause an overflow in the AS_PATH segment (i.e., more than 255 ASes), it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment.
1) 如果AS_路径的第一个路径段属于AS_序列类型，则本地系统将其自身的AS编号作为序列的最后一个元素（将其置于协议消息中八位字节位置的最左侧位置）。如果预编操作将导致AS_路径段溢出（即超过255个ASE），则应预编AS_序列类型的新段，并将其自身的AS编号预编到此新段。
2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment.
2) 如果AS_路径的第一个路径段的类型为AS_SET，则本地系统将AS_序列类型的新路径段前置到AS_路径，包括该段中自己的AS编号。
3) if the AS_PATH is empty, the local system creates a path segment of type AS_SEQUENCE, places its own AS into that segment, and places that segment into the AS_PATH.
3) 如果AS_路径为空，则本地系统将创建一个AS_序列类型的路径段，将其自身的AS放置到该段中，并将该段放置到AS_路径中。
When a BGP speaker originates a route then:
当BGP扬声器发起路由时，则：
a) the originating speaker includes its own AS number in a path segment, of type AS_SEQUENCE, in the AS_PATH attribute of all UPDATE messages sent to an external peer. In this case, the AS number of the originating speaker's autonomous system will be the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute.
a) 发端说话人在发送到外部对等方的所有更新消息的AS_路径属性中，在路径段中包含自己的AS编号，类型为AS_序列。在这种情况下，原始说话人自治系统的AS编号将是路径段的唯一条目，并且该路径段将是AS_路径属性中的唯一段。
b) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to internal peers. (An empty AS_PATH attribute is one whose length field contains the value zero).
b) 原始说话人在发送给内部对等方的所有更新消息中都包含一个空AS_PATH属性。（空AS_PATH属性是其长度字段包含值零的属性）。
Whenever the modification of the AS_PATH attribute calls for including or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration.
每当AS_PATH属性的修改需要包含或预先添加本地系统的AS编号时，本地系统可以在AS_PATH属性中包含/预先添加其自身AS编号的多个实例。这是通过本地配置控制的。
The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the destinations listed in the UPDATE message. The NEXT_HOP attribute is calculated as follows:
下一个跃点是一个众所周知的强制属性，它定义了路由器的IP地址，该地址应该用作更新消息中列出的目的地的下一个跃点。下一跳属性的计算如下：
1) When sending a message to an internal peer, if the route is not locally originated, the BGP speaker SHOULD NOT modify the NEXT_HOP attribute unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. When announcing a
1) 向内部对等方发送消息时，如果路由不是本地发起的，则BGP说话者不应修改“下一跳”属性，除非已明确配置为将其自己的IP地址宣布为下一跳。在宣布
locally-originated route to an internal peer, the BGP speaker SHOULD use the interface address of the router through which the announced network is reachable for the speaker as the NEXT_HOP. If the route is directly connected to the speaker, or if the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, then the BGP speaker SHOULD use its own IP address for the NEXT_HOP attribute (the address of the interface that is used to reach the peer).
本地发起到内部对等方的路由，BGP扬声器应使用路由器的接口地址作为下一跳，通过该地址，扬声器可以到达宣布的网络。如果路由直接连接到扬声器，或者如果扬声器可通过路由器访问宣布的网络的接口地址是内部对等方的地址，则BGP扬声器应使用其自己的IP地址作为下一跳属性（用于到达对等方的接口地址）。
2) When sending a message to an external peer, X, and the peer is one IP hop away from the speaker:
2) 向外部对等方X发送消息时，该对等方距离扬声器一个IP跃点：
- If the route being announced was learned from an internal peer or is locally originated, the BGP speaker can use an interface address of the internal peer router (or the internal router) through which the announced network is reachable for the speaker for the NEXT_HOP attribute, provided that peer X shares a common subnet with this address. This is a form of "third party" NEXT_HOP attribute.
- 如果正在宣布的路由是从内部对等方获悉的或是本地发起的，则BGP扬声器可以使用内部对等方路由器（或内部路由器）的接口地址，通过该地址，扬声器可以通过下一跳属性访问宣布的网络，前提是对等方X与该地址共享一个公共子网。这是“第三方”下一跳属性的一种形式。
- Otherwise, if the route being announced was learned from an external peer, the speaker can use an IP address of any adjacent router (known from the received NEXT_HOP attribute) that the speaker itself uses for local route calculation in the NEXT_HOP attribute, provided that peer X shares a common subnet with this address. This is a second form of "third party" NEXT_HOP attribute.
- 否则，如果正在宣布的路由是从外部对等方获悉的，则说话人可以使用任何相邻路由器的IP地址（从接收到的下一跳属性知道），说话人自己在下一跳属性中使用该IP地址进行本地路由计算，前提是对等方X与该地址共享一个公共子网。这是“第三方”下一跳属性的第二种形式。
- Otherwise, if the external peer to which the route is being advertised shares a common subnet with one of the interfaces of the announcing BGP speaker, the speaker MAY use the IP address associated with such an interface in the NEXT_HOP attribute. This is known as a "first party" NEXT_HOP attribute.
- 否则，如果正在播发路由的外部对等方与宣布的BGP扬声器的一个接口共享公共子网，则扬声器可以在下一跳属性中使用与该接口相关联的IP地址。这称为“第一方”下一跳属性。
- By default (if none of the above conditions apply), the BGP speaker SHOULD use the IP address of the interface that the speaker uses to establish the BGP connection to peer X in the NEXT_HOP attribute.
- 默认情况下（如果上述条件均不适用），BGP扬声器应使用接口的IP地址，该接口用于在下一跳属性中建立BGP与对等方X的连接。
3) When sending a message to an external peer X, and the peer is multiple IP hops away from the speaker (aka "multihop EBGP"):
3) 向外部对等方X发送消息时，该对等方距离扬声器有多个IP跃点（也称为“多跳EBGP”）：
- The speaker MAY be configured to propagate the NEXT_HOP attribute. In this case, when advertising a route that the speaker learned from one of its peers, the NEXT_HOP attribute of the advertised route is exactly the same as the NEXT_HOP
- 扬声器可被配置为传播下一跳属性。在这种情况下，当播发说话人从其一个对等方学习的路由时，播发路由的下一跳属性与下一跳完全相同
attribute of the learned route (the speaker does not modify the NEXT_HOP attribute).
已学习路线的属性（说话者不修改下一跳属性）。
- By default, the BGP speaker SHOULD use the IP address of the interface that the speaker uses in the NEXT_HOP attribute to establish the BGP connection to peer X.
- 默认情况下，BGP扬声器应使用扬声器在下一跳属性中使用的接口的IP地址来建立与对等X的BGP连接。
Normally, the NEXT_HOP attribute is chosen such that the shortest available path will be taken. A BGP speaker MUST be able to support the disabling advertisement of third party NEXT_HOP attributes in order to handle imperfectly bridged media.
通常，选择“下一跳”属性时，将采用最短的可用路径。BGP扬声器必须能够支持禁用第三方下一跳属性的广告，以便处理未完全桥接的媒体。
A route originated by a BGP speaker SHALL NOT be advertised to a peer using an address of that peer as NEXT_HOP. A BGP speaker SHALL NOT install a route with itself as the next hop.
BGP演讲者发起的路由不得使用对等方的地址作为下一跳向该对等方播发。BGP扬声器不得安装自身作为下一跳的路由。
The NEXT_HOP attribute is used by the BGP speaker to determine the actual outbound interface and immediate next-hop address that SHOULD be used to forward transit packets to the associated destinations.
BGP演讲者使用“下一跳”属性来确定实际出站接口和立即下一跳地址，该地址应用于将传输数据包转发到相关目的地。
The immediate next-hop address is determined by performing a recursive route lookup operation for the IP address in the NEXT_HOP attribute, using the contents of the Routing Table, selecting one entry if multiple entries of equal cost exist. The Routing Table entry that resolves the IP address in the NEXT_HOP attribute will always specify the outbound interface. If the entry specifies an attached subnet, but does not specify a next-hop address, then the address in the NEXT_HOP attribute SHOULD be used as the immediate next-hop address. If the entry also specifies the next-hop address, this address SHOULD be used as the immediate next-hop address for packet forwarding.
立即下一跳地址是通过使用路由表的内容，在下一跳属性中对IP地址执行递归路由查找操作来确定的，如果存在多个成本相等的条目，则选择一个条目。在下一跳属性中解析IP地址的路由表条目将始终指定出站接口。如果条目指定了连接的子网，但未指定下一跳地址，则下一跳属性中的地址应用作直接下一跳地址。如果条目还指定下一跳地址，则该地址应用作数据包转发的直接下一跳地址。
The MULTI_EXIT_DISC is an optional non-transitive attribute that is intended to be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four-octet unsigned number, called a metric. All other factors being equal, the exit point with the lower metric SHOULD be preferred. If received over EBGP, the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to other BGP speakers within the same AS (see also 9.1.2.2). The MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be propagated to other neighboring ASes.
MULTI_EXIT_DISC是一个可选的非传递属性，用于外部（AS间）链接，以区分到同一相邻AS的多个出口或入口点。MULTI_EXIT_DISC属性的值是一个四个八位组的无符号数，称为度量。在所有其他因素相同的情况下，应首选具有较低度量的出口点。如果通过EBGP接收，则可以通过IBGP将MULTI_EXIT_DISC属性传播到与相同系统内的其他BGP扬声器（另请参见9.1.2.2）。从相邻AS接收的MULTI_EXIT_DISC属性不得传播到其他相邻AS。
A BGP speaker MUST implement a mechanism (based on local configuration) that allows the MULTI_EXIT_DISC attribute to be removed from a route. If a BGP speaker is configured to remove the
BGP扬声器必须实现一种机制（基于本地配置），允许从路由中删除MULTI_EXIT_DISC属性。如果BGP扬声器配置为卸下
MULTI_EXIT_DISC attribute from a route, then this removal MUST be done prior to determining the degree of preference of the route and prior to performing route selection (Decision Process phases 1 and 2).
从路线中选择多个退出盘属性，则必须在确定路线的偏好程度之前以及在执行路线选择之前（决策过程阶段1和2）进行删除。
An implementation MAY also (based on local configuration) alter the value of the MULTI_EXIT_DISC attribute received over EBGP. If a BGP speaker is configured to alter the value of the MULTI_EXIT_DISC attribute received over EBGP, then altering the value MUST be done prior to determining the degree of preference of the route and prior to performing route selection (Decision Process phases 1 and 2). See Section 9.1.2.2 for necessary restrictions on this.
实现还可以（基于本地配置）更改通过EBGP接收的MULTI_EXIT_DISC属性的值。如果BGP扬声器被配置为改变通过EBGP接收的MULTI_EXIT_DISC属性的值，则必须在确定路由的偏好程度和执行路由选择之前改变该值（决策过程阶段1和2）。有关这方面的必要限制，请参见第9.1.2.2节。
LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers. A BGP speaker SHALL calculate the degree of preference for each external route based on the locally-configured policy, and include the degree of preference when advertising a route to its internal peers. The higher degree of preference MUST be preferred. A BGP speaker uses the degree of preference learned via LOCAL_PREF in its Decision Process (see Section 9.1.1).
LOCAL_PREF是一个众所周知的属性，该属性应包含在给定BGP演讲者发送给其他内部对等方的所有更新消息中。BGP演讲者应根据本地配置的策略计算每个外部路由的偏好度，并在向其内部对等方公布路由时包括偏好度。必须优先考虑更高程度的偏好。BGP演讲者在其决策过程中使用通过LOCAL_PREF学习的偏好度（见第9.1.1节）。
A BGP speaker MUST NOT include this attribute in UPDATE messages it sends to external peers, except in the case of BGP Confederations [RFC3065]. If it is contained in an UPDATE message that is received from an external peer, then this attribute MUST be ignored by the receiving speaker, except in the case of BGP Confederations [RFC3065].
BGP演讲者不得在发送给外部对等方的更新消息中包含此属性，BGP联合会的情况除外[RFC3065]。如果该属性包含在从外部对等方接收的更新消息中，则接收扬声器必须忽略该属性，但BGP联合会的情况除外[RFC3065]。
ATOMIC_AGGREGATE is a well-known discretionary attribute.
原子聚合是一个众所周知的自由裁量属性。
When a BGP speaker aggregates several routes for the purpose of advertisement to a particular peer, the AS_PATH of the aggregated route normally includes an AS_SET formed from the set of ASes from which the aggregate was formed. In many cases, the network administrator can determine if the aggregate can safely be advertised without the AS_SET, and without forming route loops.
当BGP演讲者为了向特定对等方播发的目的聚合多个路由时，聚合路由的AS_路径通常包括从形成聚合的ase集合形成的AS_集合。在许多情况下，网络管理员可以确定聚合是否可以在没有AS_集合和不形成路由循环的情况下安全地发布。
If an aggregate excludes at least some of the AS numbers present in the AS_PATH of the routes that are aggregated as a result of dropping the AS_SET, the aggregated route, when advertised to the peer, SHOULD include the ATOMIC_AGGREGATE attribute.
如果聚合排除了由于删除AS_集而聚合的路由的AS_路径中存在的至少一些AS编号，则当向对等方播发时，聚合路由应包括原子_聚合属性。
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute SHOULD NOT remove the attribute when propagating the route to other speakers.
接收具有原子_聚合属性的路由的BGP扬声器在向其他扬声器传播路由时不应删除该属性。
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers.
接收具有原子_聚合属性的路由的BGP扬声器在向其他BGP扬声器宣传该路由时，不得使该路由的任何NLRI更具体（如9.1.4中所定义）。
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute needs to be aware of the fact that the actual path to destinations, as specified in the NLRI of the route, while having the loop-free property, may not be the path specified in the AS_PATH attribute of the route.
接收具有原子_聚合属性的路由的BGP说话者需要知道这样一个事实：路由的NLRI中指定的到达目的地的实际路径虽然具有无循环属性，但可能不是路由的as_路径属性中指定的路径。
AGGREGATOR is an optional transitive attribute, which MAY be included in updates that are formed by aggregation (see Section 9.2.2.2). A BGP speaker that performs route aggregation MAY add the AGGREGATOR attribute, which SHALL contain its own AS number and IP address. The IP address SHOULD be the same as the BGP Identifier of the speaker.
聚合器是可选的可传递属性，可包含在聚合形成的更新中（见第9.2.2.2节）。执行路由聚合的BGP扬声器可以添加聚合器属性，该属性应包含其自身的AS编号和IP地址。IP地址应与说话人的BGP标识符相同。
6. BGP Error Handling.
6. BGP错误处理。
This section describes actions to be taken when errors are detected while processing BGP messages.
本节描述在处理BGP消息时检测到错误时要采取的操作。
When any of the conditions described here are detected, a NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed (unless it is explicitly stated that no NOTIFICATION message is to be sent and the BGP connection is not to be closed). If no Error Subcode is specified, then a zero MUST be used.
当检测到此处描述的任何情况时，将发送一条通知消息，其中包含指示的错误代码、错误子代码和数据字段，并关闭BGP连接（除非明确说明不发送通知消息且不关闭BGP连接）。如果未指定错误子代码，则必须使用零。
The phrase "the BGP connection is closed" means the TCP connection has been closed, the associated Adj-RIB-In has been cleared, and all resources for that BGP connection have been deallocated. Entries in the Loc-RIB associated with the remote peer are marked as invalid. The local system recalculates its best routes for the destinations of the routes marked as invalid. Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes before the invalid routes are deleted from the system.
短语“BGP连接已关闭”表示TCP连接已关闭，关联的Adj RIB In已清除，且该BGP连接的所有资源已释放。Loc RIB中与远程对等机关联的条目被标记为无效。对于标记为无效的路由目的地，本地系统重新计算其最佳路由。在从系统中删除无效路由之前，它向其对等方播发退出标记为无效的路由，或者在从系统中删除无效路由之前播发新的最佳路由。
Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error is empty.
除非明确指定，否则发送用于指示错误的通知消息的数据字段为空。
All errors detected while processing the Message Header MUST be indicated by sending the NOTIFICATION message with the Error Code Message Header Error. The Error Subcode elaborates on the specific nature of the error.
处理消息头时检测到的所有错误必须通过发送带有错误代码消息头错误的通知消息来指示。错误子代码详细说明了错误的具体性质。
The expected value of the Marker field of the message header is all ones. If the Marker field of the message header is not as expected, then a synchronization error has occurred and the Error Subcode MUST be set to Connection Not Synchronized.
消息头的标记字段的预期值为“全1”。如果消息头的标记字段不符合预期，则发生同步错误，错误子代码必须设置为Connection not Synchronized（连接未同步）。
If at least one of the following is true:
如果以下至少一项为真：
- if the Length field of the message header is less than 19 or greater than 4096, or
- 如果消息头的长度字段小于19或大于4096，或
- if the Length field of an OPEN message is less than the minimum length of the OPEN message, or
- 如果打开邮件的长度字段小于打开邮件的最小长度，或
- if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or
- 如果更新消息的长度字段小于更新消息的最小长度，或
- if the Length field of a KEEPALIVE message is not equal to 19, or
- 如果KEEPALIVE消息的长度字段不等于19，或
- if the Length field of a NOTIFICATION message is less than the minimum length of the NOTIFICATION message,
- 如果通知消息的长度字段小于通知消息的最小长度，
then the Error Subcode MUST be set to Bad Message Length. The Data field MUST contain the erroneous Length field.
然后，必须将错误子代码设置为错误消息长度。数据字段必须包含错误的长度字段。
If the Type field of the message header is not recognized, then the Error Subcode MUST be set to Bad Message Type. The Data field MUST contain the erroneous Type field.
如果无法识别消息头的类型字段，则必须将错误子代码设置为错误消息类型。数据字段必须包含错误的类型字段。
All errors detected while processing the OPEN message MUST be indicated by sending the NOTIFICATION message with the Error Code OPEN Message Error. The Error Subcode elaborates on the specific nature of the error.
处理打开的消息时检测到的所有错误必须通过发送带有错误代码OPEN message Error的通知消息来指示。错误子代码详细说明了错误的具体性质。
If the version number in the Version field of the received OPEN message is not supported, then the Error Subcode MUST be set to Unsupported Version Number. The Data field is a 2-octet unsigned integer, which indicates the largest, locally-supported version number less than the version the remote BGP peer bid (as indicated in
如果不支持接收到的打开消息的版本字段中的版本号，则必须将错误子代码设置为不支持的版本号。数据字段是一个2-octet无符号整数，表示本地支持的最大版本号小于远程BGP对等出价的版本号（如中所示）
the received OPEN message), or if the smallest, locally-supported version number is greater than the version the remote BGP peer bid, then the smallest, locally-supported version number.
收到的打开消息），或者如果本地支持的最小版本号大于远程BGP对等出价的版本号，则为本地支持的最小版本号。
If the Autonomous System field of the OPEN message is unacceptable, then the Error Subcode MUST be set to Bad Peer AS. The determination of acceptable Autonomous System numbers is outside the scope of this protocol.
如果打开消息的自治系统字段不可接受，则必须将错误子代码设置为Bad Peer AS。可接受的自主系统编号的确定不在本协议的范围内。
If the Hold Time field of the OPEN message is unacceptable, then the Error Subcode MUST be set to Unacceptable Hold Time. An implementation MUST reject Hold Time values of one or two seconds. An implementation MAY reject any proposed Hold Time. An implementation that accepts a Hold Time MUST use the negotiated value for the Hold Time.
如果打开消息的保持时间字段不可接受，则必须将错误子代码设置为不可接受的保持时间。实现必须拒绝一秒或两秒的保持时间值。实施可以拒绝任何提议的保持时间。接受保留时间的实现必须使用保留时间的协商值。
If the BGP Identifier field of the OPEN message is syntactically incorrect, then the Error Subcode MUST be set to Bad BGP Identifier. Syntactic correctness means that the BGP Identifier field represents a valid unicast IP host address.
如果打开消息的BGP标识符字段在语法上不正确，则必须将错误子代码设置为坏BGP标识符。语法正确性意味着BGP标识符字段表示有效的单播IP主机地址。
If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode MUST be set to Unsupported Optional Parameters.
如果无法识别打开消息中的一个可选参数，则必须将错误子代码设置为不受支持的可选参数。
If one of the Optional Parameters in the OPEN message is recognized, but is malformed, then the Error Subcode MUST be set to 0 (Unspecific).
如果已识别OPEN消息中的一个可选参数，但其格式不正确，则必须将错误子代码设置为0（非特定）。
All errors detected while processing the UPDATE message MUST be indicated by sending the NOTIFICATION message with the Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error.
处理更新消息时检测到的所有错误都必须通过发送带有错误代码UPDATE message Error的通知消息来指示。错误子代码详细说明了错误的具体性质。
Error checking of an UPDATE message begins by examining the path attributes. If the Withdrawn Routes Length or Total Attribute Length is too large (i.e., if Withdrawn Routes Length + Total Attribute Length + 23 exceeds the message Length), then the Error Subcode MUST be set to Malformed Attribute List.
更新消息的错误检查从检查路径属性开始。如果撤回的路由长度或总属性长度太大（即，如果撤回的路由长度+总属性长度+23超过消息长度），则必须将错误子代码设置为格式错误的属性列表。
If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode MUST be set to Attribute Flags Error. The Data field MUST contain the erroneous attribute (type, length, and value).
如果任何已识别的属性具有与属性类型代码冲突的属性标志，则必须将错误子代码设置为属性标志错误。数据字段必须包含错误的属性（类型、长度和值）。
If any recognized attribute has an Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode MUST be set to Attribute Length Error. The Data field MUST contain the erroneous attribute (type, length, and value).
如果任何已识别属性的属性长度与预期长度冲突（基于属性类型代码），则必须将错误子代码设置为属性长度错误。数据字段必须包含错误的属性（类型、长度和值）。
If any of the well-known mandatory attributes are not present, then the Error Subcode MUST be set to Missing Well-known Attribute. The Data field MUST contain the Attribute Type Code of the missing, well-known attribute.
如果任何已知的强制属性不存在，则必须将错误子代码设置为缺少已知属性。数据字段必须包含缺少的已知属性的属性类型代码。
If any of the well-known mandatory attributes are not recognized, then the Error Subcode MUST be set to Unrecognized Well-known Attribute. The Data field MUST contain the unrecognized attribute (type, length, and value).
如果无法识别任何已知的强制属性，则必须将错误子代码设置为无法识别的已知属性。数据字段必须包含无法识别的属性（类型、长度和值）。
If the ORIGIN attribute has an undefined value, then the Error Sub-code MUST be set to Invalid Origin Attribute. The Data field MUST contain the unrecognized attribute (type, length, and value).
如果原点属性具有未定义的值，则必须将错误子代码设置为无效的原点属性。数据字段必须包含无法识别的属性（类型、长度和值）。
If the NEXT_HOP attribute field is syntactically incorrect, then the Error Subcode MUST be set to Invalid NEXT_HOP Attribute. The Data field MUST contain the incorrect attribute (type, length, and value). Syntactic correctness means that the NEXT_HOP attribute represents a valid IP host address.
如果下一跳属性字段语法不正确，则必须将错误子代码设置为无效的下一跳属性。数据字段必须包含不正确的属性（类型、长度和值）。语法正确性意味着NEXT_HOP属性表示有效的IP主机地址。
The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct:
下一跳中的IP地址必须满足以下标准才能被视为语义正确：
a) It MUST NOT be the IP address of the receiving speaker.
a) 它不能是接收扬声器的IP地址。
b) In the case of an EBGP, where the sender and receiver are one IP hop away from each other, either the IP address in the NEXT_HOP MUST be the sender's IP address that is used to establish the BGP connection, or the interface associated with the NEXT_HOP IP address MUST share a common subnet with the receiving BGP speaker.
b) 对于EBGP，如果发送方和接收方彼此相距一个IP跳，则下一跳中的IP地址必须是用于建立BGP连接的发送方IP地址，或者与下一跳IP地址相关联的接口必须与接收BGP扬声器共享一个公共子网。
If the NEXT_HOP attribute is semantically incorrect, the error SHOULD be logged, and the route SHOULD be ignored. In this case, a NOTIFICATION message SHOULD NOT be sent, and the connection SHOULD NOT be closed.
如果NEXT_HOP属性在语义上不正确，则应记录错误，并忽略路由。在这种情况下，不应发送通知消息，也不应关闭连接。
The AS_PATH attribute is checked for syntactic correctness. If the path is syntactically incorrect, then the Error Subcode MUST be set to Malformed AS_PATH.
将检查AS_PATH属性的语法正确性。如果路径在语法上不正确，则必须将错误子代码设置为格式错误的AS\U path。
If the UPDATE message is received from an external peer, the local system MAY check whether the leftmost (with respect to the position of octets in the protocol message) AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message. If the check determines this is not the case, the Error Subcode MUST be set to Malformed AS_PATH.
如果从外部对等方接收到更新消息，则本地系统可检查AS_PATH属性中最左侧（相对于协议消息中的八位字节位置）AS是否等于发送消息的对等方的自治系统编号。如果检查确定情况并非如此，则必须将错误子代码设置为格式错误的AS_路径。
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value).
如果识别出可选属性，则必须检查该属性的值。如果检测到错误，则必须放弃该属性，并且必须将错误子代码设置为可选属性错误。数据字段必须包含属性（类型、长度和值）。
If any attribute appears more than once in the UPDATE message, then the Error Subcode MUST be set to Malformed Attribute List.
如果任何属性在更新消息中出现多次，则必须将错误子代码设置为格式不正确的属性列表。
The NLRI field in the UPDATE message is checked for syntactic validity. If the field is syntactically incorrect, then the Error Subcode MUST be set to Invalid Network Field.
检查更新消息中的NLRI字段的语法有效性。如果字段语法不正确，则必须将错误子代码设置为无效网络字段。
If a prefix in the NLRI field is semantically incorrect (e.g., an unexpected multicast IP address), an error SHOULD be logged locally, and the prefix SHOULD be ignored.
如果NLRI字段中的前缀在语义上不正确（例如，意外的多播IP地址），则应在本地记录错误，并且应忽略前缀。
An UPDATE message that contains correct path attributes, but no NLRI, SHALL be treated as a valid UPDATE message.
包含正确路径属性但没有NLRI的更新消息应视为有效的更新消息。
If a peer sends a NOTIFICATION message, and the receiver of the message detects an error in that message, the receiver cannot use a NOTIFICATION message to report this error back to the peer. Any such error (e.g., an unrecognized Error Code or Error Subcode) SHOULD be noticed, logged locally, and brought to the attention of the administration of the peer. The means to do this, however, lies outside the scope of this document.
如果对等方发送通知消息，且消息接收方检测到该消息中存在错误，则接收方无法使用通知消息将此错误报告回对等方。应注意任何此类错误（例如，无法识别的错误代码或错误子代码），在本地记录，并提请对等方管理部门注意。然而，这样做的方法不在本文件的范围之内。
If a system does not receive successive KEEPALIVE, UPDATE, and/or NOTIFICATION messages within the period specified in the Hold Time field of the OPEN message, then the NOTIFICATION message with the Hold Timer Expired Error Code is sent and the BGP connection is closed.
如果系统在打开消息的保持时间字段中指定的时间段内未接收到连续的KEEPALIVE、UPDATE和/或通知消息，则发送带有保持计时器过期错误代码的通知消息，并关闭BGP连接。
Any error detected by the BGP Finite State Machine (e.g., receipt of an unexpected event) is indicated by sending the NOTIFICATION message with the Error Code Finite State Machine Error.
BGP有限状态机检测到的任何错误（例如，收到意外事件）通过发送带有错误代码有限状态机错误的通知消息来指示。
In the absence of any fatal errors (that are indicated in this section), a BGP peer MAY choose, at any given time, to close its BGP connection by sending the NOTIFICATION message with the Error Code Cease. However, the Cease NOTIFICATION message MUST NOT be used when a fatal error indicated by this section does exist.
在没有任何致命错误（本节中指出）的情况下，BGP对等方可以在任何给定时间通过发送带有错误代码STOP的通知消息来选择关闭其BGP连接。但是，当本节指示的致命错误确实存在时，不得使用停止通知消息。
A BGP speaker MAY support the ability to impose a locally-configured, upper bound on the number of address prefixes the speaker is willing to accept from a neighbor. When the upper bound is reached, the speaker, under control of local configuration, either (a) discards new address prefixes from the neighbor (while maintaining the BGP connection with the neighbor), or (b) terminates the BGP connection with the neighbor. If the BGP speaker decides to terminate its BGP connection with a neighbor because the number of address prefixes received from the neighbor exceeds the locally-configured, upper bound, then the speaker MUST send the neighbor a NOTIFICATION message with the Error Code Cease. The speaker MAY also log this locally.
BGP演讲者可以支持对演讲者愿意从邻居接受的地址前缀的数量施加本地配置的上限的能力。当达到上限时，说话人在本地配置的控制下，（a）丢弃邻居的新地址前缀（同时保持与邻居的BGP连接），或（b）终止与邻居的BGP连接。如果BGP演讲者决定终止其与邻居的BGP连接，因为从邻居接收的地址前缀数量超过了本地配置的上限，则演讲者必须向邻居发送带有错误代码STOP的通知消息。演讲者也可以将此记录在本地。
If a pair of BGP speakers try to establish a BGP connection with each other simultaneously, then two parallel connections well be formed. If the source IP address used by one of these connections is the same as the destination IP address used by the other, and the destination IP address used by the first connection is the same as the source IP address used by the other, connection collision has occurred. In the event of connection collision, one of the connections MUST be closed.
如果一对BGP扬声器试图同时彼此建立BGP连接，则很可能形成两个并行连接。如果其中一个连接使用的源IP地址与另一个连接使用的目标IP地址相同，并且第一个连接使用的目标IP地址与另一个连接使用的源IP地址相同，则会发生连接冲突。在连接冲突的情况下，必须关闭其中一个连接。
Based on the value of the BGP Identifier, a convention is established for detecting which BGP connection is to be preserved when a collision occurs. The convention is to compare the BGP Identifiers of the peers involved in the collision and to retain only the connection initiated by the BGP speaker with the higher-valued BGP Identifier.
基于BGP标识符的值，建立了一种约定，用于在发生冲突时检测要保留的BGP连接。该约定是比较参与冲突的对等方的BGP标识符，并仅保留由BGP说话人启动的连接与更高值的BGP标识符。
Upon receipt of an OPEN message, the local system MUST examine all of its connections that are in the OpenConfirm state. A BGP speaker MAY also examine connections in an OpenSent state if it knows the BGP Identifier of the peer by means outside of the protocol. If, among these connections, there is a connection to a remote BGP speaker
收到打开的消息后，本地系统必须检查所有处于OpenConfirm状态的连接。如果BGP说话者通过协议之外的方式知道对等方的BGP标识符，则也可以在OpenSent状态下检查连接。如果在这些连接中，存在到远程BGP扬声器的连接
whose BGP Identifier equals the one in the OPEN message, and this connection collides with the connection over which the OPEN message is received, then the local system performs the following collision resolution procedure:
其BGP标识符等于打开消息中的BGP标识符，并且此连接与接收打开消息的连接冲突，则本地系统执行以下冲突解决过程：
1) The BGP Identifier of the local system is compared to the BGP Identifier of the remote system (as specified in the OPEN message). Comparing BGP Identifiers is done by converting them to host byte order and treating them as 4-octet unsigned integers.
1) 将本地系统的BGP标识符与远程系统的BGP标识符进行比较（如打开消息中所指定）。比较BGP标识符的方法是将它们转换为主机字节顺序，并将它们视为4个八位无符号整数。
2) If the value of the local BGP Identifier is less than the remote one, the local system closes the BGP connection that already exists (the one that is already in the OpenConfirm state), and accepts the BGP connection initiated by the remote system.
2) 如果本地BGP标识符的值小于远程BGP标识符的值，则本地系统关闭已存在的BGP连接（已处于OpenConfirm状态的BGP连接），并接受远程系统启动的BGP连接。
3) Otherwise, the local system closes the newly created BGP connection (the one associated with the newly received OPEN message), and continues to use the existing one (the one that is already in the OpenConfirm state).
3) 否则，本地系统将关闭新创建的BGP连接（与新接收到的打开消息相关联的连接），并继续使用现有连接（已处于OpenConfirm状态的连接）。
Unless allowed via configuration, a connection collision with an existing BGP connection that is in the Established state causes closing of the newly created connection.
除非通过配置允许，否则与处于已建立状态的现有BGP连接的连接冲突将导致关闭新创建的连接。
Note that a connection collision cannot be detected with connections that are in Idle, Connect, or Active states.
请注意，对于处于空闲、连接或活动状态的连接，无法检测到连接冲突。
Closing the BGP connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
关闭BGP连接（由冲突解决过程产生）是通过发送带有错误代码STOP的通知消息来完成的。
BGP speakers MAY negotiate the version of the protocol by making multiple attempts at opening a BGP connection, starting with the highest version number each BGP speaker supports. If an open attempt fails with an Error Code, OPEN Message Error, and an Error Subcode, Unsupported Version Number, then the BGP speaker has available the version number it tried, the version number its peer tried, the version number passed by its peer in the NOTIFICATION message, and the version numbers it supports. If the two peers do support one or more common versions, then this will allow them to rapidly determine the highest common version. In order to support BGP version negotiation, future versions of BGP MUST retain the format of the OPEN and NOTIFICATION messages.
BGP扬声器可以通过多次尝试打开BGP连接来协商协议的版本，从每个BGP扬声器支持的最高版本号开始。如果打开尝试失败，出现错误代码、打开消息错误和错误子代码、不受支持的版本号，则BGP扬声器已提供其尝试的版本号、其对等方尝试的版本号、其对等方在通知消息中传递的版本号以及其支持的版本号。如果两个对等点确实支持一个或多个通用版本，那么这将允许它们快速确定最高的通用版本。为了支持BGP版本协商，BGP的未来版本必须保留打开和通知消息的格式。
The data structures and FSM described in this document are conceptual and do not have to be implemented precisely as described here, as long as the implementations support the described functionality and they exhibit the same externally visible behavior.
本文档中描述的数据结构和FSM是概念性的，不必像这里描述的那样精确地实现，只要实现支持所描述的功能，并且它们表现出相同的外部可见行为。
This section specifies the BGP operation in terms of a Finite State Machine (FSM). The section falls into two parts:
本节根据有限状态机（FSM）指定BGP操作。本节分为两部分：
1) Description of Events for the State machine (Section 8.1) 2) Description of the FSM (Section 8.2)
1) 状态机事件描述（第8.1节）2）FSM描述（第8.2节）
Session attributes required (mandatory) for each connection are:
每个连接所需（必需）的会话属性包括：
1) State 2) ConnectRetryCounter 3) ConnectRetryTimer 4) ConnectRetryTime 5) HoldTimer 6) HoldTime 7) KeepaliveTimer 8) KeepaliveTime
1) 状态2）ConnectRetryCounter 3）ConnectRetryTimer 4）ConnectRetryTime 5）HoldTimer 6）HoldTime 7）KeepaliveTimer 8）KeepaliveTime
The state session attribute indicates the current state of the BGP FSM. The ConnectRetryCounter indicates the number of times a BGP peer has tried to establish a peer session.
状态会话属性表示BGP FSM的当前状态。ConnectRetryCounter指示BGP对等方尝试建立对等会话的次数。
The mandatory attributes related to timers are described in Section 10. Each timer has a "timer" and a "time" (the initial value).
第10节描述了与定时器相关的强制性属性。每个计时器都有一个“计时器”和一个“时间”（初始值）。
The optional Session attributes are listed below. These optional attributes may be supported, either per connection or per local system:
下面列出了可选会话属性。每个连接或每个本地系统都可能支持以下可选属性：
1) AcceptConnectionsUnconfiguredPeers 2) AllowAutomaticStart 3) AllowAutomaticStop 4) CollisionDetectEstablishedState 5) DampPeerOscillations 6) DelayOpen 7) DelayOpenTime 8) DelayOpenTimer 9) IdleHoldTime 10) IdleHoldTimer 11) PassiveTcpEstablishment 12) SendNOTIFICATIONwithoutOPEN 13) TrackTcpState
1） AcceptConnections Unconfigured Peers 2）AllowAutomaticStart 3）AllowAutomaticStop 4）碰撞检测测试数据状态5）阻尼对等关系6）延迟打开7）延迟打开时间8）延迟打开计时器9）空闲保持时间10）空闲保持计时器11）无源CPE建立12）发送通知而不打开跟踪TCPState
The optional session attributes support different features of the BGP functionality that have implications for the BGP FSM state transitions. Two groups of the attributes which relate to timers are:
可选会话属性支持对BGP FSM状态转换有影响的BGP功能的不同功能。与计时器相关的两组属性是：
group 1: DelayOpen, DelayOpenTime, DelayOpenTimer group 2: DampPeerOscillations, IdleHoldTime, IdleHoldTimer
第1组：延迟打开、延迟打开时间、延迟打开计时器第2组：阻尼隔离、IdleHoldTime、IdleHoldTimer
The first parameter (DelayOpen, DampPeerOscillations) is an optional attribute that indicates that the Timer function is active. The "Time" value specifies the initial value for the "Timer" (DelayOpenTime, IdleHoldTime). The "Timer" specifies the actual timer.
第一个参数（DelayOpen，DampPeerOscillations）是一个可选属性，指示计时器功能处于活动状态。“时间”值指定“计时器”（DelayOpenTime、IdleHoldTime）的初始值。“计时器”指定实际计时器。
Please refer to Section 8.1.1 for an explanation of the interaction between these optional attributes and the events signaled to the state machine. Section 8.2.1.3 also provides a short overview of the different types of optional attributes (flags or timers).
请参阅第8.1.1节，以了解这些可选属性与向状态机发送信号的事件之间的交互说明。第8.2.1.3节还简要概述了不同类型的可选属性（标志或计时器）。
The Inputs to the BGP FSM are events. Events can either be mandatory or optional. Some optional events are linked to optional session attributes. Optional session attributes enable several groups of FSM functionality.
BGP FSM的输入为事件。事件可以是强制性的，也可以是可选的。某些可选事件链接到可选会话属性。可选会话属性支持多组FSM功能。
The linkage between FSM functionality, events, and the optional session attributes are described below.
FSM功能、事件和可选会话属性之间的链接如下所述。
Group 1: Automatic Administrative Events (Start/Stop)
组1：自动管理事件（启动/停止）
Optional Session Attributes: AllowAutomaticStart, AllowAutomaticStop, DampPeerOscillations, IdleHoldTime, IdleHoldTimer
可选会话属性：AllowAutomaticStart、AllowAutomaticStop、DampPeerOscillations、IdleHoldTime、IdleHoldTimer
Option 1: AllowAutomaticStart
选项1：AllowAutomaticStart
Description: A BGP peer connection can be started and stopped by administrative control. This administrative control can either be manual, based on operator intervention, or under the control of logic that is specific to a BGP implementation. The term "automatic" refers to a start being issued to the BGP peer connection FSM when such logic determines that the BGP peer connection should be restarted.
描述：管理控制可以启动和停止BGP对等连接。该管理控制可以是基于操作员干预的手动控制，也可以是特定于BGP实现的逻辑控制。术语“自动”是指当此类逻辑确定BGP对等连接应重新启动时，向BGP对等连接FSM发出的启动。
The AllowAutomaticStart attribute specifies that this BGP connection supports automatic starting of the BGP connection.
AllowAutomaticStart属性指定此BGP连接支持自动启动BGP连接。
If the BGP implementation supports AllowAutomaticStart, the peer may be repeatedly restarted. Three other options control the rate at which the automatic restart occurs: DampPeerOscillations, IdleHoldTime, and the IdleHoldTimer.
如果BGP实现支持AllowAutomaticStart，则对等机可能会重复重启。其他三个选项控制自动重启发生的速率：DampPeerOscillations、IdleHoldTime和IdleHoldTimer。
The DampPeerOscillations option specifies that the implementation engages additional logic to damp the oscillations of BGP peers in the face of sequences of automatic start and automatic stop. IdleHoldTime specifies the length of time the BGP peer is held in the Idle state prior to allowing the next automatic restart. The IdleHoldTimer is the timer that holds the peer in Idle state.
DampPeerOscillations选项指定，在自动启动和自动停止序列面前，该实现采用额外的逻辑来抑制BGP对等点的振荡。IdleHoldTime指定在允许下一次自动重启之前，BGP对等机处于空闲状态的时间长度。IdleHoldTimer是将对等方保持在空闲状态的计时器。
An example of DampPeerOscillations logic is an increase of the IdleHoldTime value if a BGP peer oscillates connectivity (connected/disconnected) repeatedly within a time period. To engage this logic, a peer could connect and disconnect 10 times within 5 minutes. The IdleHoldTime value would be reset from 0 to 120 seconds.
DampPeerOscillations逻辑的一个示例是，如果BGP对等方在一个时间段内反复振荡连接（连接/断开），IdleHoldTime值将增加。要采用这种逻辑，对等方可以在5分钟内连接和断开10次。IdleHoldTime值将从0重置为120秒。
Values: TRUE or FALSE
值：真还是假
Option 2: AllowAutomaticStop
选项2：AllowAutomaticStop
Description: This BGP peer session optional attribute indicates that the BGP connection allows "automatic" stopping of the BGP connection. An "automatic" stop is defined as a stop under the control of implementation-specific logic. The implementation-specific logic is outside the scope of this specification.
描述：此BGP对等会话可选属性表示BGP连接允许“自动”停止BGP连接。“自动”停止被定义为在特定于实现的逻辑控制下的停止。特定于实现的逻辑不在本规范的范围内。
Values: TRUE or FALSE
值：真还是假
Option 3: DampPeerOscillations
备选方案3：湿剥离
Description: The DampPeerOscillations optional session attribute indicates that the BGP connection is using logic that damps BGP peer oscillations in the Idle State.
描述：DampPeerOscillations可选会话属性表示BGP连接正在使用逻辑抑制处于空闲状态的BGP对等振荡。
Value: TRUE or FALSE
值：对还是错
Option 4: IdleHoldTime
选项4：闲置时间
Description: The IdleHoldTime is the value that is set in the IdleHoldTimer.
描述：IdleHoldTime是在IdleHoldTimer中设置的值。
Values: Time in seconds
值：以秒为单位的时间
Option 5: IdleHoldTimer
选项5：IdleHoldTimer
Description: The IdleHoldTimer aids in controlling BGP peer oscillation. The IdleHoldTimer is used to keep the BGP peer in Idle for a particular duration. The IdleHoldTimer_Expires event is described in Section 8.1.3.
描述：IdleHoldTimer有助于控制BGP对等振荡。IdleHoldTimer用于在特定的持续时间内保持BGP对等机处于空闲状态。IdleHoldTimer_Expires事件在第8.1.3节中描述。
Values: Time in seconds
值：以秒为单位的时间
Group 2: Unconfigured Peers
第2组：未配置的对等方
Optional Session Attributes: AcceptConnectionsUnconfiguredPeers
Optional Session Attributes: AcceptConnectionsUnconfiguredPeers
Option 1: AcceptConnectionsUnconfiguredPeers
Option 1: AcceptConnectionsUnconfiguredPeers
Description: The BGP FSM optionally allows the acceptance of BGP peer connections from neighbors that are not pre-configured. The "AcceptConnectionsUnconfiguredPeers" optional session attribute allows the FSM to support the state transitions that allow the implementation to accept or reject these unconfigured peers.
描述：BGP FSM可选地允许接受来自未预先配置的邻居的BGP对等连接。“AcceptConnectionsUnconfiguredPeers”可选会话属性允许FSM支持允许实现接受或拒绝这些未配置对等点的状态转换。
The AcceptConnectionsUnconfiguredPeers has security implications. Please refer to the BGP Vulnerabilities document [RFC4272] for details.
AcceptConnectionsUnconfiguredPeers具有安全隐患。有关详细信息，请参阅BGP漏洞文档[RFC4272]。
Value: True or False
值：对还是错
Group 3: TCP processing
第3组：TCP处理
Optional Session Attributes: PassiveTcpEstablishment, TrackTcpState
可选会话属性：被动设置、TrackTcpState
Option 1: PassiveTcpEstablishment
备选方案1：被动建立
Description: This option indicates that the BGP FSM will passively wait for the remote BGP peer to establish the BGP TCP connection.
描述：此选项表示BGP FSM将被动等待远程BGP对等方建立BGP TCP连接。
value: TRUE or FALSE
值：对还是错
Option 2: TrackTcpState
选项2：TrackTcpState
Description: The BGP FSM normally tracks the end result of a TCP connection attempt rather than individual TCP messages. Optionally, the BGP FSM can support additional interaction with the TCP connection negotiation. The interaction with the TCP events may increase the amount of logging the BGP peer connection requires and the number of BGP FSM changes.
描述：BGP FSM通常跟踪TCP连接尝试的最终结果，而不是单个TCP消息。可选地，BGP FSM可以支持与TCP连接协商的额外交互。与TCP事件的交互可能会增加BGP对等连接所需的日志记录量和BGP FSM更改的数量。
Value: TRUE or FALSE
值：对还是错
Group 4: BGP Message Processing
第4组：BGP消息处理
Optional Session Attributes: DelayOpen, DelayOpenTime, DelayOpenTimer, SendNOTIFICATIONwithoutOPEN, CollisionDetectEstablishedState
可选会话属性：DelayOpen、DelayOpenTime、DelayOpenTimer、SendNOTIFICATIONwithoutOPEN、CollisionDetectedTestAblishedState
Option 1: DelayOpen
选项1：延迟开放
Description: The DelayOpen optional session attribute allows implementations to be configured to delay sending an OPEN message for a specific time period (DelayOpenTime). The delay allows the remote BGP Peer time to send the first OPEN message.
描述：DelayOpen可选会话属性允许将实现配置为在特定时间段（DelayOpenTime）内延迟发送打开的消息。延迟允许远程BGP对等方有时间发送第一条打开的消息。
Value: TRUE or FALSE
值：对还是错
Option 2: DelayOpenTime
选项2：延迟开放时间
Description: The DelayOpenTime is the initial value set in the DelayOpenTimer.
说明：DelayOpenTime是DelayOpenTimer中设置的初始值。
Value: Time in seconds
值：以秒为单位的时间
Option 3: DelayOpenTimer
选项3：延迟开放计时器
Description: The DelayOpenTimer optional session attribute is used to delay the sending of an OPEN message on a
描述：DelayOpenTimer可选会话属性用于延迟服务器上打开消息的发送
connection. The DelayOpenTimer_Expires event (Event 12) is described in Section 8.1.3.
联系第8.1.3节描述了DelayOpenTimer_Expires事件（事件12）。
Value: Time in seconds
值：以秒为单位的时间
Option 4: SendNOTIFICATIONwithoutOPEN
选项4:SendNotificationWithout打开
Description: The SendNOTIFICATIONwithoutOPEN allows a peer to send a NOTIFICATION without first sending an OPEN message. Without this optional session attribute, the BGP connection assumes that an OPEN message must be sent by a peer prior to the peer sending a NOTIFICATION message.
描述：SendNOTIFICATIONwithoutOPEN允许对等方发送通知，而无需先发送打开的消息。如果没有此可选会话属性，BGP连接将假定在对等方发送通知消息之前，必须先由对等方发送打开的消息。
Value: True or False
值：对还是错
Option 5: CollisionDetectEstablishedState
选项5：碰撞检测测试状态
Description: Normally, a Detect Collision (see Section 6.8) will be ignored in the Established state. This optional session attribute indicates that this BGP connection processes collisions in the Established state.
描述：通常，在已建立状态下，检测碰撞（见第6.8节）将被忽略。此可选会话属性表示此BGP连接在已建立状态下处理冲突。
Value: True or False
值：对还是错
Note: The optional session attributes clarify the BGP FSM description for existing features of BGP implementations. The optional session attributes may be pre-defined for an implementation and not readable via management interfaces for existing correct implementations. As newer BGP MIBs (version 2 and beyond) are supported, these fields will be accessible via a management interface.
注意：可选会话属性澄清了BGP FSM对BGP实现现有功能的描述。可选会话属性可能是为实现预定义的，并且对于现有的正确实现，无法通过管理接口读取。由于支持较新的BGP MIB（版本2及更高版本），因此可以通过管理界面访问这些字段。
An administrative event is an event in which the operator interface and BGP Policy engine signal the BGP-finite state machine to start or stop the BGP state machine. The basic start and stop indications are augmented by optional connection attributes that signal a certain type of start or stop mechanism to the BGP FSM. An example of this combination is Event 5, AutomaticStart_with_PassiveTcpEstablishment. With this event, the BGP implementation signals to the BGP FSM that the implementation is using an Automatic Start with the option to use a Passive TCP Establishment. The Passive TCP establishment signals that this BGP FSM will wait for the remote side to start the TCP establishment.
管理事件是操作员界面和BGP策略引擎向BGP有限状态机发出启动或停止BGP状态机的信号的事件。基本启动和停止指示通过可选连接属性进行增强，这些属性向BGP FSM发送特定类型启动或停止机制的信号。这种组合的一个例子是事件5，AutomaticStart_与_被动设置。在该事件中，BGP实现向BGP FSM发出信号，表示该实现正在使用自动启动，并选择使用被动TCP建立。被动TCP建立表示此BGP FSM将等待远程端启动TCP建立。
Note that only Event 1 (ManualStart) and Event 2 (ManualStop) are mandatory administrative events. All other administrative events are optional (Events 3-8). Each event below has a name, definition, status (mandatory or optional), and the optional session attributes that SHOULD be set at each stage. When generating Event 1 through Event 8 for the BGP FSM, the conditions specified in the "Optional Attribute Status" section are verified. If any of these conditions are not satisfied, then the local system should log an FSM error.
请注意，只有事件1（手动启动）和事件2（手动停止）是强制性管理事件。所有其他管理事件都是可选的（事件3-8）。下面的每个事件都有名称、定义、状态（强制或可选）以及每个阶段应设置的可选会话属性。为BGP FSM生成事件1至事件8时，验证“可选属性状态”部分中指定的条件。如果不满足上述任何条件，则本地系统应记录FSM错误。
The settings of optional session attributes may be implicit in some implementations, and therefore may not be set explicitly by an external operator action. Section 8.2.1.5 describes these implicit settings of the optional session attributes. The administrative states described below may also be implicit in some implementations and not directly configurable by an external operator.
The settings of optional session attributes may be implicit in some implementations, and therefore may not be set explicitly by an external operator action. Section 8.2.1.5 describes these implicit settings of the optional session attributes. The administrative states described below may also be implicit in some implementations and not directly configurable by an external operator.translate error, please retry
Event 1: ManualStart
事件1：手动启动
Definition: Local system administrator manually starts the peer connection.
定义：本地系统管理员手动启动对等连接。
Status: Mandatory
地位：强制性
Optional Attribute Status: The PassiveTcpEstablishment attribute SHOULD be set to FALSE.
可选属性状态：被动设置属性应设置为FALSE。
Event 2: ManualStop
事件2：手动停止
Definition: Local system administrator manually stops the peer connection.
定义：本地系统管理员手动停止对等连接。
Status: Mandatory
地位：强制性
Optional Attribute Status: No interaction with any optional attributes.
可选属性状态：不与任何可选属性交互。
Event 3: AutomaticStart
事件3：自动启动
Definition: Local system automatically starts the BGP connection.
定义：本地系统自动启动BGP连接。
Status: Optional, depending on local system
状态：可选，取决于本地系统
Optional Attribute Status: 1) The AllowAutomaticStart attribute SHOULD be set to TRUE if this event occurs. 2) If the PassiveTcpEstablishment optional session attribute is supported, it SHOULD be set to FALSE. 3) If the DampPeerOscillations is supported, it SHOULD be set to FALSE when this event occurs.
可选属性状态：1）如果发生此事件，则AllowAutomaticStart属性应设置为TRUE。2） 如果支持PassivetCPEstablish可选会话属性，则应将其设置为FALSE。3） 如果支持DampPeerOscillations，则在发生此事件时应将其设置为FALSE。
Event 4: ManualStart_with_PassiveTcpEstablishment
事件4：使用被动设置手动启动
Definition: Local system administrator manually starts the peer connection, but has PassiveTcpEstablishment enabled. The PassiveTcpEstablishment optional attribute indicates that the peer will listen prior to establishing the connection.
定义：本地系统管理员手动启动对等连接，但已启用被动设置。PassivetCPEstablish可选属性表示对等方将在建立连接之前侦听。
Status: Optional, depending on local system
状态：可选，取决于本地系统
Optional Attribute Status: 1) The PassiveTcpEstablishment attribute SHOULD be set to TRUE if this event occurs. 2) The DampPeerOscillations attribute SHOULD be set to FALSE when this event occurs.
可选属性状态：1）如果发生此事件，则应将被动设置CPEstablish属性设置为TRUE。2） 发生此事件时，DampPeerOscillations属性应设置为FALSE。
Event 5: AutomaticStart_with_PassiveTcpEstablishment
事件5：自动启动与被动设置
Definition: Local system automatically starts the BGP connection with the PassiveTcpEstablishment enabled. The PassiveTcpEstablishment optional attribute indicates that the peer will listen prior to establishing a connection.
定义：本地系统在启用被动设置的情况下自动启动BGP连接。PassivetCPEstablish可选属性表示对等方将在建立连接之前侦听。
Status: Optional, depending on local system
状态：可选，取决于本地系统
Optional Attribute Status: 1) The AllowAutomaticStart attribute SHOULD be set to TRUE. 2) The PassiveTcpEstablishment attribute SHOULD be set to TRUE. 3) If the DampPeerOscillations attribute is supported, the DampPeerOscillations SHOULD be set to FALSE.
可选属性状态：1）AllowAutomaticStart属性应设置为TRUE。2） 被动设置CPEstablish属性应设置为TRUE。3） 如果支持DampPeerOscillations属性，则应将DampPeerOscillations设置为FALSE。
Event 6: AutomaticStart_with_DampPeerOscillations
事件6：自动启动，带阻尼隔离
Definition: Local system automatically starts the BGP peer connection with peer oscillation damping enabled. The exact method of damping persistent peer oscillations is determined by the implementation and is outside the scope of this document.
定义：本地系统在启用对等振荡阻尼的情况下自动启动BGP对等连接。阻尼持续对等振荡的确切方法由实现确定，不在本文档的范围内。
Status: Optional, depending on local system.
状态：可选，具体取决于本地系统。
Optional Attribute Status: 1) The AllowAutomaticStart attribute SHOULD be set to TRUE. 2) The DampPeerOscillations attribute SHOULD be set to TRUE. 3) The PassiveTcpEstablishment attribute SHOULD be set to FALSE.
可选属性状态：1）AllowAutomaticStart属性应设置为TRUE。2） DampPeerOscillations属性应设置为TRUE。3） 被动设置CPEstablish属性应设置为FALSE。
Event 7: AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment
事件7：自动启动，带阻尼隔离和被动设置
Definition: Local system automatically starts the BGP peer connection with peer oscillation damping enabled and PassiveTcpEstablishment enabled. The exact method of damping persistent peer oscillations is determined by the implementation and is outside the scope of this document.
定义：本地系统在启用对等振荡阻尼和无源建立的情况下自动启动BGP对等连接。阻尼持续对等振荡的确切方法由实现确定，不在本文档的范围内。
Status: Optional, depending on local system
状态：可选，取决于本地系统
Optional Attributes Status: 1) The AllowAutomaticStart attribute SHOULD be set to TRUE. 2) The DampPeerOscillations attribute SHOULD be set to TRUE. 3) The PassiveTcpEstablishment attribute SHOULD be set to TRUE.
可选属性状态：1）AllowAutomaticStart属性应设置为TRUE。2） DampPeerOscillations属性应设置为TRUE。3） 被动设置CPEstablish属性应设置为TRUE。
Event 8: AutomaticStop
事件8：自动停止
Definition: Local system automatically stops the BGP connection.
定义：本地系统自动停止BGP连接。
An example of an automatic stop event is exceeding the number of prefixes for a given peer and the local system automatically disconnecting the peer.
自动停止事件的一个示例是超过给定对等方的前缀数量，并且本地系统自动断开对等方的连接。
Status: Optional, depending on local system
状态：可选，取决于本地系统
Optional Attribute Status: 1) The AllowAutomaticStop attribute SHOULD be TRUE.
可选属性状态：1）AllowAutomaticStop属性应为TRUE。
Event 9: ConnectRetryTimer_Expires
事件9:ConnectRetryTimer\u过期
Definition: An event generated when the ConnectRetryTimer expires.
定义：ConnectRetryTimer过期时生成的事件。
Status: Mandatory
地位：强制性
Event 10: HoldTimer_Expires
事件10:HoldTimer\u过期
Definition: An event generated when the HoldTimer expires.
定义：HoldTimer过期时生成的事件。
Status: Mandatory
地位：强制性
Event 11: KeepaliveTimer_Expires
事件11:KeepaliveTimer_过期
Definition: An event generated when the KeepaliveTimer expires.
定义：KeepaliveTimer过期时生成的事件。
Status: Mandatory
地位：强制性
Event 12: DelayOpenTimer_Expires
事件12:DelayOpenTimer\u过期
Definition: An event generated when the DelayOpenTimer expires.
定义：DelayOpenTimer过期时生成的事件。
Status: Optional
状态：可选
Optional Attribute Status: If this event occurs, 1) DelayOpen attribute SHOULD be set to TRUE, 2) DelayOpenTime attribute SHOULD be supported, 3) DelayOpenTimer SHOULD be supported.
可选属性状态：如果发生此事件，则1）应将DelayOpen属性设置为TRUE，2）应支持DelayOpenTime属性，3）应支持DelayOpenTimer。
Event 13: IdleHoldTimer_Expires
事件13:IdleHoldTimer\u过期
Definition: An event generated when the IdleHoldTimer expires, indicating that the BGP connection has completed waiting for the back-off period to prevent BGP peer oscillation.
定义：IdleHoldTimer过期时生成的事件，表示BGP连接已完成等待回退时间以防止BGP对等振荡。
The IdleHoldTimer is only used when the persistent peer oscillation damping function is enabled by setting the DampPeerOscillations optional attribute to TRUE.
IdleHoldTimer仅在通过将DampPeerOscillations optional属性设置为TRUE启用持久对等振荡阻尼功能时使用。
Implementations not implementing the persistent peer oscillation damping function may not have the IdleHoldTimer.
未实现持久对等振荡阻尼功能的实现可能没有IdleHoldTimer。
Status: Optional
状态：可选
Optional Attribute Status: If this event occurs: 1) DampPeerOscillations attribute SHOULD be set to TRUE. 2) IdleHoldTimer SHOULD have just expired.
可选属性状态：如果发生此事件：1）DampPeerOscillations属性应设置为TRUE。2） IdleHoldTimer应该刚刚过期。
Event 14: TcpConnection_Valid
事件14:TcpConnection_有效
Definition: Event indicating the local system reception of a TCP connection request with a valid source IP address, TCP port, destination IP address, and TCP Port. The definition of invalid source and invalid destination IP address is determined by the implementation.
定义：表示本地系统接收到具有有效源IP地址、TCP端口、目标IP地址和TCP端口的TCP连接请求的事件。无效源和无效目标IP地址的定义由实现确定。
BGP's destination port SHOULD be port 179, as defined by IANA.
BGP的目标端口应为IANA定义的端口179。
TCP connection request is denoted by the local system receiving a TCP SYN.
TCP连接请求由接收TCP SYN的本地系统表示。
Status: Optional
状态：可选
Optional Attribute Status: 1) The TrackTcpState attribute SHOULD be set to TRUE if this event occurs.
可选属性状态：1）如果发生此事件，TrackTcpState属性应设置为TRUE。
Event 15: Tcp_CR_Invalid
事件15:Tcp\u CR\u无效
Definition: Event indicating the local system reception of a TCP connection request with either an invalid source address or port number, or an invalid destination address or port number.
定义：表示本地系统接收到TCP连接请求的事件，该请求的源地址或端口号无效，或目标地址或端口号无效。
BGP destination port number SHOULD be 179, as defined by IANA.
根据IANA的定义，BGP目标端口号应为179。
A TCP connection request occurs when the local system receives a TCP SYN.
当本地系统接收到TCP SYN时，会发生TCP连接请求。
Status: Optional
状态：可选
Optional Attribute Status: 1) The TrackTcpState attribute should be set to TRUE if this event occurs.
可选属性状态：1）如果发生此事件，TrackTcpState属性应设置为TRUE。
Event 16: Tcp_CR_Acked
事件16：Tcp\u确认
Definition: Event indicating the local system's request to establish a TCP connection to the remote peer.
定义：指示本地系统请求建立到远程对等机的TCP连接的事件。
The local system's TCP connection sent a TCP SYN, received a TCP SYN/ACK message, and sent a TCP ACK.
本地系统的TCP连接发送TCP SYN，接收TCP SYN/ACK消息，并发送TCP ACK。
Status: Mandatory
地位：强制性
Event 17: TcpConnectionConfirmed
事件17:TCP连接已确认
Definition: Event indicating that the local system has received a confirmation that the TCP connection has been established by the remote site.
定义：表示本地系统已收到远程站点已建立TCP连接的确认的事件。
The remote peer's TCP engine sent a TCP SYN. The local peer's TCP engine sent a SYN, ACK message and now has received a final ACK.
远程对等方的TCP引擎发送了一个TCP SYN。本地对等方的TCP引擎发送了一条SYN、ACK消息，现在已收到最终ACK。
Status: Mandatory
地位：强制性
Event 18: TcpConnectionFails
事件18:TcpConnectionFails
Definition: Event indicating that the local system has received a TCP connection failure notice.
定义：表示本地系统已收到TCP连接失败通知的事件。
The remote BGP peer's TCP machine could have sent a FIN. The local peer would respond with a FIN-ACK. Another possibility is that the local peer indicated a timeout in the TCP connection and downed the connection.
远程BGP对等方的TCP计算机可能已发送FIN。本地对等方将使用FIN-ACK进行响应。另一种可能是本地对等方指示TCP连接超时并关闭连接。
Status: Mandatory
地位：强制性
Event 19: BGPOpen
事件19:BGPOpen
Definition: An event is generated when a valid OPEN message has been received.
定义：收到有效的打开消息时生成事件。
Status: Mandatory
地位：强制性
Optional Attribute Status: 1) The DelayOpen optional attribute SHOULD be set to FALSE. 2) The DelayOpenTimer SHOULD not be running.
可选属性状态：1）DelayOpen可选属性应设置为FALSE。2） DelayOpenTimer不应运行。
Event 20: BGPOpen with DelayOpenTimer running
事件20:DelayOpenTimer运行的BGPOpen
Definition: An event is generated when a valid OPEN message has been received for a peer that has a successfully established transport connection and is currently delaying the sending of a BGP open message.
定义：当为已成功建立传输连接且当前正在延迟发送BGP OPEN消息的对等方接收到有效的OPEN消息时，将生成一个事件。
Status: Optional
状态：可选
Optional Attribute Status: 1) The DelayOpen attribute SHOULD be set to TRUE. 2) The DelayOpenTimer SHOULD be running.
可选属性状态：1）DelayOpen属性应设置为TRUE。2） DelayOpenTimer应该正在运行。
Event 21: BGPHeaderErr
事件21:bgpheaderrer
Definition: An event is generated when a received BGP message header is not valid.
定义：收到的BGP消息头无效时生成事件。
Status: Mandatory
地位：强制性
Event 22: BGPOpenMsgErr
事件22:BGPOpenMsgErr
Definition: An event is generated when an OPEN message has been received with errors.
定义：当收到带有错误的打开消息时，将生成一个事件。
Status: Mandatory
地位：强制性
Event 23: OpenCollisionDump
事件23：OpenCollisionDump
Definition: An event generated administratively when a connection collision has been detected while processing an incoming OPEN message and this
定义：在处理传入的打开消息时检测到连接冲突时，通过管理方式生成的事件
connection has been selected to be disconnected. See Section 6.8 for more information on collision detection.
已选择断开连接。有关碰撞检测的更多信息，请参见第6.8节。
Event 23 is an administrative action generated by implementation logic that determines whether this connection needs to be dropped per the rules in Section 6.8. This event may occur if the FSM is implemented as two linked state machines.
事件23是由实现逻辑生成的管理操作，它确定是否需要根据第6.8节中的规则删除此连接。如果FSM实现为两个链接状态机，则可能发生此事件。
Status: Optional
状态：可选
Optional Attribute Status: If the state machine is to process this event in the Established state, 1) CollisionDetectEstablishedState optional attribute SHOULD be set to TRUE.
可选属性状态：如果状态机要在已建立状态下处理此事件，则1）CollisionDetectionTestAblishedState可选属性应设置为TRUE。
Please note: The OpenCollisionDump event can occur in Idle, Connect, Active, OpenSent, and OpenConfirm without any optional attributes being set.
请注意：OpenCollisionDump事件可以在空闲、连接、活动、OpenSent和OpenConfirm中发生，而无需设置任何可选属性。
Event 24: NotifMsgVerErr
事件24：Notifmsgverer
Definition: An event is generated when a NOTIFICATION message with "version error" is received.
定义：当收到带有“版本错误”的通知消息时，将生成一个事件。
Status: Mandatory
地位：强制性
Event 25: NotifMsg
事件25：NotifMsg
Definition: An event is generated when a NOTIFICATION message is received and the error code is anything but "version error".
定义：当收到通知消息且错误代码不是“版本错误”时，将生成一个事件。
Status: Mandatory
地位：强制性
Event 26: KeepAliveMsg
事件26：KeepAliveMsg
Definition: An event is generated when a KEEPALIVE message is received.
定义：收到KEEPALIVE消息时生成事件。
Status: Mandatory
地位：强制性
Event 27: UpdateMsg
事件27:UpdateMsg
Definition: An event is generated when a valid UPDATE message is received.
定义：收到有效更新消息时生成事件。
Status: Mandatory
地位：强制性
Event 28: UpdateMsgErr
事件28:UpdateMsgErr
Definition: An event is generated when an invalid UPDATE message is received.
定义：收到无效更新消息时生成事件。
Status: Mandatory
地位：强制性
BGP MUST maintain a separate FSM for each configured peer. Each BGP peer paired in a potential connection will attempt to connect to the other, unless configured to remain in the idle state, or configured to remain passive. For the purpose of this discussion, the active or connecting side of the TCP connection (the side of a TCP connection sending the first TCP SYN packet) is called outgoing. The passive or listening side (the sender of the first SYN/ACK) is called an incoming connection. (See Section 8.2.1.1 for information on the terms active and passive used below.)
BGP必须为每个配置的对等机维护一个单独的FSM。在潜在连接中配对的每个BGP对等方将尝试连接到另一个，除非配置为保持空闲状态或配置为保持被动。在本讨论中，TCP连接的活动或连接端（发送第一个TCP SYN数据包的TCP连接端）称为传出。被动或侦听端（第一个SYN/ACK的发送方）称为传入连接。（关于下文使用的术语主动和被动，请参见第8.2.1.1节。）
A BGP implementation MUST connect to and listen on TCP port 179 for incoming connections in addition to trying to connect to peers. For each incoming connection, a state machine MUST be instantiated. There exists a period in which the identity of the peer on the other end of an incoming connection is known, but the BGP identifier is not known. During this time, both an incoming and outgoing connection may exist for the same configured peering. This is referred to as a connection collision (see Section 6.8).
除了尝试连接到对等方之外，BGP实现还必须连接到TCP端口179并在其上侦听传入连接。对于每个传入连接，必须实例化一个状态机。存在一段时间，在此期间，传入连接另一端的对等方的标识已知，但BGP标识符未知。在此期间，同一配置的对等可能存在传入和传出连接。这称为连接冲突（见第6.8节）。
A BGP implementation will have, at most, one FSM for each configured peering, plus one FSM for each incoming TCP connection for which the peer has not yet been identified. Each FSM corresponds to exactly one TCP connection.
BGP实现最多为每个配置的对等点配置一个FSM，为每个尚未识别对等点的传入TCP连接添加一个FSM。每个FSM只对应一个TCP连接。
There may be more than one connection between a pair of peers if the connections are configured to use a different pair of IP addresses. This is referred to as multiple "configured peerings" to the same peer.
如果将连接配置为使用不同的一对IP地址，则一对对等方之间可能存在多个连接。这被称为同一对等方的多个“配置对等”。
The terms active and passive have been in the Internet operator's vocabulary for almost a decade and have proven useful. The words active and passive have slightly different meanings when applied to a TCP connection or a peer. There is only one active side and one passive side to any one TCP connection, per the definition above and the state machine below. When a BGP speaker is configured as active, it may end up on either the active or passive side of the connection that eventually gets established. Once the TCP connection is completed, it doesn't matter which end was active and which was passive. The only difference is in which side of the TCP connection has port number 179.
“主动”和“被动”这两个术语在互联网运营商的词汇表中已经存在了近十年，并被证明是有用的。“主动”和“被动”这两个词在用于TCP连接或对等连接时的含义略有不同。根据上面的定义和下面的状态机，任何一个TCP连接只有一个主动端和一个被动端。当BGP扬声器配置为有源时，它可能会在最终建立的连接的有源或无源侧结束。一旦TCP连接完成，哪一端是主动端，哪一端是被动端就无关紧要了。唯一的区别在于TCP连接的哪一侧具有端口号179。
There is one FSM per BGP connection. When the connection collision occurs prior to determining what peer a connection is associated with, there may be two connections for one peer. After the connection collision is resolved (see Section 6.8), the FSM for the connection that is closed SHOULD be disposed.
每个BGP连接有一个FSM。当连接冲突发生在确定连接与哪个对等方关联之前时，一个对等方可能有两个连接。解决连接冲突后（参见第6.8节），应处理关闭连接的FSM。
Optional Session Attributes specify either attributes that act as flags (TRUE or FALSE) or optional timers. For optional attributes that act as flags, if the optional session attribute can be set to TRUE on the system, the corresponding BGP FSM actions must be supported. For example, if the following options can be set in a BGP implementation: AutoStart and PassiveTcpEstablishment, then Events 3, 4 and 5 must be supported. If an Optional Session attribute cannot be set to TRUE, the events supporting that set of options do not have to be supported.
可选会话属性指定用作标志（TRUE或FALSE）的属性或可选计时器。对于用作标志的可选属性，如果系统上的可选会话属性可以设置为TRUE，则必须支持相应的BGP FSM操作。例如，如果可以在BGP实现中设置以下选项：AutoStart和PassivetCPEstablish，则必须支持事件3、4和5。如果可选会话属性不能设置为TRUE，则不必支持支持该选项集的事件。
Each of the optional timers (DelayOpenTimer and IdleHoldTimer) has a group of attributes that are:
每个可选计时器（DelayOpenTimer和IdleHoldTimer）都有一组属性，这些属性是：
- flag indicating support, - Time set in Timer - Timer.
- 表示支持的标志，-在定时器-定时器中设置的时间。
The two optional timers show this format:
两个可选计时器显示此格式：
DelayOpenTimer: DelayOpen, DelayOpenTime, DelayOpenTimer IdleHoldTimer: DampPeerOscillations, IdleHoldTime, IdleHoldTimer
DelayOpenTimer:DelayOpen，DelayOpenTime，DelayOpenTimer IdleHoldTimer:DampPeerOscillations，IdleHoldTime，IdleHoldTimer
If the flag indicating support for an optional timer (DelayOpen or DampPeerOscillations) cannot be set to TRUE, the timers and events supporting that option do not have to be supported.
如果表示支持可选计时器（DelayOpen或DampPeerOscillations）的标志无法设置为TRUE，则不必支持支持该选项的计时器和事件。
The Event numbers (1-28) utilized in this state machine description aid in specifying the behavior of the BGP state machine. Implementations MAY use these numbers to provide network management information. The exact form of an FSM or the FSM events are specific to each implementation.
此状态机描述中使用的事件编号（1-28）有助于指定BGP状态机的行为。实现可以使用这些数字来提供网络管理信息。FSM或FSM事件的确切形式特定于每个实现。
At certain points, the BGP FSM specifies that BGP initialization will occur or that BGP resources will be deleted. The initialization of the BGP FSM and the associated resources depend on the policy portion of the BGP implementation. The details of these actions are outside the scope of the FSM document.
在某些情况下，BGP FSM指定将进行BGP初始化或删除BGP资源。BGP FSM和相关资源的初始化取决于BGP实现的策略部分。这些行动的细节不在FSM文件的范围内。
Idle state:
空闲状态：
Initially, the BGP peer FSM is in the Idle state. Hereafter, the BGP peer FSM will be shortened to BGP FSM.
最初，BGP对等FSM处于空闲状态。此后，BGP对等FSM将缩短为BGP FSM。
In this state, BGP FSM refuses all incoming BGP connections for this peer. No resources are allocated to the peer. In response to a ManualStart event (Event 1) or an AutomaticStart event (Event 3), the local system:
在此状态下，BGP FSM拒绝此对等方的所有传入BGP连接。没有资源分配给对等方。为响应手动启动事件（事件1）或自动启动事件（事件3），本地系统：
- initializes all BGP resources for the peer connection,
- 初始化对等连接的所有BGP资源，
- sets ConnectRetryCounter to zero,
- 将ConnectRetryCounter设置为零，
- starts the ConnectRetryTimer with the initial value,
- 使用初始值启动ConnectRetryTimer，
- initiates a TCP connection to the other BGP peer,
- 启动与其他BGP对等方的TCP连接，
- listens for a connection that may be initiated by the remote BGP peer, and
- 侦听远程BGP对等方可能发起的连接，以及
- changes its state to Connect.
- 将其状态更改为“连接”。
The ManualStop event (Event 2) and AutomaticStop (Event 8) event are ignored in the Idle state.
在怠速状态下忽略手动停止事件（事件2）和自动停止（事件8）事件。
In response to a ManualStart_with_PassiveTcpEstablishment event (Event 4) or AutomaticStart_with_PassiveTcpEstablishment event (Event 5), the local system:
为响应手动启动和被动设置事件（事件4）或自动启动和被动设置事件（事件5），本地系统：
- initializes all BGP resources,
- 初始化所有BGP资源，
- sets the ConnectRetryCounter to zero,
- 将ConnectRetryCounter设置为零，
- starts the ConnectRetryTimer with the initial value,
- 使用初始值启动ConnectRetryTimer，
- listens for a connection that may be initiated by the remote peer, and
- 侦听可能由远程对等方启动的连接，以及
- changes its state to Active.
- 将其状态更改为“活动”。
The exact value of the ConnectRetryTimer is a local matter, but it SHOULD be sufficiently large to allow TCP initialization.
ConnectRetryTimer的确切值是本地问题，但它应该足够大，以允许TCP初始化。
If the DampPeerOscillations attribute is set to TRUE, the following three additional events may occur within the Idle state:
如果DampPeerOscillations属性设置为TRUE，则在空闲状态下可能会发生以下三个附加事件：
- AutomaticStart_with_DampPeerOscillations (Event 6),
- 自动启动带阻尼隔离装置（事件6），
- AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment (Event 7),
- 自动启动，带有阻尼隔离和被动设置（事件7），
- IdleHoldTimer_Expires (Event 13).
- IdleHoldTimer_过期（事件13）。
Upon receiving these 3 events, the local system will use these events to prevent peer oscillations. The method of preventing persistent peer oscillation is outside the scope of this document.
收到这3个事件后，本地系统将使用这些事件来防止对等振荡。防止持续对等振荡的方法不在本文档的范围内。
Any other event (Events 9-12, 15-28) received in the Idle state does not cause change in the state of the local system.
在空闲状态下接收的任何其他事件（事件9-12、15-28）不会导致本地系统的状态发生变化。
Connect State:
连接状态：
In this state, BGP FSM is waiting for the TCP connection to be completed.
在此状态下，BGP FSM正在等待TCP连接完成。
The start events (Events 1, 3-7) are ignored in the Connect state.
在连接状态下忽略启动事件（事件1、3-7）。
In response to a ManualStop event (Event 2), the local system:
为响应手动停止事件（事件2），本地系统：
- drops the TCP connection,
- 断开TCP连接，
- releases all BGP resources,
- 释放所有BGP资源，
- sets ConnectRetryCounter to zero,
- 将ConnectRetryCounter设置为零，
- stops the ConnectRetryTimer and sets ConnectRetryTimer to zero, and
- 停止ConnectRetryTimer并将ConnectRetryTimer设置为零，然后
- changes its state to Idle.
- 将其状态更改为空闲。
In response to the ConnectRetryTimer_Expires event (Event 9), the local system:
响应ConnectRetryTimer_Expires事件（事件9），本地系统：
- drops the TCP connection,
- 断开TCP连接，
- restarts the ConnectRetryTimer,
- 重新启动ConnectRetryTimer，
- stops the DelayOpenTimer and resets the timer to zero,
- 停止DelayOpenTimer并将计时器重置为零，
- initiates a TCP connection to the other BGP peer,
- 启动与其他BGP对等方的TCP连接，
- continues to listen for a connection that may be initiated by the remote BGP peer, and
- 继续侦听远程BGP对等方可能发起的连接，以及
- stays in the Connect state.
- 保持连接状态。
If the DelayOpenTimer_Expires event (Event 12) occurs in the Connect state, the local system:
如果在连接状态下发生DelayOpenTimer_Expires事件（事件12），则本地系统：
- sends an OPEN message to its peer,
- 向其对等方发送打开的消息，
- sets the HoldTimer to a large value, and
- 将HoldTimer设置为较大的值，然后
- changes its state to OpenSent.
- 将其状态更改为OpenSent。
If the BGP FSM receives a TcpConnection_Valid event (Event 14), the TCP connection is processed, and the connection remains in the Connect state.
如果BGP FSM接收到TcpConnection_有效事件（事件14），则TCP连接将被处理，并且连接将保持在连接状态。
If the BGP FSM receives a Tcp_CR_Invalid event (Event 15), the local system rejects the TCP connection, and the connection remains in the Connect state.
如果BGP FSM接收到Tcp_CR_无效事件（事件15），本地系统将拒绝Tcp连接，并且该连接将保持连接状态。
If the TCP connection succeeds (Event 16 or Event 17), the local system checks the DelayOpen attribute prior to processing. If the DelayOpen attribute is set to TRUE, the local system:
如果TCP连接成功（事件16或事件17），本地系统将在处理之前检查DelayOpen属性。如果DelayOpen属性设置为TRUE，则本地系统：
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer（如果正在运行）并将ConnectRetryTimer设置为零，
- sets the DelayOpenTimer to the initial value, and
- 将DelayOpenTimer设置为初始值，然后
- stays in the Connect state.
- 保持连接状态。
If the DelayOpen attribute is set to FALSE, the local system:
如果DelayOpen属性设置为FALSE，则本地系统：
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer（如果正在运行）并将ConnectRetryTimer设置为零，
- completes BGP initialization
- 完成BGP初始化
- sends an OPEN message to its peer,
- 向其对等方发送打开的消息，
- sets the HoldTimer to a large value, and
- 将HoldTimer设置为较大的值，然后
- changes its state to OpenSent.
- 将其状态更改为OpenSent。
A HoldTimer value of 4 minutes is suggested.
建议将HoldTimer值设置为4分钟。
If the TCP connection fails (Event 18), the local system checks the DelayOpenTimer. If the DelayOpenTimer is running, the local system:
如果TCP连接失败（事件18），本地系统将检查DelayOpenTimer。如果DelayOpenTimer正在运行，则本地系统：
- restarts the ConnectRetryTimer with the initial value,
- 使用初始值重新启动ConnectRetryTimer，
- stops the DelayOpenTimer and resets its value to zero,
- 停止DelayOpenTimer并将其值重置为零，
- continues to listen for a connection that may be initiated by the remote BGP peer, and
- 继续侦听远程BGP对等方可能发起的连接，以及
- changes its state to Active.
- 将其状态更改为“活动”。
If the DelayOpenTimer is not running, the local system:
如果DelayOpenTimer未运行，则本地系统：
- stops the ConnectRetryTimer to zero,
- 将ConnectRetryTimer停止为零，
- drops the TCP connection,
- 断开TCP连接，
- releases all BGP resources, and
- 释放所有BGP资源，以及
- changes its state to Idle.
- 将其状态更改为空闲。
If an OPEN message is received while the DelayOpenTimer is running (Event 20), the local system:
如果在DelayOpenTimer运行时收到打开消息（事件20），则本地系统：
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer（如果正在运行）并将ConnectRetryTimer设置为零，
- completes the BGP initialization,
- 完成BGP初始化，
- stops and clears the DelayOpenTimer (sets the value to zero),
- 停止并清除DelayOpenTimer（将值设置为零），
- sends an OPEN message,
- 发送一条公开消息，
- sends a KEEPALIVE message,
- 发送一条KEEPALIVE消息，
- if the HoldTimer initial value is non-zero,
- 如果HoldTimer初始值为非零，
- starts the KeepaliveTimer with the initial value and
- 使用初始值启动KeepaliveTimer，然后
- resets the HoldTimer to the negotiated value,
- 将HoldTimer重置为协商值，
else, if the HoldTimer initial value is zero,
否则，如果HoldTimer初始值为零，
- resets the KeepaliveTimer and
- 重置KeepaliveTimer和
- resets the HoldTimer value to zero,
- 将HoldTimer值重置为零，
- and changes its state to OpenConfirm.
- 并将其状态更改为OpenConfirm。
If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it will be "external".
如果自治系统字段的值与本地自治系统编号相同，则将连接状态设置为内部连接；否则它将是“外部的”。
If BGP message header checking (Event 21) or OPEN message checking detects an error (Event 22) (see Section 6.2), the local system:
如果BGP消息头检查（事件21）或打开消息检查检测到错误（事件22）（参见第6.2节），本地系统：
- (optionally) If the SendNOTIFICATIONwithoutOPEN attribute is set to TRUE, then the local system first sends a NOTIFICATION message with the appropriate error code, and then
- （可选）如果SendNOTIFICATIONwithoutOPEN属性设置为TRUE，则本地系统首先发送带有相应错误代码的通知消息，然后
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer（如果正在运行）并将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If a NOTIFICATION message is received with a version error (Event 24), the local system checks the DelayOpenTimer. If the DelayOpenTimer is running, the local system:
如果收到带有版本错误的通知消息（事件24），本地系统将检查DelayOpenTimer。如果DelayOpenTimer正在运行，则本地系统：
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer（如果正在运行）并将ConnectRetryTimer设置为零，
- stops and resets the DelayOpenTimer (sets to zero),
- 停止并重置DelayOpenTimer（设置为零），
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection, and
- 断开TCP连接，然后
- changes its state to Idle.
- 将其状态更改为空闲。
If the DelayOpenTimer is not running, the local system:
如果DelayOpenTimer未运行，则本地系统：
- stops the ConnectRetryTimer and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer并将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- performs peer oscillation damping if the DampPeerOscillations attribute is set to True, and
- 如果DampPeerOscillations属性设置为True，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
In response to any other events (Events 8, 10-11, 13, 19, 23, 25-28), the local system:
为响应任何其他事件（事件8、10-11、13、19、23、25-28），本地系统：
- if the ConnectRetryTimer is running, stops and resets the ConnectRetryTimer (sets to zero),
- 如果ConnectRetryTimer正在运行，则停止并重置ConnectRetryTimer（设置为零），
- if the DelayOpenTimer is running, stops and resets the DelayOpenTimer (sets to zero),
- 如果DelayOpenTimer正在运行，则停止并重置DelayOpenTimer（设置为零），
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- performs peer oscillation damping if the DampPeerOscillations attribute is set to True, and
- 如果DampPeerOscillations属性设置为True，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
Active State:
活动状态：
In this state, BGP FSM is trying to acquire a peer by listening for, and accepting, a TCP connection.
在此状态下，BGP FSM试图通过侦听和接受TCP连接来获取对等方。
The start events (Events 1, 3-7) are ignored in the Active state.
启动事件（事件1、3-7）在激活状态下被忽略。
In response to a ManualStop event (Event 2), the local system:
为响应手动停止事件（事件2），本地系统：
- If the DelayOpenTimer is running and the SendNOTIFICATIONwithoutOPEN session attribute is set, the local system sends a NOTIFICATION with a Cease,
- 如果DelayOpenTimer正在运行，并且设置了SendNOTIFICATIONwithoutOPEN会话属性，则本地系统将发送一个带有停止的通知，
- releases all BGP resources including stopping the DelayOpenTimer
- 释放所有BGP资源，包括停止DelayOpenTimer
- drops the TCP connection,
- 断开TCP连接，
- sets ConnectRetryCounter to zero,
- 将ConnectRetryCounter设置为零，
- stops the ConnectRetryTimer and sets the ConnectRetryTimer to zero, and
- 停止ConnectRetryTimer并将ConnectRetryTimer设置为零，然后
- changes its state to Idle.
- 将其状态更改为空闲。
In response to a ConnectRetryTimer_Expires event (Event 9), the local system:
响应ConnectRetryTimer_Expires事件（事件9），本地系统：
- restarts the ConnectRetryTimer (with initial value),
- 重新启动ConnectRetryTimer（使用初始值），
- initiates a TCP connection to the other BGP peer,
- 启动与其他BGP对等方的TCP连接，
- continues to listen for a TCP connection that may be initiated by a remote BGP peer, and
- 继续侦听可能由远程BGP对等方启动的TCP连接，以及
- changes its state to Connect.
- 将其状态更改为“连接”。
If the local system receives a DelayOpenTimer_Expires event (Event 12), the local system:
如果本地系统接收到DelayOpenTimer_Expires事件（事件12），则本地系统：
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- stops and clears the DelayOpenTimer (set to zero),
- 停止并清除DelayOpenTimer（设置为零），
- completes the BGP initialization,
- 完成BGP初始化，
- sends the OPEN message to its remote peer,
- 将打开的消息发送到其远程对等方，
- sets its hold timer to a large value, and
- 将其保持计时器设置为大值，然后
- changes its state to OpenSent.
- 将其状态更改为OpenSent。
A HoldTimer value of 4 minutes is also suggested for this state transition.
对于此状态转换，建议使用4分钟的HoldTimer值。
If the local system receives a TcpConnection_Valid event (Event 14), the local system processes the TCP connection flags and stays in the Active state.
如果本地系统接收到TcpConnection_有效事件（事件14），本地系统将处理TCP连接标志并保持活动状态。
If the local system receives a Tcp_CR_Invalid event (Event 15), the local system rejects the TCP connection and stays in the Active State.
如果本地系统接收到Tcp_CR_无效事件（事件15），本地系统将拒绝Tcp连接并保持活动状态。
In response to the success of a TCP connection (Event 16 or Event 17), the local system checks the DelayOpen optional attribute prior to processing.
为了响应TCP连接成功（事件16或事件17），本地系统在处理之前检查DelayOpen可选属性。
If the DelayOpen attribute is set to TRUE, the local system:
如果DelayOpen属性设置为TRUE，则本地系统：
- stops the ConnectRetryTimer and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer并将ConnectRetryTimer设置为零，
- sets the DelayOpenTimer to the initial value (DelayOpenTime), and
- 将DelayOpenTimer设置为初始值（DelayOpenTime），然后
- stays in the Active state.
- 保持活动状态。
If the DelayOpen attribute is set to FALSE, the local system:
如果DelayOpen属性设置为FALSE，则本地系统：
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- completes the BGP initialization,
- 完成BGP初始化，
- sends the OPEN message to its peer,
- 将打开的消息发送给其对等方，
- sets its HoldTimer to a large value, and
- 将其HoldTimer设置为较大的值，然后
- changes its state to OpenSent.
- 将其状态更改为OpenSent。
A HoldTimer value of 4 minutes is suggested as a "large value" for the HoldTimer.
建议将4分钟的HoldTimer值作为HoldTimer的“大值”。
If the local system receives a TcpConnectionFails event (Event 18), the local system:
如果本地系统接收到TcpConnectionFails事件（事件18），则本地系统：
- restarts the ConnectRetryTimer (with the initial value),
- 重新启动ConnectRetryTimer（使用初始值），
- stops and clears the DelayOpenTimer (sets the value to zero),
- 停止并清除DelayOpenTimer（将值设置为零），
- releases all BGP resource,
- 释放所有BGP资源，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- optionally performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- 如果DampPeerOscillations属性设置为TRUE，则可以选择执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If an OPEN message is received and the DelayOpenTimer is running (Event 20), the local system:
如果收到打开消息且DelayOpenTimer正在运行（事件20），则本地系统：
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer（如果正在运行）并将ConnectRetryTimer设置为零，
- stops and clears the DelayOpenTimer (sets to zero),
- 停止并清除DelayOpenTimer（设置为零），
- completes the BGP initialization,
- 完成BGP初始化，
- sends an OPEN message,
- 发送一条公开消息，
- sends a KEEPALIVE message,
- 发送一条KEEPALIVE消息，
- if the HoldTimer value is non-zero,
- 如果HoldTimer值为非零，
- starts the KeepaliveTimer to initial value,
- 将KeepaliveTimer启动为初始值，
- resets the HoldTimer to the negotiated value,
- 将HoldTimer重置为协商值，
else if the HoldTimer is zero
否则，如果保持计时器为零
- resets the KeepaliveTimer (set to zero),
- 重置KeepaliveTimer（设置为零），
- resets the HoldTimer to zero, and
- 将HoldTimer重置为零，然后
- changes its state to OpenConfirm.
- 将其状态更改为OpenConfirm。
If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it will be external.
如果自治系统字段的值与本地自治系统编号相同，则将连接状态设置为内部连接；否则它将是外部的。
If BGP message header checking (Event 21) or OPEN message checking detects an error (Event 22) (see Section 6.2), the local system:
如果BGP消息头检查（事件21）或打开消息检查检测到错误（事件22）（参见第6.2节），本地系统：
- (optionally) sends a NOTIFICATION message with the appropriate error code if the SendNOTIFICATIONwithoutOPEN attribute is set to TRUE,
- （可选）如果SendNOTIFICATIONwithoutOPEN属性设置为TRUE，则发送带有相应错误代码的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If a NOTIFICATION message is received with a version error (Event 24), the local system checks the DelayOpenTimer. If the DelayOpenTimer is running, the local system:
如果收到带有版本错误的通知消息（事件24），本地系统将检查DelayOpenTimer。如果DelayOpenTimer正在运行，则本地系统：
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- 停止ConnectRetryTimer（如果正在运行）并将ConnectRetryTimer设置为零，
- stops and resets the DelayOpenTimer (sets to zero),
- 停止并重置DelayOpenTimer（设置为零），
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection, and
- 断开TCP连接，然后
- changes its state to Idle.
- 将其状态更改为空闲。
If the DelayOpenTimer is not running, the local system:
如果DelayOpenTimer未运行，则本地系统：
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
In response to any other event (Events 8, 10-11, 13, 19, 23, 25-28), the local system:
为响应任何其他事件（事件8、10-11、13、19、23、25-28），本地系统：
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by one,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
OpenSent:
OpenSent：
In this state, BGP FSM waits for an OPEN message from its peer.
在此状态下，BGP FSM等待来自其对等方的打开消息。
The start events (Events 1, 3-7) are ignored in the OpenSent state.
在OpenSent状态下忽略启动事件（事件1、3-7）。
If a ManualStop event (Event 2) is issued in the OpenSent state, the local system:
如果在OpenSent状态下发出手动停止事件（事件2），则本地系统：
- sends the NOTIFICATION with a Cease,
- 发送带有停止的通知，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- sets the ConnectRetryCounter to zero, and
- 将ConnectRetryCounter设置为零，然后
- changes its state to Idle.
- 将其状态更改为空闲。
If an AutomaticStop event (Event 8) is issued in the OpenSent state, the local system:
如果在OpenSent状态下发出AutomaticStop事件（事件8），则本地系统：
- sends the NOTIFICATION with a Cease,
- 发送带有停止的通知，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all the BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If the HoldTimer_Expires (Event 10), the local system:
如果HoldTimer_过期（事件10），本地系统：
- sends a NOTIFICATION message with the error code Hold Timer Expired,
- 发送错误代码Hold Timer已过期的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter,
- 递增ConnectRetryCounter，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If a TcpConnection_Valid (Event 14), Tcp_CR_Acked (Event 16), or a TcpConnectionConfirmed event (Event 17) is received, a second TCP connection may be in progress. This second TCP connection is tracked per Connection Collision processing (Section 6.8) until an OPEN message is received.
如果收到Tcp连接有效（事件14）、Tcp连接确认（事件16）或Tcp连接确认事件（事件17），则第二个Tcp连接可能正在进行。每次连接冲突处理（第6.8节）都会跟踪第二个TCP连接，直到收到打开的消息。
A TCP Connection Request for an Invalid port (Tcp_CR_Invalid (Event 15)) is ignored.
对无效端口的TCP连接请求（TCP_CR_Invalid（事件15））被忽略。
If a TcpConnectionFails event (Event 18) is received, the local system:
如果收到TcpConnectionFails事件（事件18），则本地系统：
- closes the BGP connection,
- 关闭BGP连接，
- restarts the ConnectRetryTimer,
- 重新启动ConnectRetryTimer，
- continues to listen for a connection that may be initiated by the remote BGP peer, and
- 继续侦听远程BGP对等方可能发起的连接，以及
- changes its state to Active.
- 将其状态更改为“活动”。
When an OPEN message is received, all fields are checked for correctness. If there are no errors in the OPEN message (Event 19), the local system:
当收到打开的消息时，将检查所有字段的正确性。如果打开消息（事件19）中没有错误，则本地系统：
- resets the DelayOpenTimer to zero,
- 将DelayOpenTimer重置为零，
- sets the BGP ConnectRetryTimer to zero,
- 将BGP ConnectRetryTimer设置为零，
- sends a KEEPALIVE message, and
- 发送一条KEEPALIVE消息，然后
- sets a KeepaliveTimer (via the text below)
- 设置KeepaliveTimer（通过下面的文本）
- sets the HoldTimer according to the negotiated value (see Section 4.2),
- 根据协商值设置HoldTimer（参见第4.2节），
- changes its state to OpenConfirm.
- 将其状态更改为OpenConfirm。
If the negotiated hold time value is zero, then the HoldTimer and KeepaliveTimer are not started. If the value of the Autonomous System field is the same as the local Autonomous System number, then the connection is an "internal" connection; otherwise, it is an "external" connection. (This will impact UPDATE processing as described below.)
如果协商的保持时间值为零，则不会启动保持计时器和KeepaliveTimer。如果自治系统字段的值与本地自治系统编号相同，则连接为“内部”连接；否则，它是一个“外部”连接。（这将影响如下所述的更新处理。）
If the BGP message header checking (Event 21) or OPEN message checking detects an error (Event 22)(see Section 6.2), the local system:
如果BGP消息头检查（事件21）或打开消息检查检测到错误（事件22）（参见第6.2节），本地系统：
- sends a NOTIFICATION message with the appropriate error code,
- 发送带有相应错误代码的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is TRUE, and
- （可选）如果DampPeerOscillations属性为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
Collision detection mechanisms (Section 6.8) need to be applied when a valid BGP OPEN message is received (Event 19 or Event 20). Please refer to Section 6.8 for the details of the comparison. A
当收到有效的BGP OPEN消息（事件19或事件20）时，需要应用碰撞检测机制（第6.8节）。有关比较的详细信息，请参阅第6.8节。A.
CollisionDetectDump event occurs when the BGP implementation determines, by means outside the scope of this document, that a connection collision has occurred.
当BGP实现通过本文档范围之外的方式确定发生了连接冲突时，将发生CollisionDetectDump事件。
If a connection in the OpenSent state is determined to be the connection that must be closed, an OpenCollisionDump (Event 23) is signaled to the state machine. If such an event is received in the OpenSent state, the local system:
如果确定处于OpenSent状态的连接是必须关闭的连接，则会向状态机发送OpenCollisionDump（事件23）信号。如果在OpenSent状态下收到此类事件，则本地系统：
- sends a NOTIFICATION with a Cease,
- 发送带有停止的通知，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If a NOTIFICATION message is received with a version error (Event 24), the local system:
如果收到带有版本错误的通知消息（事件24），则本地系统：
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection, and
- 断开TCP连接，然后
- changes its state to Idle.
- 将其状态更改为空闲。
In response to any other event (Events 9, 11-13, 20, 25-28), the local system:
为响应任何其他事件（事件9、11-13、20、25-28），本地系统：
- sends the NOTIFICATION with the Error Code Finite State Machine Error,
- 发送错误代码为有限状态机错误的通知，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
OpenConfirm State:
OpenConfirm状态：
In this state, BGP waits for a KEEPALIVE or NOTIFICATION message.
在此状态下，BGP等待KEEPALIVE或通知消息。
Any start event (Events 1, 3-7) is ignored in the OpenConfirm state.
在OpenConfirm状态下忽略任何启动事件（事件1、3-7）。
In response to a ManualStop event (Event 2) initiated by the operator, the local system:
为响应操作员启动的手动停止事件（事件2），本地系统：
- sends the NOTIFICATION message with a Cease,
- 发送带有停止的通知消息，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- sets the ConnectRetryCounter to zero,
- 将ConnectRetryCounter设置为零，
- sets the ConnectRetryTimer to zero, and
- 将ConnectRetryTimer设置为零，然后
- changes its state to Idle.
- 将其状态更改为空闲。
In response to the AutomaticStop event initiated by the system (Event 8), the local system:
为响应系统启动的AutomaticStop事件（事件8），本地系统：
- sends the NOTIFICATION message with a Cease,
- 发送带有停止的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If the HoldTimer_Expires event (Event 10) occurs before a KEEPALIVE message is received, the local system:
如果在收到KEEPALIVE消息之前发生HoldTimer_Expires事件（事件10），则本地系统：
- sends the NOTIFICATION message with the Error Code Hold Timer Expired,
- 发送错误代码保持计时器过期的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If the local system receives a KeepaliveTimer_Expires event (Event 11), the local system:
如果本地系统收到KeepaliveTimer_Expires事件（事件11），则本地系统：
- sends a KEEPALIVE message,
- 发送一条KEEPALIVE消息，
- restarts the KeepaliveTimer, and
- 重新启动KeepaliveTimer，然后
- remains in the OpenConfirmed state.
- 仍处于打开确认状态。
In the event of a TcpConnection_Valid event (Event 14), or the success of a TCP connection (Event 16 or Event 17) while in OpenConfirm, the local system needs to track the second connection.
如果在OpenConfirm中发生TcpConnection_有效事件（事件14）或TCP连接成功（事件16或事件17），则本地系统需要跟踪第二个连接。
If a TCP connection is attempted with an invalid port (Event 15), the local system will ignore the second connection attempt.
如果尝试使用无效端口进行TCP连接（事件15），本地系统将忽略第二次连接尝试。
If the local system receives a TcpConnectionFails event (Event 18) from the underlying TCP or a NOTIFICATION message (Event 25), the local system:
如果本地系统从底层TCP接收到TcpConnectionFails事件（事件18）或通知消息（事件25），则本地系统：
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If the local system receives a NOTIFICATION message with a version error (NotifMsgVerErr (Event 24)), the local system:
如果本地系统收到带有版本错误的通知消息（NotIFMSGVERRR（事件24）），则本地系统：
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection, and
- 断开TCP连接，然后
- changes its state to Idle.
- 将其状态更改为空闲。
If the local system receives a valid OPEN message (BGPOpen (Event 19)), the collision detect function is processed per Section 6.8. If this connection is to be dropped due to connection collision, the local system:
如果本地系统收到有效的打开消息（BGPOpen（事件19）），则按照第6.8节处理碰撞检测功能。如果由于连接冲突要断开此连接，本地系统：
- sends a NOTIFICATION with a Cease,
- 发送带有停止的通知，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection (send TCP FIN),
- 断开TCP连接（发送TCP FIN），
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If an OPEN message is received, all fields are checked for correctness. If the BGP message header checking (BGPHeaderErr (Event 21)) or OPEN message checking detects an error (see Section 6.2) (BGPOpenMsgErr (Event 22)), the local system:
如果收到打开的消息，将检查所有字段的正确性。如果BGP消息头检查（BGPHEADERRER（事件21））或打开消息检查检测到错误（请参阅第6.2节）（BGPOpenMsgErr（事件22）），则本地系统：
- sends a NOTIFICATION message with the appropriate error code,
- 发送带有相应错误代码的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If, during the processing of another OPEN message, the BGP implementation determines, by a means outside the scope of this document, that a connection collision has occurred and this connection is to be closed, the local system will issue an OpenCollisionDump event (Event 23). When the local system receives an OpenCollisionDump event (Event 23), the local system:
如果在处理另一条打开的消息期间，BGP实现通过本文档范围之外的方式确定发生了连接冲突，并且该连接将被关闭，则本地系统将发出OpenCollisionDump事件（事件23）。当本地系统接收到OpenCollisionDump事件（事件23）时，本地系统：
- sends a NOTIFICATION with a Cease,
- 发送带有停止的通知，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources
- 释放所有BGP资源
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If the local system receives a KEEPALIVE message (KeepAliveMsg (Event 26)), the local system:
如果本地系统收到KEEPALIVE消息（KeepAliveMsg（事件26）），则本地系统：
- restarts the HoldTimer and
- 重新启动HoldTimer并
- changes its state to Established.
- 将其状态更改为“已建立”。
In response to any other event (Events 9, 12-13, 20, 27-28), the local system:
为响应任何其他事件（事件9、12-13、20、27-28），本地系统：
- sends a NOTIFICATION with a code of Finite State Machine Error,
- 发送带有有限状态机错误代码的通知，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
Established State:
既定国家：
In the Established state, the BGP FSM can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
在已建立状态下，BGP FSM可以与其对等方交换更新、通知和保留消息。
Any Start event (Events 1, 3-7) is ignored in the Established state.
在已建立状态下，忽略任何启动事件（事件1、3-7）。
In response to a ManualStop event (initiated by an operator) (Event 2), the local system:
为响应手动停止事件（由操作员启动）（事件2），本地系统：
- sends the NOTIFICATION message with a Cease,
- 发送带有停止的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- deletes all routes associated with this connection,
- 删除与此连接关联的所有路由，
- releases BGP resources,
- 释放BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- sets the ConnectRetryCounter to zero, and
- 将ConnectRetryCounter设置为零，然后
- changes its state to Idle.
- 将其状态更改为空闲。
In response to an AutomaticStop event (Event 8), the local system:
为响应AutomaticStop事件（事件8），本地系统：
- sends a NOTIFICATION with a Cease,
- 发送带有停止的通知，
- sets the ConnectRetryTimer to zero
- 将ConnectRetryTimer设置为零
- deletes all routes associated with this connection,
- 删除与此连接关联的所有路由，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
One reason for an AutomaticStop event is: A BGP receives an UPDATE messages with a number of prefixes for a given peer such that the total prefixes received exceeds the maximum number of prefixes configured. The local system automatically disconnects the peer.
AutomaticStop事件的一个原因是：BGP接收到具有给定对等方前缀数量的更新消息，因此接收到的前缀总数超过了配置的最大前缀数量。本地系统会自动断开对等机的连接。
If the HoldTimer_Expires event occurs (Event 10), the local system:
如果发生HoldTimer_Expires事件（事件10），本地系统：
- sends a NOTIFICATION message with the Error Code Hold Timer Expired,
- 发送错误代码Hold Timer已过期的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If the KeepaliveTimer_Expires event occurs (Event 11), the local system:
如果发生KeepaliveTimer_Expires事件（事件11），则本地系统：
- sends a KEEPALIVE message, and
- 发送一条KEEPALIVE消息，然后
- restarts its KeepaliveTimer, unless the negotiated HoldTime value is zero.
- 重新启动其KeepaliveTimer，除非协商的HoldTime值为零。
Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepaliveTimer, unless the negotiated HoldTime value is zero.
每次本地系统发送KEEPALIVE或UPDATE消息时，它都会重新启动其KeepaliveTimer，除非协商的HoldTime值为零。
A TcpConnection_Valid (Event 14), received for a valid port, will cause the second connection to be tracked.
为有效端口接收的TcpConnection_Valid（事件14）将导致跟踪第二个连接。
An invalid TCP connection (Tcp_CR_Invalid event (Event 15)) will be ignored.
无效的TCP连接（TCP\u CR\u无效事件（事件15））将被忽略。
In response to an indication that the TCP connection is successfully established (Event 16 or Event 17), the second connection SHALL be tracked until it sends an OPEN message.
为了响应TCP连接成功建立的指示（事件16或事件17），应跟踪第二个连接，直到其发送打开消息。
If a valid OPEN message (BGPOpen (Event 19)) is received, and if the CollisionDetectEstablishedState optional attribute is TRUE, the OPEN message will be checked to see if it collides (Section 6.8) with any other connection. If the BGP implementation determines that this connection needs to be terminated, it will process an OpenCollisionDump event (Event 23). If this connection needs to be terminated, the local system:
如果收到有效的打开消息（BGPOpen（事件19）），并且如果CollisionDetectedTestAblishedState可选属性为TRUE，则将检查打开的消息是否与任何其他连接发生冲突（第6.8节）。如果BGP实现确定需要终止此连接，它将处理OpenCollisionDump事件（事件23）。如果需要终止此连接，本地系统：
- sends a NOTIFICATION with a Cease,
- 发送带有停止的通知，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- deletes all routes associated with this connection,
- 删除与此连接关联的所有路由，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations is set to TRUE, and
- （可选）如果DampPeerOscillations设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
If the local system receives a NOTIFICATION message (Event 24 or Event 25) or a TcpConnectionFails (Event 18) from the underlying TCP, the local system:
如果本地系统从底层TCP接收到通知消息（事件24或事件25）或TcpConnectionFails（事件18），则本地系统：
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- deletes all routes associated with this connection,
- 删除与此连接关联的所有路由，
- releases all the BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- changes its state to Idle.
- 将其状态更改为空闲。
If the local system receives a KEEPALIVE message (Event 26), the local system:
如果本地系统收到KEEPALIVE消息（事件26），则本地系统：
- restarts its HoldTimer, if the negotiated HoldTime value is non-zero, and
- 如果协商的HoldTime值非零，则重新启动其HoldTimer，并且
- remains in the Established state.
- 仍然处于既定状态。
If the local system receives an UPDATE message (Event 27), the local system:
如果本地系统收到更新消息（事件27），则本地系统：
- processes the message,
- 处理消息，
- restarts its HoldTimer, if the negotiated HoldTime value is non-zero, and
- 如果协商的HoldTime值非零，则重新启动其HoldTimer，并且
- remains in the Established state.
- 仍然处于既定状态。
If the local system receives an UPDATE message, and the UPDATE message error handling procedure (see Section 6.3) detects an error (Event 28), the local system:
如果本地系统收到更新消息，且更新消息错误处理程序（见第6.3节）检测到错误（事件28），则本地系统：
- sends a NOTIFICATION message with an Update error,
- 发送带有更新错误的通知消息，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- deletes all routes associated with this connection,
- 删除与此连接关联的所有路由，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
In response to any other event (Events 9, 12-13, 20-22), the local system:
为响应任何其他事件（事件9、12-13、20-22），本地系统：
- sends a NOTIFICATION message with the Error Code Finite State Machine Error,
- 发送错误代码为有限状态机错误的通知消息，
- deletes all routes associated with this connection,
- 删除与此连接关联的所有路由，
- sets the ConnectRetryTimer to zero,
- 将ConnectRetryTimer设置为零，
- releases all BGP resources,
- 释放所有BGP资源，
- drops the TCP connection,
- 断开TCP连接，
- increments the ConnectRetryCounter by 1,
- 将ConnectRetryCounter增加1，
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （可选）如果DampPeerOscillations属性设置为TRUE，则执行对等振荡阻尼，并且
- changes its state to Idle.
- 将其状态更改为空闲。
An UPDATE message may be received only in the Established state. Receiving an UPDATE message in any other state is an error. When an UPDATE message is received, each field is checked for validity, as specified in Section 6.3.
只能在已建立状态下接收更新消息。在任何其他状态下接收更新消息都是错误的。当收到更新消息时，按照第6.3节的规定，检查每个字段的有效性。
If an optional non-transitive attribute is unrecognized, it is quietly ignored. If an optional transitive attribute is unrecognized, the Partial bit (the third high-order bit) in the attribute flags octet is set to 1, and the attribute is retained for propagation to other BGP speakers.
如果无法识别可选的非传递属性，则会悄悄地忽略它。如果无法识别可选的可传递属性，则属性标志八位字节中的部分位（第三个高阶位）将设置为1，并保留该属性以传播到其他BGP扬声器。
If an optional attribute is recognized and has a valid value, then, depending on the type of the optional attribute, it is processed locally, retained, and updated, if necessary, for possible propagation to other BGP speakers.
如果一个可选属性被识别并具有有效值，则根据可选属性的类型，它将在本地进行处理、保留和更新（如有必要），以便可能传播到其他BGP扬声器。
If the UPDATE message contains a non-empty WITHDRAWN ROUTES field, the previously advertised routes, whose destinations (expressed as IP prefixes) are contained in this field, SHALL be removed from the Adj-RIB-In. This BGP speaker SHALL run its Decision Process because the previously advertised route is no longer available for use.
如果更新消息包含非空的撤回路由字段，则先前公布的路由（其目的地（表示为IP前缀）包含在该字段中）应从中的Adj RIB中删除。该BGP演讲者应运行其决策过程，因为先前公布的路线不再可用。
If the UPDATE message contains a feasible route, the Adj-RIB-In will be updated with this route as follows: if the NLRI of the new route is identical to the one the route currently has stored in the Adj-RIB-In, then the new route SHALL replace the older route in the Adj-RIB-In, thus implicitly withdrawing the older route from service. Otherwise, if the Adj-RIB-In has no route with NLRI identical to the new route, the new route SHALL be placed in the Adj-RIB-In.
如果更新消息包含可行的路由，则Adj RIB In将使用该路由更新，如下所示：如果新路由的NLRI与当前存储在Adj RIB In中的路由的NLRI相同，则新路由应替换Adj RIB In中的旧路由，从而隐式地将旧路由从服务中撤回。否则，如果中的调整肋没有NLRI与新路线相同的路线，则应将新路线放置在中的调整肋中。
Once the BGP speaker updates the Adj-RIB-In, the speaker SHALL run its Decision Process.
一旦BGP演讲者更新Adj RIB In，演讲者应运行其决策过程。
The Decision Process selects routes for subsequent advertisement by applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-RIBs-In. The output of the Decision Process is the set of routes that will be advertised to peers; the selected routes will be stored in the local speaker's Adj-RIBs-Out, according to policy.
决策过程通过将本地策略信息库（PIB）中的策略应用于其Adj中存储的路由来选择用于后续广告的路由。决策过程的输出是将通告给对等方的路由集；根据策略，选定的路由将存储在本地说话人的Adj输出中。
The BGP Decision Process described here is conceptual, and does not have to be implemented precisely as described, as long as the implementations support the described functionality and they exhibit the same externally visible behavior.
这里描述的BGP决策过程是概念性的，不必按照所描述的那样精确地实现，只要实现支持所描述的功能，并且它们表现出相同的外部可见行为。
The selection process is formalized by defining a function that takes the attribute of a given route as an argument and returns either (a) a non-negative integer denoting the degree of preference for the route, or (b) a value denoting that this route is ineligible to be installed in Loc-RIB and will be excluded from the next phase of route selection.
选择过程通过定义一个函数形式化，该函数将给定路由的属性作为参数，并返回（a）表示路由偏好程度的非负整数，或（b）一个值，表示该路线不符合安装在Loc RIB中的条件，并将被排除在下一阶段的路线选择之外。
The function that calculates the degree of preference for a given route SHALL NOT use any of the following as its inputs: the existence of other routes, the non-existence of other routes, or the path attributes of other routes. Route selection then consists of the individual application of the degree of preference function to each feasible route, followed by the choice of the one with the highest degree of preference.
计算给定路线偏好度的函数不得使用以下任何一项作为其输入：存在其他路线、不存在其他路线或其他路线的路径属性。然后，路线选择包括对每个可行路线单独应用偏好度函数，然后选择偏好度最高的路线。
The Decision Process operates on routes contained in the Adj-RIBs-In, and is responsible for:
决策过程在中的Adj肋骨中包含的路线上运行，并负责：
- selection of routes to be used locally by the speaker
- 选择演讲者在本地使用的路线
- selection of routes to be advertised to other BGP peers
- 选择要向其他BGP对等方公布的路由
- route aggregation and route information reduction
- 路由聚合与路由信息约简
The Decision Process takes place in three distinct phases, each triggered by a different event:
决策过程分为三个不同的阶段，每个阶段由不同的事件触发：
a) Phase 1 is responsible for calculating the degree of preference for each route received from a peer.
a) 阶段1负责计算从对等方接收到的每个路由的偏好程度。
b) Phase 2 is invoked on completion of phase 1. It is responsible for choosing the best route out of all those available for each distinct destination, and for installing each chosen route into the Loc-RIB.
b) 阶段2在阶段1完成时调用。它负责从每个不同目的地的所有可用路线中选择最佳路线，并将每个选择的路线安装到Loc肋骨中。
c) Phase 3 is invoked after the Loc-RIB has been modified. It is responsible for disseminating routes in the Loc-RIB to each peer, according to the policies contained in the PIB. Route aggregation and information reduction can optionally be performed within this phase.
c) 修改Loc肋骨后，将调用阶段3。它负责根据PIB中包含的政策，向每个对等方传播Loc RIB中的路由。路由聚合和信息缩减可以选择在此阶段中执行。
The Phase 1 decision function is invoked whenever the local BGP speaker receives, from a peer, an UPDATE message that advertises a new route, a replacement route, or withdrawn routes.
当本地BGP演讲者从对等方接收到播发新路由、替换路由或撤回路由的更新消息时，将调用阶段1决策功能。
The Phase 1 decision function is a separate process,f which completes when it has no further work to do.
第1阶段决策函数是一个单独的过程，在没有其他工作要做时完成。
The Phase 1 decision function locks an Adj-RIB-In prior to operating on any route contained within it, and unlocks it after operating on all new or unfeasible routes contained within it.
阶段1决策功能在对包含在其中的任何路线进行操作之前锁定Adj RIB In，并在对包含在其中的所有新路线或不可行路线进行操作之后解锁Adj RIB In。
For each newly received or replacement feasible route, the local BGP speaker determines a degree of preference as follows:
对于每个新接收到的或替换的可行路由，本地BGP扬声器确定如下偏好程度：
If the route is learned from an internal peer, either the value of the LOCAL_PREF attribute is taken as the degree of preference, or the local system computes the degree of preference of the route based on preconfigured policy information. Note that the latter may result in formation of persistent routing loops.
如果路由是从内部对等方学习的，则本地_PREF属性的值将作为首选程度，或者本地系统根据预配置的策略信息计算路由的首选程度。注意，后者可能导致形成持久路由循环。
If the route is learned from an external peer, then the local BGP speaker computes the degree of preference based on preconfigured policy information. If the return value indicates the route is ineligible, the route MAY NOT serve as an input to the next phase of route selection; otherwise, the return value MUST be used as the LOCAL_PREF value in any IBGP readvertisement.
如果路由是从外部对等方学习的，则本地BGP说话者根据预配置的策略信息计算偏好程度。如果返回值表明该路线不合格，则该路线不能作为下一阶段路线选择的输入；否则，返回值必须用作任何IBGP readvertisement中的本地_PREF值。
The exact nature of this policy information, and the computation involved, is a local matter.
这些政策信息的确切性质以及所涉及的计算是一个局部问题。
The Phase 2 decision function is invoked on completion of Phase 1. The Phase 2 function is a separate process, which completes when it has no further work to do. The Phase 2 process considers all routes that are eligible in the Adj-RIBs-In.
第2阶段决策函数在第1阶段完成时调用。第2阶段功能是一个单独的过程，在没有其他工作要做时完成。第2阶段流程考虑了Adj中符合条件的所有路线。
The Phase 2 decision function is blocked from running while the Phase 3 decision function is in process. The Phase 2 function locks all Adj-RIBs-In prior to commencing its function, and unlocks them on completion.
当第3阶段决策功能正在运行时，第2阶段决策功能被阻止运行。第2阶段功能在开始其功能之前锁定所有调整肋，并在完成时解锁。
If the NEXT_HOP attribute of a BGP route depicts an address that is not resolvable, or if it would become unresolvable if the route was installed in the routing table, the BGP route MUST be excluded from the Phase 2 decision function.
如果BGP路由的下一跳属性描述了一个不可解析的地址，或者如果在路由表中安装了该路由，该地址将变得不可解析，则必须将BGP路由从阶段2决策功能中排除。
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. Operations of a BGP speaker that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document.
如果BGP路由的AS_路径属性包含AS循环，则应将BGP路由从阶段2决策函数中排除。AS循环检测是通过扫描完整AS路径（如AS_路径属性中所指定）并检查本地系统的自治系统编号是否未出现在AS路径中来完成的。配置为接受AS路径中具有自身自主系统编号的路由的BGP扬声器的操作不在本文档的范围内。
It is critical that BGP speakers within an AS do not make conflicting decisions regarding route selection that would cause forwarding loops to occur.
AS中的BGP演讲者在路由选择方面不要做出可能导致转发循环发生的冲突决定，这一点至关重要。
For each set of destinations for which a feasible route exists in the Adj-RIBs-In, the local BGP speaker identifies the route that has:
对于Adj肋骨中存在可行路由的每组目的地，本地BGP扬声器识别具有以下特性的路由：
a) the highest degree of preference of any route to the same set of destinations, or
a) 任何路线对同一组目的地的最高偏好程度，或
b) is the only route to that destination, or
b) 是到达该目的地的唯一路线，或
c) is selected as a result of the Phase 2 tie breaking rules specified in Section 9.1.2.2.
c) 根据第9.1.2.2节规定的第2阶段领带断裂规则选择。
The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being held in the Loc-RIB. When the new BGP route is installed in the Routing Table, care must be taken to ensure that existing routes to the same destination that are now considered invalid are removed from the Routing Table. Whether the new BGP route replaces an existing non-BGP route in the Routing Table depends on the policy configured on the BGP speaker.
然后，本地扬声器应将该路线安装在Loc肋骨中，替换目前位于Loc肋骨中的通往同一目的地的任何路线。在路由表中安装新的BGP路由时，必须小心确保从路由表中删除到同一目标的现有路由，这些路由现在被视为无效。新的BGP路由是否替换路由表中现有的非BGP路由取决于BGP扬声器上配置的策略。
The local speaker MUST determine the immediate next-hop address from the NEXT_HOP attribute of the selected route (see Section 5.1.3). If either the immediate next-hop or the IGP cost to the NEXT_HOP (where the NEXT_HOP is resolved through an IGP route) changes, Phase 2 Route Selection MUST be performed again.
本地扬声器必须根据所选路由的下一跳属性确定下一跳地址（见第5.1.3节）。如果立即下一跳或下一跳的IGP成本（下一跳通过IGP路由解决）发生变化，则必须再次执行阶段2路由选择。
Notice that even though BGP routes do not have to be installed in the Routing Table with the immediate next-hop(s), implementations MUST take care that, before any packets are forwarded along a BGP route, its associated NEXT_HOP address is resolved to the immediate (directly connected) next-hop address, and that this address (or multiple addresses) is finally used for actual packet forwarding.
请注意，即使BGP路由不必与立即下一跳一起安装在路由表中，实现也必须注意，在沿着BGP路由转发任何数据包之前，其关联的下一跳地址被解析为立即（直接连接的）下一跳地址，并且该地址（或多个地址）最后用于实际的数据包转发。
Unresolvable routes SHALL be removed from the Loc-RIB and the routing table. However, corresponding unresolvable routes SHOULD be kept in the Adj-RIBs-In (in case they become resolvable).
应从Loc肋骨和路由表中删除无法解决的路由。然而，相应的不可解路径应保留在Adj肋骨中（以防它们变得可解）。
As indicated in Section 9.1.2, BGP speakers SHOULD exclude unresolvable routes from the Phase 2 decision. This ensures that only valid routes are installed in Loc-RIB and the Routing Table.
如第9.1.2节所述，BGP发言人应将无法解决的路线排除在第2阶段决策之外。这确保了Loc RIB和布线表中只安装了有效的布线。
The route resolvability condition is defined as follows:
路由可解析性条件定义如下：
1) A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indirectly) through Rte1. If multiple matching routes are available, only the longest matching route SHOULD be considered.
1) 如果路由表包含至少一个与Rte1的中间网络地址匹配且未通过Rte1递归解析（直接或间接）的可解析路由Rte2，则仅引用中间网络地址的路由Rte1被认为是可解析的。如果有多条匹配路线可用，则只应考虑最长的匹配路线。
2) Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the referenced interface is up and if IP processing is enabled on this interface.
2) 如果引用接口的状态为“启动”，并且在该接口上启用了IP处理，则认为引用接口的路由（带或不带中间地址）是可解析的。
BGP routes do not refer to interfaces, but can be resolved through the routes in the Routing Table that can be of both types (those that specify interfaces or those that do not). IGP routes and routes to directly connected networks are expected to specify the outbound interface. Static routes can specify the outbound interface, the intermediate address, or both.
BGP路由不引用接口，但可以通过路由表中的路由来解析，该路由可以是两种类型（指定接口的路由或不指定接口的路由）。IGP路由和直接连接网络的路由应指定出站接口。静态路由可以指定出站接口和/或中间地址。
Note that a BGP route is considered unresolvable in a situation where the BGP speaker's Routing Table contains no route matching the BGP route's NEXT_HOP. Mutually recursive routes (routes resolving each other or themselves) also fail the resolvability check.
请注意，如果BGP演讲者的路由表不包含与BGP路由的下一跳匹配的路由，则BGP路由被视为不可解。相互递归路由（相互解析或自身解析的路由）也无法通过可解析性检查。
It is also important that implementations do not consider feasible routes that would become unresolvable if they were installed in the Routing Table, even if their NEXT_HOPs are resolvable using the current contents of the Routing Table (an example of such routes
同样重要的是，如果在路由表中安装了可行的路由，即使它们的下一个跳数可用路由表的当前内容来解决（这类路由的例子），也不考虑可行的路由。
would be mutually recursive routes). This check ensures that a BGP speaker does not install routes in the Routing Table that will be removed and not used by the speaker. Therefore, in addition to local Routing Table stability, this check also improves behavior of the protocol in the network.
将是相互递归的路由）。此检查确保BGP扬声器不会在路由表中安装将被删除且扬声器不会使用的路由。因此，除了本地路由表的稳定性外，该检查还改进了协议在网络中的行为。
Whenever a BGP speaker identifies a route that fails the resolvability check because of mutual recursion, an error message SHOULD be logged.
无论何时，只要BGP扬声器识别出一条因相互递归而未通过可解析性检查的路由，都应记录一条错误消息。
In its Adj-RIBs-In, a BGP speaker may have several routes to the same destination that have the same degree of preference. The local speaker can select only one of these routes for inclusion in the associated Loc-RIB. The local speaker considers all routes with the same degrees of preference, both those received from internal peers, and those received from external peers.
在其Adj-RIBs-In中，BGP说话者可能具有多条到具有相同偏好程度的相同目的地的路由。本地扬声器只能选择其中一条路线以包含在相关Loc RIB中。本地说话人考虑具有相同偏好度的所有路由，包括从内部对等方接收的路由和从外部对等方接收的路由。
The following tie-breaking procedure assumes that, for each candidate route, all the BGP speakers within an autonomous system can ascertain the cost of a path (interior distance) to the address depicted by the NEXT_HOP attribute of the route, and follow the same route selection algorithm.
以下解绑过程假设，对于每个候选路由，自治系统内的所有BGP扬声器都可以确定到路由的下一跳属性所描述的地址的路径（内部距离）的成本，并遵循相同的路由选择算法。
The tie-breaking algorithm begins by considering all equally preferable routes to the same destination, and then selects routes to be removed from consideration. The algorithm terminates as soon as only one route remains in consideration. The criteria MUST be applied in the order specified.
平局中断算法首先考虑到到到同一目的地的所有同等优先的路由，然后选择要从考虑中删除的路由。只要只考虑一条路由，算法就会终止。必须按照指定的顺序应用标准。
Several of the criteria are described using pseudo-code. Note that the pseudo-code shown was chosen for clarity, not efficiency. It is not intended to specify any particular implementation. BGP implementations MAY use any algorithm that produces the same results as those described here.
使用伪代码描述了几个标准。请注意，所示伪代码的选择是为了清晰，而不是效率。它不打算指定任何特定的实现。BGP实现可以使用产生与本文所述相同结果的任何算法。
a) Remove from consideration all routes that are not tied for having the smallest number of AS numbers present in their AS_PATH attributes. Note that when counting this number, an AS_SET counts as 1, no matter how many ASes are in the set.
a) 从考虑中删除所有未因AS_路径属性中存在最少AS编号而绑定的路由。请注意，当计算此数字时，无论集合中有多少ASE，AS_集合都将计为1。
b) Remove from consideration all routes that are not tied for having the lowest Origin number in their Origin attribute.
b) 从考虑中删除所有未因其“起点”属性中的起点编号最低而绑定的路线。
c) Remove from consideration routes with less-preferred MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable between routes learned from the same neighboring AS (the neighboring AS is determined from the AS_PATH attribute). Routes that do not have the MULTI_EXIT_DISC attribute are considered to have the lowest possible MULTI_EXIT_DISC value.
c) 从考虑中删除具有较少首选多出口光盘属性的路由。MULTI_EXIT_DISC仅在从同一相邻AS（相邻AS由AS_路径属性确定）学习的路由之间具有可比性。不具有MULTI_EXIT_DISC属性的路由被视为具有最低可能的MULTI_EXIT_DISC值。
This is also described in the following procedure:
以下程序中也对其进行了说明：
for m = all routes still under consideration
for n = all routes still under consideration
if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
remove route m from consideration
for m = all routes still under consideration
for n = all routes still under consideration
if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
remove route m from consideration
In the pseudo-code above, MED(n) is a function that returns the value of route n's MULTI_EXIT_DISC attribute. If route n has no MULTI_EXIT_DISC attribute, the function returns the lowest possible MULTI_EXIT_DISC value (i.e., 0).
在上面的伪代码中，MED（n）是一个函数，返回路由n的MULTI_EXIT_DISC属性的值。如果路由n没有MULTI_EXIT_DISC属性，则函数返回最低可能的MULTI_EXIT_DISC值（即0）。
Similarly, neighborAS(n) is a function that returns the neighbor AS from which the route was received. If the route is learned via IBGP, and the other IBGP speaker didn't originate the route, it is the neighbor AS from which the other IBGP speaker learned the route. If the route is learned via IBGP, and the other IBGP speaker either (a) originated the route, or (b) created the route by aggregation and the AS_PATH attribute of the aggregate route is either empty or begins with an AS_SET, it is the local AS.
类似地，neighborAS（n）是一个函数，它返回从中接收路由的邻居。如果该路由是通过IBGP学习的，而另一个IBGP说话者没有发起该路由，那么它就是另一个IBGP说话者学习该路由的邻居AS。如果路由是通过IBGP学习的，而另一个IBGP说话者（a）发起路由，或（b）通过聚合创建路由，并且聚合路由的AS_PATH属性为空或以AS_集开始，则它是本地AS。
If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the received EBGP MULTI_EXIT_DISC attribute MAY still be performed. If an implementation chooses to remove MULTI_EXIT_DISC, then the optional comparison on MULTI_EXIT_DISC, if performed, MUST be performed only among EBGP-learned routes. The best EBGP-learned route may then be compared with IBGP-learned routes after the removal of the MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a subset of EBGP-learned routes, and the selected "best" EBGP-learned route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC must be used in the comparison with IBGP-learned routes. For IBGP-learned routes, the MULTI_EXIT_DISC MUST be used in route comparisons that reach this step in the Decision Process. Including the MULTI_EXIT_DISC of an EBGP-learned route in the comparison with an IBGP-learned route, then removing the MULTI_EXIT_DISC attribute, and advertising the route has been proven to cause route loops.
如果在将路由重新播发到IBGP之前删除了MULTI_EXIT_DISC属性，则仍然可以执行基于接收到的EBGP MULTI_EXIT_DISC属性的比较。如果某个实现选择移除MULTI_EXIT_DISC，则MULTI_EXIT_DISC上的可选比较（如果执行）必须仅在EBGP学习的路由之间执行。删除MULTI_EXIT_DISC属性后，可将最佳EBGP学习路径与IBGP学习路径进行比较。如果从EBGP学习路径子集中移除多个退出路径，并且所选“最佳”EBGP学习路径不会移除多个退出路径，则必须使用多个退出路径与IBGP学习路径进行比较。对于IBGP学习的路线，在决策过程中达到此步骤的路线比较中必须使用MULTI_EXIT_光盘。在与IBGP学习路由的比较中，包括EBGP学习路由的多个出口盘，然后删除多个出口盘属性，并且已证明该路由的广告会导致路由循环。
d) If at least one of the candidate routes was received via EBGP, remove from consideration all routes that were received via IBGP.
d) 如果至少有一条候选路由通过EBGP接收，则从考虑中删除通过IBGP接收的所有路由。
e) Remove from consideration any routes with less-preferred interior cost. The interior cost of a route is determined by calculating the metric to the NEXT_HOP for the route using the Routing Table. If the NEXT_HOP hop for a route is reachable, but no cost can be determined, then this step should be skipped (equivalently, consider all routes to have equal costs).
e) 不考虑任何首选内部成本较低的路线。路由的内部成本是通过使用路由表计算路由下一跳的度量来确定的。如果路由的NEXTXHOP跳数是可到达的，但不需要确定成本，则应该跳过这一步骤（等价地，考虑所有路由具有相等的成本）。
This is also described in the following procedure.
以下步骤中也将对此进行说明。
for m = all routes still under consideration for n = all routes in still under consideration if (cost(n) is lower than cost(m)) remove m from consideration
对于m=所有仍在考虑中的路线对于n=所有仍在考虑中的路线，如果（成本（n）低于成本（m）），则从考虑中删除m
In the pseudo-code above, cost(n) is a function that returns the cost of the path (interior distance) to the address given in the NEXT_HOP attribute of the route.
在上面的伪代码中，cost（n）是一个函数，它将路径（内部距离）的代价返回到路由的NEXT_HOP属性中给定的地址。
f) Remove from consideration all routes other than the route that was advertised by the BGP speaker with the lowest BGP Identifier value.
f) 从考虑中删除除由具有最低BGP标识符值的BGP扬声器播发的路由之外的所有路由。
g) Prefer the route received from the lowest peer address.
g) 首选从最低对等地址接收的路由。
The Phase 3 decision function is invoked on completion of Phase 2, or when any of the following events occur:
第3阶段决策功能在第2阶段完成时或发生以下任何事件时调用：
a) when routes in the Loc-RIB to local destinations have changed
a) 当Loc RIB中通往本地目的地的路线发生变化时
b) when locally generated routes learned by means outside of BGP have changed
b) 当通过BGP以外的方式学习的本地生成路由发生变化时
c) when a new BGP speaker connection has been established
c) 建立新的BGP扬声器连接时
The Phase 3 function is a separate process that completes when it has no further work to do. The Phase 3 Routing Decision function is blocked from running while the Phase 2 decision function is in process.
第3阶段功能是一个单独的过程，在没有其他工作要做时完成。当第2阶段决策功能正在运行时，第3阶段路由决策功能被阻止运行。
All routes in the Loc-RIB are processed into Adj-RIBs-Out according to configured policy. This policy MAY exclude a route in the Loc-RIB from being installed in a particular Adj-RIB-Out. A route SHALL NOT
Loc RIB中的所有路由根据配置的策略处理为Adj RIB Out。本政策可能会将Loc肋骨中的路线排除在特定Adj肋骨中。路线不得
be installed in the Adj-Rib-Out unless the destination, and NEXT_HOP described by this route, may be forwarded appropriately by the Routing Table. If a route in Loc-RIB is excluded from a particular Adj-RIB-Out, the previously advertised route in that Adj-RIB-Out MUST be withdrawn from service by means of an UPDATE message (see 9.2).
安装在Adj Rib Out中，除非目的地和该路由描述的下一跳可由路由表适当转发。如果Loc RIB中的路线被排除在特定的Adj RIB Out之外，则必须通过更新消息（见9.2）将该Adj RIB Out中先前公布的路线退出服务。
Route aggregation and information reduction techniques (see Section 9.2.2.1) may optionally be applied.
可选择应用路由聚合和信息缩减技术（见第9.2.2.1节）。
Any local policy that results in routes being added to an Adj-RIB-Out without also being added to the local BGP speaker's forwarding table is outside the scope of this document.
任何导致路由添加到Adj RIB Out而未添加到本地BGP演讲者转发表的本地策略均不在本文档范围内。
When the updating of the Adj-RIBs-Out and the Routing Table is complete, the local BGP speaker runs the Update-Send process of 9.2.
当Adj肋骨的更新完成并且路由表完成时，本地BGP扬声器运行9.2的更新发送过程。
A BGP speaker may transmit routes with overlapping Network Layer Reachability Information (NLRI) to another BGP speaker. NLRI overlap occurs when a set of destinations are identified in non-matching multiple routes. Because BGP encodes NLRI using IP prefixes, overlap will always exhibit subset relationships. A route describing a smaller set of destinations (a longer prefix) is said to be more specific than a route describing a larger set of destinations (a shorter prefix); similarly, a route describing a larger set of destinations is said to be less specific than a route describing a smaller set of destinations.
BGP扬声器可以向另一BGP扬声器发送具有重叠网络层可达性信息（NLRI）的路由。当在不匹配的多条路由中标识一组目的地时，NLRI重叠发生。因为BGP使用IP前缀对NLRI进行编码，所以重叠将始终显示子集关系。描述较小目的地集合（较长前缀）的路由被称为比描述较大目的地集合（较短前缀）的路由更具体；类似地，描述一组较大目的地的路由比描述一组较小目的地的路由更不具体。
The precedence relationship effectively decomposes less specific routes into two parts:
优先级关系有效地将不太具体的路由分解为两部分：
- a set of destinations described only by the less specific route, and
- 仅由不太具体的路线描述的一组目的地，以及
- a set of destinations described by the overlap of the less specific and the more specific routes
- 一组目的地，由较不特定的路线和较特定的路线重叠来描述
The set of destinations described by the overlap represents a portion of the less specific route that is feasible, but is not currently in use. If a more specific route is later withdrawn, the set of destinations described by the overlap will still be reachable using the less specific route.
重叠描述的目的地集表示不太具体的路线中可行但当前未使用的一部分。如果以后撤回更具体的路线，则仍可以使用不太具体的路线到达重叠描述的目的地集。
If a BGP speaker receives overlapping routes, the Decision Process MUST consider both routes based on the configured acceptance policy. If both a less and a more specific route are accepted, then the Decision Process MUST install, in Loc-RIB, either both the less and
如果BGP说话人接收到重叠的路由，则决策过程必须基于配置的接受策略来考虑两条路线。如果接受less和更具体的路线，则决策流程必须在Loc RIB中安装less和
the more specific routes or aggregate the two routes and install, in Loc-RIB, the aggregated route, provided that both routes have the same value of the NEXT_HOP attribute.
如果两条路由具有相同的下一跳属性值，则更具体的路由或聚合两条路由并在Loc RIB中安装聚合路由。
If a BGP speaker chooses to aggregate, then it SHOULD either include all ASes used to form the aggregate in an AS_SET, or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now primarily informational. With the elimination of IP routing protocols that do not support classless routing, and the elimination of router and host implementations that do not support classless routing, there is no longer a need to de-aggregate. Routes SHOULD NOT be de-aggregated. In particular, a route that carries the ATOMIC_AGGREGATE attribute MUST NOT be de-aggregated. That is, the NLRI of this route cannot be more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASes listed in the AS_PATH attribute of the route.
如果BGP演讲者选择聚合，那么它应该在AS_集合中包含用于形成聚合的所有ASE，或者向路由添加原子_聚合属性。该属性现在主要是信息性的。随着不支持无类路由的IP路由协议的消除，以及不支持无类路由的路由器和主机实现的消除，不再需要去聚合。不应取消聚合路由。特别是，不能对带有原子聚合属性的路由进行反聚合。也就是说，该路线的NLRI不能更具体。沿着这样的路由进行转发并不保证IP数据包实际上只会遍历路由的AS_PATH属性中列出的ASE。
The Update-Send process is responsible for advertising UPDATE messages to all peers. For example, it distributes the routes chosen by the Decision Process to other BGP speakers, which may be located in either the same autonomous system or a neighboring autonomous system.
更新发送过程负责向所有对等方发布更新消息。例如，它将决策过程选择的路由分配给其他BGP说话者，这些说话者可能位于同一自治系统或相邻的自治系统中。
When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker SHALL NOT re-distribute the routing information contained in that UPDATE message to other internal peers (unless the speaker acts as a BGP Route Reflector [RFC2796]).
当BGP演讲者从内部对等方接收到更新消息时，接收BGP演讲者不得将更新消息中包含的路由信息重新分发给其他内部对等方（除非演讲者充当BGP路由反射器[RFC2796]）。
As part of Phase 3 of the route selection process, the BGP speaker has updated its Adj-RIBs-Out. All newly installed routes and all newly unfeasible routes for which there is no replacement route SHALL be advertised to its peers by means of an UPDATE message.
作为路由选择过程第3阶段的一部分，BGP扬声器已更新其Adj肋骨。所有新安装的路由和所有没有替代路由的新不可行路由应通过更新消息通知其对等方。
A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised.
BGP演讲者不应该从其Adj RIB Out播发给定的可行BGP路由，如果它将生成一条包含与先前播发的相同BGP路由的更新消息。
Any routes in the Loc-RIB marked as unfeasible SHALL be removed. Changes to the reachable destinations within its own autonomous system SHALL also be advertised in an UPDATE message.
应移除Loc肋骨中标记为不可行的任何路线。对其自主系统内可到达目的地的变更也应在更新消息中公布。
If, due to the limits on the maximum size of an UPDATE message (see Section 4), a single route doesn't fit into the message, the BGP speaker MUST not advertise the route to its peers and MAY choose to log an error locally.
如果由于更新消息最大大小的限制（见第4节），单个路由不适合消息，BGP演讲者不得向其对等方公布该路由，并可选择在本地记录错误。
The BGP protocol constrains the amount of routing traffic (that is, UPDATE messages), in order to limit both the link bandwidth needed to advertise UPDATE messages and the processing power needed by the Decision Process to digest the information contained in the UPDATE messages.
BGP协议限制路由通信量（即更新消息），以限制播发更新消息所需的链路带宽和决策过程消化更新消息中包含的信息所需的处理能力。
The parameter MinRouteAdvertisementIntervalTimer determines the minimum amount of time that must elapse between an advertisement and/or withdrawal of routes to a particular destination by a BGP speaker to a peer. This rate limiting procedure applies on a per-destination basis, although the value of MinRouteAdvertisementIntervalTimer is set on a per BGP peer basis.
参数MinRouteAdVertiseMinterValimer确定BGP扬声器向对等方播发和/或撤回到特定目的地的路由之间必须经过的最短时间。此速率限制程序适用于每个目的地，尽管MinRoutedVertisementTinterValimer的值是基于每个BGP对等点设置的。
Two UPDATE messages sent by a BGP speaker to a peer that advertise feasible routes and/or withdrawal of unfeasible routes to some common set of destinations MUST be separated by at least MinRouteAdvertisementIntervalTimer. This can only be achieved by keeping a separate timer for each common set of destinations. This would be unwarranted overhead. Any technique that ensures that the interval between two UPDATE messages sent from a BGP speaker to a peer that advertise feasible routes and/or withdrawal of unfeasible routes to some common set of destinations will be at least MinRouteAdvertisementIntervalTimer, and will also ensure that a constant upper bound on the interval is acceptable.
BGP演讲者向对等方发送的两条更新消息（向某些公共目的地组公布可行路由和/或撤回不可行路由）必须至少由MinRoutedVertisementRetvalimer分隔。这只能通过为每个公共目的地设置单独的计时器来实现。这将是不必要的开销。任何确保从BGP说话者发送到对等方的两条更新消息之间的间隔（播发可行路由和/或撤回不可行路由到某个公共目的地集）至少为MinRoutedVertisementTintervalTimer的技术，还将确保间隔上的恒定上限是可接受的。
Since fast convergence is needed within an autonomous system, either (a) the MinRouteAdvertisementIntervalTimer used for internal peers SHOULD be shorter than the MinRouteAdvertisementIntervalTimer used for external peers, or (b) the procedure describe in this section SHOULD NOT apply to routes sent to internal peers.
由于自治系统内需要快速收敛，因此（a）用于内部对等点的MinRoutedVertisementTintervalTimer应短于用于外部对等点的MinRoutedVertisementTintervalTimer，或者（b）本节中描述的过程不适用于发送给内部对等点的路由。
This procedure does not limit the rate of route selection, but only the rate of route advertisement. If new routes are selected multiple times while awaiting the expiration of MinRouteAdvertisementIntervalTimer, the last route selected SHALL be advertised at the end of MinRouteAdvertisementIntervalTimer.
此过程不限制路线选择的速率，只限制路线广告的速率。如果在等待MinRoutedVertisementTinterValimer到期时多次选择新路线，则最后选择的路线应在MinRoutedVertisementTinterValimer的末尾公布。
The parameter MinASOriginationIntervalTimer determines the minimum amount of time that must elapse between successive advertisements of UPDATE messages that report changes within the advertising BGP speaker's own autonomous systems.
参数MinASOriginationIntervalTimer确定在播发BGP演讲者自己的自治系统内报告更改的更新消息的连续播发之间必须经过的最小时间量。
Having selected the routing information it will advertise, a BGP speaker may avail itself of several methods to organize this information in an efficient manner.
选择了将公布的路由信息后，BGP演讲者可以利用多种方法以有效的方式组织这些信息。
Information reduction may imply a reduction in granularity of policy control - after information is collapsed, the same policies will apply to all destinations and paths in the equivalence class.
信息缩减可能意味着策略控制粒度的缩减——在信息被压缩后，相同的策略将应用于等价类中的所有目的地和路径。
The Decision Process may optionally reduce the amount of information that it will place in the Adj-RIBs-Out by any of the following methods:
决策过程可以通过以下任一方法选择性地减少其将放置在调整肋骨中的信息量：
a) Network Layer Reachability Information (NLRI):
a) 网络层可达性信息（NLRI）：
Destination IP addresses can be represented as IP address prefixes. In cases where there is a correspondence between the address structure and the systems under control of an autonomous system administrator, it will be possible to reduce the size of the NLRI carried in the UPDATE messages.
目标IP地址可以表示为IP地址前缀。在地址结构和自治系统管理员控制的系统之间存在通信的情况下，可以减小更新消息中携带的NLRI的大小。
b) AS_PATHs:
b) 作为路径：
AS path information can be represented as ordered AS_SEQUENCEs or unordered AS_SETs. AS_SETs are used in the route aggregation algorithm described in Section 9.2.2.2. They reduce the size of the AS_PATH information by listing each AS number only once, regardless of how many times it may have appeared in multiple AS_PATHs that were aggregated.
AS路径信息可以表示为有序的_序列或无序的_集合。AS_集合用于第9.2.2.2节所述的路由聚合算法。它们通过只将每个AS_路径信息列出一次来减小AS_路径信息的大小，而不管它在聚合的多个AS_路径中出现了多少次。
An AS_SET implies that the destinations listed in the NLRI can be reached through paths that traverse at least some of the constituent autonomous systems. AS_SETs provide sufficient information to avoid routing information looping; however, their use may prune potentially feasible paths because such paths are no longer listed individually in the form of AS_SEQUENCEs. In practice, this is not likely to be a problem because once an IP packet arrives at the edge of a group of autonomous systems, the BGP speaker is likely to have more detailed path information and can distinguish individual paths from destinations.
AS_集意味着NLRI中列出的目的地可以通过至少穿过一些组成自治系统的路径到达。AS_集合提供足够的信息，以避免路由信息循环；然而，它们的使用可能会删减潜在的可行路径，因为这些路径不再以AS_序列的形式单独列出。在实践中，这不太可能是问题，因为一旦IP分组到达一组自治系统的边缘，BGP说话者可能具有更详细的路径信息，并且可以区分各个路径和目的地。
Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised. Aggregation can occur as part of the Decision Process to reduce the amount of routing information that will be placed in the Adj-RIBs-Out.
聚合是将多个不同路由的特征组合在一起的过程，从而可以发布单个路由。聚合可以作为决策过程的一部分发生，以减少将放置在Adj中的路由信息量。
Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure, separately, to path attributes of the same type and to the Network Layer Reachability Information.
聚合减少了BGP扬声器必须存储和与其他BGP扬声器交换的信息量。通过将以下过程分别应用于相同类型的路径属性和网络层可达性信息，可以聚合路由。
Routes that have different MULTI_EXIT_DISC attributes SHALL NOT be aggregated.
不应聚合具有不同多出口盘属性的路由。
If the aggregated route has an AS_SET as the first element in its AS_PATH attribute, then the router that originates the route SHOULD NOT advertise the MULTI_EXIT_DISC attribute with this route.
如果聚合路由的AS_设置为其AS_路径属性中的第一个元素，则发起路由的路由器不应使用此路由播发MULTI_EXIT_DISC属性。
Path attributes that have different type codes cannot be aggregated together. Path attributes of the same type code may be aggregated, according to the following rules:
具有不同类型代码的路径属性不能聚合在一起。根据以下规则，可以聚合相同类型代码的路径属性：
NEXT_HOP: When aggregating routes that have different NEXT_HOP attributes, the NEXT_HOP attribute of the aggregated route SHALL identify an interface on the BGP speaker that performs the aggregation.
下一跳：聚合具有不同下一跳属性的路由时，聚合路由的下一跳属性应标识BGP扬声器上执行聚合的接口。
ORIGIN attribute: If at least one route among routes that are aggregated has ORIGIN with the value INCOMPLETE, then the aggregated route MUST have the ORIGIN attribute with the value INCOMPLETE. Otherwise, if at least one route among routes that are aggregated has ORIGIN with the value EGP, then the aggregated route MUST have the ORIGIN attribute with the value EGP. In all other cases,, the value of the ORIGIN attribute of the aggregated route is IGP.
来源属性：如果聚合的路由中至少有一个路由的来源值不完整，则聚合的路由必须具有值不完整的来源属性。否则，如果聚合的路由中至少有一条路由的ORIGIN值为EGP，则聚合的路由必须具有ORIGIN属性的值为EGP。在所有其他情况下，聚合路由的ORIGIN属性的值为IGP。
AS_PATH attribute: If routes to be aggregated have identical AS_PATH attributes, then the aggregated route has the same AS_PATH attribute as each individual route.
AS_路径属性：如果要聚合的路由具有相同的AS_路径属性，则聚合的路由与每个单独的路由具有相同的AS_路径属性。
For the purpose of aggregating AS_PATH attributes, we model each AS within the AS_PATH attribute as a tuple <type, value>, where "type" identifies a type of the path segment the AS
为了聚合AS_路径属性，我们将AS_路径属性中的每个AS建模为元组<type，value>，其中“type”将路径段的类型标识为AS
belongs to (e.g., AS_SEQUENCE, AS_SET), and "value" identifies the AS number. If the routes to be aggregated have different AS_PATH attributes, then the aggregated AS_PATH attribute SHALL satisfy all of the following conditions:
属于（例如，AS_序列、AS_集合），并且“值”标识AS编号。如果要聚合的路由具有不同的AS_路径属性，则聚合的AS_路径属性应满足以下所有条件：
- all tuples of type AS_SEQUENCE in the aggregated AS_PATH SHALL appear in all of the AS_PATHs in the initial set of routes to be aggregated.
- 聚合AS_路径中AS_序列类型的所有元组应出现在待聚合路由初始集合中的所有AS_路径中。
- all tuples of type AS_SET in the aggregated AS_PATH SHALL appear in at least one of the AS_PATHs in the initial set (they may appear as either AS_SET or AS_SEQUENCE types).
- 聚合AS_路径中AS_SET类型的所有元组应至少出现在初始集中的一个AS_路径中（它们可以显示为AS_SET或AS_序列类型）。
- for any tuple X of type AS_SEQUENCE in the aggregated AS_PATH, which precedes tuple Y in the aggregated AS_PATH, X precedes Y in each AS_PATH in the initial set, which contains Y, regardless of the type of Y.
- 对于聚合AS_路径中类型为AS_序列的任何元组X（位于聚合AS_路径中元组Y之前），初始集中每个AS_路径中的X都位于Y之前，其中包含Y，而与Y的类型无关。
- No tuple of type AS_SET with the same value SHALL appear more than once in the aggregated AS_PATH.
- 具有相同值的AS_SET类型的元组在聚合AS_路径中不得出现多次。
- Multiple tuples of type AS_SEQUENCE with the same value may appear in the aggregated AS_PATH only when adjacent to another tuple of the same type and value.
- 只有当与相同类型和值的另一个元组相邻时，具有相同值的多个类型为\u序列的元组才可能出现在聚合为\u路径中。
An implementation may choose any algorithm that conforms to these rules. At a minimum, a conformant implementation SHALL be able to perform the following algorithm that meets all of the above conditions:
实现可以选择符合这些规则的任何算法。一致性实现至少应能够执行满足上述所有条件的以下算法：
- determine the longest leading sequence of tuples (as defined above) common to all the AS_PATH attributes of the routes to be aggregated. Make this sequence the leading sequence of the aggregated AS_PATH attribute.
- 确定要聚合的路由的所有as_路径属性共有的元组的最长前导序列（如上定义）。使此序列成为聚合为路径属性的前导序列。
- set the type of the rest of the tuples from the AS_PATH attributes of the routes to be aggregated to AS_SET, and append them to the aggregated AS_PATH attribute.
- 从要聚合到AS_集的路由的AS_路径属性中设置其余元组的类型，并将它们附加到聚合的AS_路径属性中。
- if the aggregated AS_PATH has more than one tuple with the same value (regardless of tuple's type), eliminate all but one such tuple by deleting tuples of the type AS_SET from the aggregated AS_PATH attribute.
- 如果聚合AS_路径有多个具有相同值的元组（无论元组的类型如何），则通过从聚合AS_路径属性中删除AS_集类型的元组来消除除一个元组以外的所有元组。
- for each pair of adjacent tuples in the aggregated AS_PATH, if both tuples have the same type, merge them together, as long as doing so will not cause a segment with a length greater than 255 to be generated.
- 对于聚合为_路径中的每对相邻元组，如果两个元组具有相同的类型，则将它们合并在一起，只要这样做不会导致生成长度大于255的段。
Appendix F, Section F.6 presents another algorithm that satisfies the conditions and allows for more complex policy configurations.
附录F第F.6节介绍了另一种算法，该算法满足条件并允许更复杂的策略配置。
ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has ATOMIC_AGGREGATE path attribute, then the aggregated route SHALL have this attribute as well.
原子聚合：如果至少有一个要聚合的路由具有原子聚合路径属性，则聚合的路由也应具有此属性。
AGGREGATOR: Any AGGREGATOR attributes from the routes to be aggregated MUST NOT be included in the aggregated route. The BGP speaker performing the route aggregation MAY attach a new AGGREGATOR attribute (see Section 5.1.7).
聚合器：要聚合的路由中的任何聚合器属性不得包含在聚合路由中。执行路由聚合的BGP扬声器可附加新的聚合器属性（见第5.1.7节）。
Generally, additional rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions:
通常，用于比较多个备选方案之间路线的附加规则不在本文件范围内。有两个例外：
- If the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route (provided that the speaker is configured to accept such routes). If such a route were ever used, a routing loop could result.
- 如果本地AS出现在正在考虑的新路由的AS路径中，则不能将该新路由视为优于任何其他路由（前提是扬声器配置为接受此类路由）。如果曾经使用过这样的路由，可能会导致路由循环。
- In order to achieve a successful distributed operation, only routes with a likelihood of stability can be chosen. Thus, an AS SHOULD avoid using unstable routes, and it SHOULD NOT make rapid, spontaneous changes to its choice of route. Quantifying the terms "unstable" and "rapid" (from the previous sentence) will require experience, but the principle is clear. Routes that are unstable can be "penalized" (e.g., by using the procedures described in [RFC2439]).
- 为了实现成功的分布式操作，只能选择具有稳定可能性的路由。因此，AS应避免使用不稳定的路由，并且不应对其路由选择进行快速、自发的更改。量化术语“不稳定”和“快速”（来自上一句）需要经验，但原则是明确的。不稳定的路线可能会受到“惩罚”（例如，通过使用[RFC2439]中描述的程序）。
A BGP speaker may originate BGP routes by injecting routing information acquired by some other means (e.g., via an IGP) into BGP. A BGP speaker that originates BGP routes assigns the degree of preference (e.g., according to local configuration) to these routes by passing them through the Decision Process (see Section 9.1). These routes MAY also be distributed to other BGP speakers within the local AS as part of the update process (see Section 9.2). The decision of whether to distribute non-BGP acquired routes within an AS via BGP depends on the environment within the AS (e.g., type of IGP) and SHOULD be controlled via configuration.
BGP扬声器可以通过将通过某些其他手段（例如，经由IGP）获得的路由信息注入BGP来发起BGP路由。发起BGP路由的BGP说话人通过决策过程（参见第9.1节）为这些路由分配偏好度（例如，根据本地配置）。作为更新过程的一部分，这些路由也可以分发给本地的其他BGP扬声器（见第9.2节）。是否通过BGP在AS内分发非BGP获取的路由的决定取决于AS内的环境（例如IGP类型），并应通过配置进行控制。
BGP employs five timers: ConnectRetryTimer (see Section 8), HoldTimer (see Section 4.2), KeepaliveTimer (see Section 8), MinASOriginationIntervalTimer (see Section 9.2.1.2), and MinRouteAdvertisementIntervalTimer (see Section 9.2.1.1).
BGP采用五种定时器：ConnectRetryTimer（见第8节）、HoldTimer（见第4.2节）、KeepaliveTimer（见第8节）、MinASOriginationIntervalTimer（见第9.2.1.2节）和MinRoutedVertisementIntervalTimer（见第9.2.1.1节）。
Two optional timers MAY be supported: DelayOpenTimer, IdleHoldTimer by BGP (see Section 8). Section 8 describes their use. The full operation of these optional timers is outside the scope of this document.
可支持两个可选计时器：延迟开放计时器、BGP的IdleHoldTimer（参见第8节）。第8节介绍了它们的用途。这些可选定时器的完整操作不在本文档的范围内。
ConnectRetryTime is a mandatory FSM attribute that stores the initial value for the ConnectRetryTimer. The suggested default value for the ConnectRetryTime is 120 seconds.
ConnectRetryTime是一个强制的FSM属性，用于存储ConnectRetryTimer的初始值。ConnectRetryTime的建议默认值为120秒。
HoldTime is a mandatory FSM attribute that stores the initial value for the HoldTimer. The suggested default value for the HoldTime is 90 seconds.
HoldTime是一个强制的FSM属性，用于存储HoldTimer的初始值。建议的保持时间默认值为90秒。
During some portions of the state machine (see Section 8), the HoldTimer is set to a large value. The suggested default for this large value is 4 minutes.
在状态机的某些部分期间（参见第8节），HoldTimer被设置为一个大值。此大值的建议默认值为4分钟。
The KeepaliveTime is a mandatory FSM attribute that stores the initial value for the KeepaliveTimer. The suggested default value for the KeepaliveTime is 1/3 of the HoldTime.
KeepaliveTime是一个强制的FSM属性，用于存储KeepaliveTimer的初始值。KeepaliveTime的建议默认值是保持时间的1/3。
The suggested default value for the MinASOriginationIntervalTimer is 15 seconds.
MinASOriginationIntervalTimer的建议默认值为15秒。
The suggested default value for the MinRouteAdvertisementIntervalTimer on EBGP connections is 30 seconds.
EBGP连接上MinRoutedVertisementTinterValimer的建议默认值为30秒。
The suggested default value for the MinRouteAdvertisementIntervalTimer on IBGP connections is 5 seconds.
IBGP连接上MinRoutedVertisementTinterValimer的建议默认值为5秒。
An implementation of BGP MUST allow the HoldTimer to be configurable on a per-peer basis, and MAY allow the other timers to be configurable.
BGP的实现必须允许HoldTimer在每个对等机的基础上进行配置，并且可以允许其他计时器进行配置。
To minimize the likelihood that the distribution of BGP messages by a given BGP speaker will contain peaks, jitter SHOULD be applied to the timers associated with MinASOriginationIntervalTimer, KeepaliveTimer, MinRouteAdvertisementIntervalTimer, and ConnectRetryTimer. A given BGP speaker MAY apply the same jitter to each of these quantities, regardless of the destinations to which the updates are being sent; that is, jitter need not be configured on a per-peer basis.
为了使给定BGP扬声器的BGP消息分布包含峰值的可能性降至最低，应将抖动应用于与MinASOriginationIntervalTimer、KeepaliveTimer、MinRoutedVertisementIntervalTimer和ConnectRetryTimer关联的计时器。给定的BGP扬声器可以对这些数量中的每一个应用相同的抖动，而不管更新被发送到哪个目的地；也就是说，不需要在每个对等基础上配置抖动。
The suggested default amount of jitter SHALL be determined by multiplying the base value of the appropriate timer by a random factor, which is uniformly distributed in the range from 0.75 to 1.0. A new random value SHOULD be picked each time the timer is set. The range of the jitter's random value MAY be configurable.
建议的默认抖动量应通过将适当定时器的基准值乘以随机因子来确定，该随机因子均匀分布在0.75到1.0的范围内。每次设置计时器时，应选择一个新的随机值。抖动随机值的范围可以配置。
There are numerous editorial changes in comparison to [RFC1771] (too many to list here).
与[RFC1771]相比，有许多编辑上的变化（此处列出的太多）。
The following list the technical changes:
以下列出了技术更改：
Changes to reflect the usage of features such as TCP MD5 [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations [RFC3065], and BGP Route Refresh [RFC2918].
更改以反映TCP MD5[RFC2385]、BGP路由反射器[RFC2796]、BGP联盟[RFC3065]和BGP路由刷新[RFC2918]等功能的使用情况。
Clarification of the use of the BGP Identifier in the AGGREGATOR attribute.
澄清聚合器属性中BGP标识符的使用。
Procedures for imposing an upper bound on the number of prefixes that a BGP speaker would accept from a peer.
对BGP说话者从对等方接受的前缀数量施加上限的过程。
The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering.
BGP扬声器在AS_路径属性中包含其自身AS的多个实例的能力，用于AS间通信工程。
Clarification of the various types of NEXT_HOPs.
澄清各种类型的下一个啤酒花。
Clarification of the use of the ATOMIC_AGGREGATE attribute.
澄清原子聚合属性的使用。
The relationship between the immediate next hop, and the next hop as specified in the NEXT_HOP path attribute.
立即下一跳与下一跳路径属性中指定的下一跳之间的关系。
Clarification of the tie-breaking procedures.
澄清解绑程序。
Clarification of the frequency of route advertisements.
澄清路线广告的频率。
Optional Parameter Type 1 (Authentication Information) has been deprecated.
可选参数类型1（身份验证信息）已被弃用。
UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.
已弃用更新消息错误子代码7（作为路由循环）。
OPEN Message Error subcode 5 (Authentication Failure) has been deprecated.
已弃用打开消息错误子代码5（身份验证失败）。
Use of the Marker field for authentication has been deprecated.
已不推荐使用标记字段进行身份验证。
Implementations MUST support TCP MD5 [RFC2385] for authentication.
实现必须支持TCP MD5[RFC2385]进行身份验证。
Clarification of BGP FSM.
BGP FSM的澄清。
All the changes listed in Appendix A, plus the following.
附录A中列出的所有变更，以及以下内容。
BGP-4 is capable of operating in an environment where a set of reachable destinations may be expressed via a single IP prefix. The concept of network classes, or subnetting, is foreign to BGP-4. To accommodate these capabilities, BGP-4 changes the semantics and encoding associated with the AS_PATH attribute. New text has been added to define semantics associated with IP prefixes. These abilities allow BGP-4 to support the proposed supernetting scheme [RFC1518, RFC1519].
BGP-4能够在可通过单个IP前缀表示一组可到达目的地的环境中运行。网络类或子网的概念与BGP-4无关。为了适应这些功能，BGP-4更改了与AS_PATH属性相关联的语义和编码。添加了新文本以定义与IP前缀关联的语义。这些能力使BGP-4能够支持拟议的超级网络计划[RFC1518，RFC1519]。
To simplify configuration, this version introduces a new attribute, LOCAL_PREF, that facilitates route selection procedures.
为了简化配置，此版本引入了一个新属性LOCAL_PREF，以简化路由选择过程。
The INTER_AS_METRIC attribute has been renamed MULTI_EXIT_DISC.
INTER_AS_METRIC属性已重命名为MULTI_EXIT_DISC。
A new attribute, ATOMIC_AGGREGATE, has been introduced to insure that certain aggregates are not de-aggregated. Another new attribute, AGGREGATOR, can be added to aggregate routes to advertise which AS and which BGP speaker within that AS caused the aggregation.
引入了一个新属性，即原子聚合，以确保某些聚合不会被反聚合。另一个新属性AGGREGATOR可以添加到聚合路由中，以公布哪个AS以及该AS中的哪个BGP说话人导致了聚合。
To ensure that Hold Timers are symmetric, the Hold Timer is now negotiated on a per-connection basis. Hold Timers of zero are now supported.
为了确保保持计时器是对称的，现在在每个连接的基础上协商保持计时器。现在支持零的保持计时器。
All of the changes listed in Appendices A and B, plus the following.
附录A和B中列出的所有变更，以及以下内容。
To detect and recover from BGP connection collision, a new field (BGP Identifier) has been added to the OPEN message. New text (Section 6.8) has been added to specify the procedure for detecting and recovering from collision.
要检测BGP连接冲突并从中恢复，已将新字段（BGP标识符）添加到打开的消息中。增加了新的文本（第6.8节），以规定检测和恢复碰撞的程序。
The new document no longer restricts the router that is passed in the NEXT_HOP path attribute to be part of the same Autonomous System as the BGP Speaker.
新文档不再限制在下一跳路径属性中传递的路由器与BGP扬声器属于同一自治系统。
The new document optimizes and simplifies the exchange of information about previously reachable routes.
新文档优化并简化了有关先前可到达路线的信息交换。
All of the changes listed in Appendices A, B, and C, plus the following.
附录A、B和C中列出的所有变更，以及以下内容。
Minor changes to the [RFC1105] Finite State Machine were necessary to accommodate the TCP user interface provided by BSD version 4.3.
需要对[RFC1105]有限状态机进行细微更改，以适应BSD版本4.3提供的TCP用户界面。
The notion of Up/Down/Horizontal relations presented in RFC 1105 has been removed from the protocol.
RFC 1105中提出的上/下/水平关系的概念已从协议中删除。
The changes in the message format from RFC 1105 are as follows:
来自RFC 1105的消息格式变化如下：
1. The Hold Time field has been removed from the BGP header and added to the OPEN message.
1. 保持时间字段已从BGP标头中删除并添加到打开消息中。
2. The version field has been removed from the BGP header and added to the OPEN message.
2. 版本字段已从BGP标头中删除，并添加到打开的消息中。
3. The Link Type field has been removed from the OPEN message.
3. 链接类型字段已从打开的邮件中删除。
4. The OPEN CONFIRM message has been eliminated and replaced with implicit confirmation, provided by the KEEPALIVE message.
4. 打开的确认消息已被删除，并替换为KEEPALIVE消息提供的隐式确认。
5. The format of the UPDATE message has been changed significantly. New fields were added to the UPDATE message to support multiple path attributes.
5. 更新消息的格式已发生重大更改。向更新消息中添加了新字段以支持多个路径属性。
6. The Marker field has been expanded and its role broadened to support authentication.
6. 标记字段已经扩展，其作用也扩大到支持身份验证。
Note that quite often BGP, as specified in RFC 1105, is referred to as BGP-1; BGP, as specified in [RFC1163], is referred to as BGP-2; BGP, as specified in RFC 1267 is referred to as BGP-3; and BGP, as specified in this document is referred to as BGP-4.
注意，RFC 1105中规定的BGP通常称为BGP-1；[RFC1163]中规定的BGP称为BGP-2；RFC 1267中规定的BGP称为BGP-3；本文件中规定的BGP称为BGP-4。
If a local system TCP user interface supports the TCP PUSH function, then each BGP message SHOULD be transmitted with PUSH flag set. Setting PUSH flag forces BGP messages to be transmitted to the receiver promptly.
如果本地系统TCP用户界面支持TCP推送功能，则每个BGP消息都应使用设置的推送标志进行传输。设置PUSH标志将强制BGP消息立即传输到接收器。
If a local system TCP user interface supports setting the DSCP field [RFC2474] for TCP connections, then the TCP connection used by BGP SHOULD be opened with bits 0-2 of the DSCP field set to 110 (binary).
如果本地系统TCP用户界面支持为TCP连接设置DSCP字段[RFC2474]，则BGP使用的TCP连接应打开，DSCP字段的位0-2应设置为110（二进制）。
An implementation MUST support the TCP MD5 option [RFC2385].
实现必须支持TCP MD5选项[RFC2385]。
This section presents some implementation recommendations.
本节介绍了一些实施建议。
Appendix F.1. Multiple Networks Per Message
附录F.1。每条消息有多个网络
The BGP protocol allows for multiple address prefixes with the same path attributes to be specified in one message. Using this capability is highly recommended. With one address prefix per message there is a substantial increase in overhead in the receiver. Not only does the system overhead increase due to the reception of multiple messages, but the overhead of scanning the routing table for updates to BGP peers and other routing protocols (and sending the associated messages) is incurred multiple times as well.
BGP协议允许在一条消息中指定具有相同路径属性的多个地址前缀。强烈建议使用此功能。如果每条消息有一个地址前缀，则接收器中的开销会大幅增加。由于接收多条消息，不仅系统开销增加，而且扫描路由表以更新BGP对等点和其他路由协议（以及发送相关消息）的开销也会多次发生。
One method of building messages that contain many address prefixes per path attribute set from a routing table that is not organized on a per path attribute set basis is to build many messages as the routing table is scanned. As each address prefix is processed, a message for the associated set of path attributes is allocated, if it does not exist, and the new address prefix is added to it. If such a message exists, the new address prefix is appended to it. If the message lacks the space to hold the new address prefix, it is transmitted, a new message is allocated, and the new address prefix is inserted into the new message. When the entire routing table has been scanned, all allocated messages are sent and their resources are released. Maximum compression is achieved when all destinations covered by the address prefixes share a common set of path attributes, making it possible to send many address prefixes in one 4096-byte message.
从未按每个路径属性集组织的路由表中构建每个路径属性集包含许多地址前缀的消息的一种方法是在扫描路由表时构建许多消息。在处理每个地址前缀时，如果路径属性的关联集不存在，则为其分配一条消息，并向其添加新的地址前缀。如果存在这样的消息，则会将新地址前缀附加到该消息。如果消息缺少容纳新地址前缀的空间，则会传输该消息，分配新消息，并将新地址前缀插入新消息中。扫描完整个路由表后，将发送所有已分配的邮件，并释放其资源。当地址前缀覆盖的所有目的地共享一组公共路径属性时，可以实现最大压缩，从而可以在一条4096字节的消息中发送多个地址前缀。
When peering with a BGP implementation that does not compress multiple address prefixes into one message, it may be necessary to take steps to reduce the overhead from the flood of data received when a peer is acquired or when a significant network topology change occurs. One method of doing this is to limit the rate of updates. This will eliminate the redundant scanning of the routing table to provide flash updates for BGP peers and other routing protocols. A disadvantage of this approach is that it increases the propagation latency of routing information. By choosing a minimum flash update interval that is not much greater than the time it takes to process the multiple messages, this latency should be minimized. A better method would be to read all received messages before sending updates.
当使用不将多个地址前缀压缩到一条消息中的BGP实现进行对等时，可能需要采取措施减少在获取对等方或发生重大网络拓扑变化时接收到的大量数据带来的开销。一种方法是限制更新的速率。这将消除路由表的冗余扫描，为BGP对等点和其他路由协议提供闪存更新。这种方法的缺点是增加了路由信息的传播延迟。通过选择不大于处理多条消息所需时间的最小闪存更新间隔，应将此延迟降至最低。更好的方法是在发送更新之前读取所有收到的消息。
Appendix F.2. Reducing Route Flapping
附录F.2。减少路径扑动
To avoid excessive route flapping, a BGP speaker that needs to withdraw a destination and send an update about a more specific or less specific route should combine them into the same UPDATE message.
为了避免过度的路由抖动，需要撤回目的地并发送关于更具体或不太具体的路由的更新的BGP扬声器应将它们合并到相同的更新消息中。
Appendix F.3. Path Attribute Ordering
附录F.3。路径属性排序
Implementations that combine update messages (as described above in Section 6.1) may prefer to see all path attributes presented in a known order. This permits them to quickly identify sets of attributes from different update messages that are semantically identical. To facilitate this, it is a useful optimization to order the path attributes according to type code. This optimization is entirely optional.
组合更新消息的实现（如上文第6.1节所述）可能更喜欢以已知顺序显示所有路径属性。这使他们能够从语义相同的不同更新消息中快速识别属性集。为了便于实现这一点，根据类型代码对路径属性进行排序是一种有用的优化。这种优化完全是可选的。
Appendix F.4. AS_SET Sorting
附录F.4。AS_集排序
Another useful optimization that can be done to simplify this situation is to sort the AS numbers found in an AS_SET. This optimization is entirely optional.
为了简化这种情况，可以做的另一个有用的优化是对AS_集中的AS数进行排序。这种优化完全是可选的。
Appendix F.5. Control Over Version Negotiation
附录F.5。版本协商控制
Because BGP-4 is capable of carrying aggregated routes that cannot be properly represented in BGP-3, an implementation that supports BGP-4 and another BGP version should provide the capability to only speak BGP-4 on a per-peer basis.
由于BGP-4能够承载无法在BGP-3中正确表示的聚合路由，因此支持BGP-4和另一个BGP版本的实现应提供仅在每个对等基础上讲BGP-4的能力。
Appendix F.6. Complex AS_PATH Aggregation
附录F.6。复杂AS_路径聚合
An implementation that chooses to provide a path aggregation algorithm retaining significant amounts of path information may wish to use the following procedure:
选择提供保留大量路径信息的路径聚合算法的实现可能希望使用以下过程：
For the purpose of aggregating AS_PATH attributes of two routes, we model each AS as a tuple <type, value>, where "type" identifies a type of the path segment the AS belongs to (e.g., AS_SEQUENCE, AS_SET), and "value" is the AS number. Two ASes are said to be the same if their corresponding <type, value> tuples are the same.
为了聚合两个路由的AS_路径属性，我们将每个路由建模为元组<type，value>，其中“type”标识AS所属的路径段的类型（例如AS_序列，AS_集），“value”是AS编号。如果两个ASE对应的<type，value>元组相同，则称它们相同。
The algorithm to aggregate two AS_PATH attributes works as follows:
聚合两个AS_路径属性的算法如下所示：
a) Identify the same ASes (as defined above) within each AS_PATH attribute that are in the same relative order within both AS_PATH attributes. Two ASes, X and Y, are said to be in the same order if either:
a) 在每个as_路径属性中标识相同的ASE（如上定义），它们在两个as_路径属性中的相对顺序相同。两个ASE，X和Y的顺序相同，如果：
- X precedes Y in both AS_PATH attributes, or - Y precedes X in both AS_PATH attributes.
- X在两个AS_路径属性中都位于Y之前，或者-Y在两个AS_路径属性中都位于X之前。
b) The aggregated AS_PATH attribute consists of ASes identified in (a), in exactly the same order as they appear in the AS_PATH attributes to be aggregated. If two consecutive ASes identified in (a) do not immediately follow each other in both of the AS_PATH attributes to be aggregated, then the intervening ASes (ASes that are between the two consecutive ASes that are the same) in both attributes are combined into an AS_SET path segment that consists of the intervening ASes from both AS_PATH attributes. This segment is then placed between the two consecutive ASes identified in (a) of the aggregated attribute. If two consecutive ASes identified in (a) immediately follow each other in one attribute, but do not follow in another, then the intervening ASes of the latter are combined into an AS_SET path segment. This segment is then placed between the two consecutive ASes identified in (a) of the aggregated attribute.
b) 聚合AS_路径属性由（a）中标识的ASE组成，其顺序与它们在要聚合的AS_路径属性中出现的顺序完全相同。如果（a）中标识的两个连续ASE在要聚合的两个AS_路径属性中没有立即相互跟随，则中间ASE（两个连续ASE之间相同的ASE）在中，这两个属性被组合成一个AS_集路径段，该段由两个AS_路径属性的中间ASE组成。然后将该段放置在聚合属性（a）中标识的两个连续ASE之间。如果（a）中标识的两个连续ASE在一个属性中紧跟在一起，但在另一个属性中不紧跟在一起，则后者的中间ASE组合成一个AS_集路径段。然后将该段放置在聚合属性（a）中标识的两个连续ASE之间。
c) For each pair of adjacent tuples in the aggregated AS_PATH, if both tuples have the same type, merge them together if doing so will not cause a segment of a length greater than 255 to be generated.
c) 对于聚合为_路径中的每对相邻元组，如果两个元组具有相同的类型，则将它们合并在一起，如果这样做不会导致生成长度大于255的段。
If, as a result of the above procedure, a given AS number appears more than once within the aggregated AS_PATH attribute, all but the last instance (rightmost occurrence) of that AS number should be removed from the aggregated AS_PATH attribute.
如果作为上述过程的结果，给定的as编号在聚合as_路径属性中出现不止一次，则除了该as编号的最后一个实例（最右边的实例）之外，其他所有实例都应从聚合as_路径属性中删除。
Security Considerations
安全考虑
A BGP implementation MUST support the authentication mechanism specified in RFC 2385 [RFC2385]. The authentication provided by this mechanism could be done on a per-peer basis.
BGP实现必须支持RFC 2385[RFC2385]中指定的身份验证机制。该机制提供的身份验证可以基于每个对等点进行。
BGP makes use of TCP for reliable transport of its traffic between peer routers. To provide connection-oriented integrity and data origin authentication on a point-to-point basis, BGP specifies use of the mechanism defined in RFC 2385. These services are intended to detect and reject active wiretapping attacks against the inter-router TCP connections. Absent the use of mechanisms that effect these security services, attackers can disrupt these TCP connections and/or masquerade as a legitimate peer router. Because the mechanism defined in the RFC does not provide peer-entity authentication, these connections may be subject to some forms of replay attacks that will not be detected at the TCP layer. Such attacks might result in delivery (from TCP) of "broken" or "spoofed" BGP messages.
BGP利用TCP在对等路由器之间可靠传输其流量。为了在点对点的基础上提供面向连接的完整性和数据源身份验证，BGP指定使用RFC 2385中定义的机制。这些服务旨在检测和拒绝针对路由器间TCP连接的主动窃听攻击。如果不使用影响这些安全服务的机制，攻击者可以中断这些TCP连接和/或伪装成合法的对等路由器。由于RFC中定义的机制不提供对等实体身份验证，因此这些连接可能会受到某种形式的重播攻击，而这些攻击在TCP层不会被检测到。此类攻击可能导致（从TCP）传送“中断”或“伪造”的BGP消息。
The mechanism defined in RFC 2385 augments the normal TCP checksum with a 16-byte message authentication code (MAC) that is computed over the same data as the TCP checksum. This MAC is based on a one-way hash function (MD5) and use of a secret key. The key is shared between peer routers and is used to generate MAC values that are not readily computed by an attacker who does not have access to the key. A compliant implementation must support this mechanism, and must allow a network administrator to activate it on a per-peer basis.
RFC 2385中定义的机制使用一个16字节的消息验证码（MAC）来增强正常TCP校验和，该码是在与TCP校验和相同的数据上计算的。此MAC基于单向散列函数（MD5）和使用密钥。该密钥在对等路由器之间共享，用于生成无法访问该密钥的攻击者不容易计算的MAC值。兼容的实现必须支持此机制，并且必须允许网络管理员在每个对等点的基础上激活它。
RFC 2385 does not specify a means of managing (e.g., generating, distributing, and replacing) the keys used to compute the MAC. RFC 3562 [RFC3562] (an informational document) provides some guidance in this area, and provides rationale to support this guidance. It notes that a distinct key should be used for communication with each protected peer. If the same key is used for multiple peers, the offered security services may be degraded, e.g., due to an increased risk of compromise at one router that adversely affects other routers.
RFC 2385没有指定管理（例如，生成、分发和替换）用于计算MAC的密钥的方法。RFC 3562[RFC3562]（一份信息性文件）提供了该领域的一些指导，并提供了支持该指导的基本原理。它指出，应该使用不同的密钥与每个受保护的对等方进行通信。如果同一密钥用于多个对等方，则所提供的安全服务可能会降级，例如，由于一个路由器的泄露风险增加而对其他路由器产生不利影响。
The keys used for MAC computation should be changed periodically, to minimize the impact of a key compromise or successful cryptanalytic attack. RFC 3562 suggests a crypto period (the interval during which a key is employed) of, at most, 90 days. More frequent key changes reduce the likelihood that replay attacks (as described above) will be feasible. However, absent a standard mechanism for effecting such changes in a coordinated fashion between peers, one cannot assume that BGP-4 implementations complying with this RFC will support frequent key changes.
用于MAC计算的密钥应定期更改，以将密钥泄露或成功的密码分析攻击的影响降至最低。RFC 3562建议加密周期（使用密钥的间隔）最多为90天。更频繁的密钥更改会降低重播攻击（如上所述）可行的可能性。然而，由于缺乏一种标准机制来在对等方之间以协调的方式实现此类更改，因此不能假设符合此RFC的BGP-4实现将支持频繁的密钥更改。
Obviously, each should key also be chosen to be difficult for an attacker to guess. The techniques specified in RFC 1750 for random number generation provide a guide for generation of values that could be used as keys. RFC 2385 calls for implementations to support keys "composed of a string of printable ASCII of 80 bytes or less." RFC 3562 suggests keys used in this context be 12 to 24 bytes of random (pseudo-random) bits. This is fairly consistent with suggestions for analogous MAC algorithms, which typically employ keys in the range of 16 to 20 bytes. To provide enough random bits at the low end of this range, RFC 3562 also observes that a typical ACSII text string would have to be close to the upper bound for the key length specified in RFC 2385.
显然，每一个密钥的选择都应该使攻击者难以猜测。RFC 1750中规定的随机数生成技术为生成可用作键的值提供了指南。RFC 2385要求实现支持“由80字节或更少的可打印ASCII字符串组成”的键。RFC 3562建议在此上下文中使用的键为12到24字节的随机（伪随机）位。这与类似MAC算法的建议相当一致，该算法通常使用16到20字节的密钥。为了在该范围的低端提供足够的随机位，RFC 3562还观察到典型的ACSII文本字符串必须接近RFC 2385中指定的密钥长度上限。
BGP vulnerabilities analysis is discussed in [RFC4272].
BGP漏洞分析在[RFC4272]中进行了讨论。
IANA Considerations
IANA考虑
All the BGP messages contain an 8-bit message type, for which IANA has created and is maintaining a registry entitled "BGP Message Types". This document defines the following message types:
所有BGP消息都包含一个8位消息类型，IANA已为其创建并维护一个名为“BGP消息类型”的注册表。本文档定义了以下消息类型：
Name Value Definition
---- ----- ----------
OPEN 1 See Section 4.2
UPDATE 2 See Section 4.3
NOTIFICATION 3 See Section 4.5
KEEPALIVE 4 See Section 4.4
Name Value Definition
---- ----- ----------
OPEN 1 See Section 4.2
UPDATE 2 See Section 4.3
NOTIFICATION 3 See Section 4.5
KEEPALIVE 4 See Section 4.4
Future assignments are to be made using either the Standards Action process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments consist of a name and the value.
未来分配将使用[RFC2434]中定义的标准行动流程或[RFC4020]中定义的早期IANA分配流程进行。赋值由名称和值组成。
The BGP UPDATE messages may carry one or more Path Attributes, where each Attribute contains an 8-bit Attribute Type Code. IANA is already maintaining such a registry, entitled "BGP Path Attributes". This document defines the following Path Attributes Type Codes:
BGP更新消息可能携带一个或多个路径属性，其中每个属性包含一个8位属性类型代码。IANA已经在维护这样一个名为“BGP路径属性”的注册表。本文档定义了以下路径属性类型代码：
Name Value Definition
---- ----- ----------
ORIGIN 1 See Section 5.1.1
AS_PATH 2 See Section 5.1.2
NEXT_HOP 3 See Section 5.1.3
MULTI_EXIT_DISC 4 See Section 5.1.4
LOCAL_PREF 5 See Section 5.1.5
ATOMIC_AGGREGATE 6 See Section 5.1.6
AGGREGATOR 7 See Section 5.1.7
Name Value Definition
---- ----- ----------
ORIGIN 1 See Section 5.1.1
AS_PATH 2 See Section 5.1.2
NEXT_HOP 3 See Section 5.1.3
MULTI_EXIT_DISC 4 See Section 5.1.4
LOCAL_PREF 5 See Section 5.1.5
ATOMIC_AGGREGATE 6 See Section 5.1.6
AGGREGATOR 7 See Section 5.1.7
Future assignments are to be made using either the Standards Action process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments consist of a name and the value.
未来分配将使用[RFC2434]中定义的标准行动流程或[RFC4020]中定义的早期IANA分配流程进行。赋值由名称和值组成。
The BGP NOTIFICATION message carries an 8-bit Error Code, for which IANA has created and is maintaining a registry entitled "BGP Error Codes". This document defines the following Error Codes:
BGP通知消息包含一个8位错误代码，IANA已为其创建并维护一个名为“BGP错误代码”的注册表。本文件定义了以下错误代码：
Name Value Definition
------------ ----- ----------
Message Header Error 1 Section 6.1
OPEN Message Error 2 Section 6.2
UPDATE Message Error 3 Section 6.3
Hold Timer Expired 4 Section 6.5
Finite State Machine Error 5 Section 6.6
Cease 6 Section 6.7
Name Value Definition
------------ ----- ----------
Message Header Error 1 Section 6.1
OPEN Message Error 2 Section 6.2
UPDATE Message Error 3 Section 6.3
Hold Timer Expired 4 Section 6.5
Finite State Machine Error 5 Section 6.6
Cease 6 Section 6.7
Future assignments are to be made using either the Standards Action process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments consist of a name and the value.
未来分配将使用[RFC2434]中定义的标准行动流程或[RFC4020]中定义的早期IANA分配流程进行。赋值由名称和值组成。
The BGP NOTIFICATION message carries an 8-bit Error Subcode, where each Subcode has to be defined within the context of a particular Error Code, and thus has to be unique only within that context.
BGP通知消息携带8位错误子代码，其中每个子代码必须在特定错误代码的上下文中定义，因此必须仅在该上下文中唯一。
IANA has created and is maintaining a set of registries, "Error Subcodes", with a separate registry for each BGP Error Code. Future assignments are to be made using either the Standards Action process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments consist of a name and the value.
IANA已经创建并维护了一组注册表“错误子代码”，每个BGP错误代码都有一个单独的注册表。未来分配将使用[RFC2434]中定义的标准行动流程或[RFC4020]中定义的早期IANA分配流程进行。赋值由名称和值组成。
This document defines the following Message Header Error subcodes:
本文档定义了以下消息头错误子代码：
Name Value Definition
-------------------- ----- ----------
Connection Not Synchronized 1 See Section 6.1
Bad Message Length 2 See Section 6.1
Bad Message Type 3 See Section 6.1
Name Value Definition
-------------------- ----- ----------
Connection Not Synchronized 1 See Section 6.1
Bad Message Length 2 See Section 6.1
Bad Message Type 3 See Section 6.1
This document defines the following OPEN Message Error subcodes:
本文档定义了以下打开消息错误子代码：
Name Value Definition
-------------------- ----- ----------
Unsupported Version Number 1 See Section 6.2
Bad Peer AS 2 See Section 6.2
Bad BGP Identifier 3 See Section 6.2
Unsupported Optional Parameter 4 See Section 6.2
[Deprecated] 5 See Appendix A
Unacceptable Hold Time 6 See Section 6.2
Name Value Definition
-------------------- ----- ----------
Unsupported Version Number 1 See Section 6.2
Bad Peer AS 2 See Section 6.2
Bad BGP Identifier 3 See Section 6.2
Unsupported Optional Parameter 4 See Section 6.2
[Deprecated] 5 See Appendix A
Unacceptable Hold Time 6 See Section 6.2
This document defines the following UPDATE Message Error subcodes:
本文档定义了以下更新消息错误子代码：
Name Value Definition
-------------------- --- ----------
Malformed Attribute List 1 See Section 6.3
Unrecognized Well-known Attribute 2 See Section 6.3
Missing Well-known Attribute 3 See Section 6.3
Attribute Flags Error 4 See Section 6.3
Attribute Length Error 5 See Section 6.3
Invalid ORIGIN Attribute 6 See Section 6.3
[Deprecated] 7 See Appendix A
Invalid NEXT_HOP Attribute 8 See Section 6.3
Optional Attribute Error 9 See Section 6.3
Invalid Network Field 10 See Section 6.3
Malformed AS_PATH 11 See Section 6.3
Name Value Definition
-------------------- --- ----------
Malformed Attribute List 1 See Section 6.3
Unrecognized Well-known Attribute 2 See Section 6.3
Missing Well-known Attribute 3 See Section 6.3
Attribute Flags Error 4 See Section 6.3
Attribute Length Error 5 See Section 6.3
Invalid ORIGIN Attribute 6 See Section 6.3
[Deprecated] 7 See Appendix A
Invalid NEXT_HOP Attribute 8 See Section 6.3
Optional Attribute Error 9 See Section 6.3
Invalid Network Field 10 See Section 6.3
Malformed AS_PATH 11 See Section 6.3
Normative References
规范性引用文件
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
Informative References
资料性引用
[RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC904]Mills，D.，“外部网关协议正式规范”，RFC 904，1984年4月。
[RFC1092] Rekhter, J., "EGP and policy based routing in the new NSFNET backbone", RFC 1092, February 1989.
[RFC1092]Rekhter，J.，“新NSFNET主干网中的EGP和基于策略的路由”，RFC 1092，1989年2月。
[RFC1093] Braun, H., "NSFNET routing architecture", RFC 1093, February 1989.
[RFC1093]布劳恩，H.，“NSFNET路由架构”，RFC1093，1989年2月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105]Lougheed，K.和Y.Rekhter，“边界网关协议（BGP）”，RFC1105，1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163]Lougheed，K.和Y.Rekhter，“边界网关协议（BGP）”，RFC1163，1990年6月。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
[RFC1267]Lougheed，K.和Y.Rekhter，“边境网关协议3（BGP-3）”，RFC 1267，1991年10月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[RFC1772] Rekhter, Y. and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[RFC1772]Rekhter，Y.和P.Gross，“互联网中边界网关协议的应用”，RFC 1772，1995年3月。
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[RFC1518]Rekhter，Y.和T.Li，“使用CIDR的IP地址分配架构”，RFC 1518，1993年9月。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519]Fuller，V.，Li，T.，Yu，J.，和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930]霍金森，J.和T.贝茨，“自主系统（AS）的创建、选择和注册指南”，BCP 6，RFC 1930，1996年3月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997]Chandra，R.，Traina，P.，和T.Li，“BGP社区属性”，RFC 1997，1996年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439]Villamizar，C.，Chandra，R.，和R.Govindan，“BGP路线襟翼阻尼”，RFC 2439，1998年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC2796]Bates，T.，Chandra，R.，和E.Chen，“BGP路线反射-全网格IBGP的替代品”，RFC 2796，2000年4月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858]Bates，T.，Rekhter，Y.，Chandra，R.，和D.Katz，“BGP-4的多协议扩展”，RFC 2858，2000年6月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 3392，2002年11月。
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[RFC2918]Chen，E.“BGP-4的路由刷新能力”，RFC 2918，2000年9月。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[RFC3065]Traina，P.，McPherson，D.，和J.Scudder，“BGP自治系统联合会”，RFC 3065，2001年2月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[IS10747] "Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993.
[IS10747]“信息处理系统-系统间电信和信息交换-支持ISO 8473 PDU转发的中间系统间域间路由信息交换协议”，ISO/IEC IS10747，1993年。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，2006年1月
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4020]Kompella，K.和A.Zinin，“早期IANA标准轨道代码点分配”，BCP 100，RFC 4020，2005年2月。
Editors' Addresses
编辑地址
Yakov Rekhter Juniper Networks
雅科夫-雷克特Juniper网络
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Tony Li
李东尼
EMail: tony.li@tony.li
EMail: tony.li@tony.li
Susan Hares NextHop Technologies, Inc. 825 Victors Way Ann Arbor, MI 48108
Susan Hares NextHop Technologies，Inc.密歇根州安阿伯维克多大道825号，邮编：48108
Phone: (734)222-1610 EMail: skh@nexthop.com
电话：（734）222-1610电子邮件：skh@nexthop.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。