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)
A 边界网关协议 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 系统交换网络可达性信息。这种网络可达性信息包括可达性信息遍历的自治系统（AS）列表信息。这些信息足以为这种可达性构建一个 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
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 系统交换网络可达性信息。这种网络可达性信息包括可达性信息所遍历的自治系统（AS）列表信息。这些信息足以为这种可达性构建一个 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-In Adj-RIBs-In 包含未处理的路由信息，这些信息已由本地 BGP 说话者的对等方公布给本地 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-RIBs-Out 包含通过本地发言人的 UPDATE 消息向特定对等体发布的路由。
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 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 内使用多套度量标准的情况已变得十分普遍。使用 "自治系统"（Autonomous System）一词强调的是，即使使用多个 IGP 和度量标准，一个 AS 的管理在其他 AS 看来也是一个统一的内部路由计划，并对可通过它到达的目的地进行一致的描述。
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 Identifier 一个 4 八位无符号整数，表示 BGP 消息发送者的 BGP Identifier。给定的 BGP 说话者会将其 BGP Identifier 的值设置为分配给该 BGP 说话者的 IP 地址。BGP Identifier 的值在启动时确定，对每个本地接口和 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 地址包含在 UPDATE 报文的网络层可达性信息（NLRI）字段中的一个 IP 地址前缀中的系统。路径是同一 UPDATE 消息的路径属性字段中报告的信息。
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].
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 以及 "OPTIONAL" 应按照RFC 2119 [RFC2119]中的描述进行解释。
This document was originally published as [RFC1267] in October 1991, jointly authored by Kirk Lougheed and Yakov Rekhter.
本文档最初于 1991 年 10 月作为 [RFC1267] 发布，由 Kirk Lougheed 和 Yakov Rekhter 合著。
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）的审查小组。这个团队由 Deborah Estrin、Milo Medin、John Moy、Radia Perlman、Martha Steenstrup、Mike St.
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]，后者是 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.
我们还要感谢 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 和 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.
最后，我们要感谢国际发展研究工作组的所有成员，感谢他们为本文件提出的想法和给予的支持。
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]）和 EGP 在 NSFNET 主干网中的使用（见 [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 系统交换网络可达性信息。这种网络可达性信息包括可达性信息遍历的自治系统（AS）列表信息。这些信息足以构建一个 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 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.
通过 BGP 交换的路由信息只支持基于目的地的转发模式，即路由器只根据数据包 IP 头中的目的地地址转发数据包。这反过来又反映了使用 BGP 可以（和不可以）执行的一系列策略决策。需要注意的是，有些策略是基于目的地的转发模式无法支持的，因此需要使用源路由（又称显式路由）等技术来执行。使用 BGP 也无法执行此类策略。例如，BGP 无法让一个 AS 将流量发送到邻近的 AS，以便转发到该邻近 AS 以外的某个目的地（通过但可到达），而该邻近 AS 的目的是让流量采用与源于该邻近 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 使用多个 IGP，有时在一个 AS 内使用多套度量标准的情况已变得十分普遍。使用 "自治系统"（Autonomous System）一词强调的是，即使使用了多个 IGP 和度量标准，一个 AS 的管理在其他 AS 看来也是一个统一的内部路由计划，并对可通过它到达的目的地进行一致的描述。
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-Ribs-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 内部路由的一致性视图由 AS 内使用的 IGP 提供。本文假定，AS 外部路由的一致视图是通过 AS 内所有 BGP 发言者相互间维护 IBGP 提供的。
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 地址包含在一个 IP 地址前缀中的系统，该 IP 地址前缀包含在 UPDATE 消息的网络层可达性信息 (NLRI) 字段中，而路径则是同一 UPDATE 消息的路径属性字段中报告的信息。
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.
路由是在 UPDATE 消息中在 BGP 发言者之间发布的。通过在 UPDATE 消息的 NLRI 字段中包含多个前缀，可在单个 UPDATE 消息中公布具有相同路径属性的多个路由。
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）中：即 Adj-RIBs-In、Loc-RIB 和 Adj-RIBs-Out，如第 3.2 节所述。
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) 可以在 UPDATE 消息的 WITHDRAWN ROUTES 字段中公布表示以前公布路由的目的地的 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-RIBs-In：Adj-RIBs-In 存储从其他 BGP 发言者收到的入站 UPDATE 消息中获取的路由信息。其内容代表可作为决策过程输入的路由。
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-RIBs-In 中包含的路由信息而选择的本地路由信息。这些是本地 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-RIBs-Out：Adj-RIBs-Out 存储本地 BGP 发言者选择向其对等方发布的信息。存储在 Adj-RIBs-Out 中的路由信息将在本地 BGP 发言者的 UPDATE 消息中携带，并向其对等方发布。
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 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-RIBs-In 包含同行向本地 BGP 演讲者发布的未处理路由信息；Loc-RIB 包含本地 BGP 演讲者的决策过程选择的路由；Adj-RIBs-Out（通过本地演讲者的 UPDATE 消息）组织路由，以便向特定同行发布。
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-RIBs-In、Loc-RIB 和 Adj-RIBs-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker:
标记：
This 16-octet field is included for compatibility; it MUST be set to all ones.
这个 16 八位字节字段是为了兼容而加入的，必须设置为全 1。
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 八位无符号整数表示报文的总长度，包括以八位字节为单位的报文头。因此，它允许我们在 TCP 流中找到下一条报文的（标记字段）。长度字段的值必须始终至少为 19，不大于 4096，并可根据报文类型进一步限制。不允许在报文后 "填充 "额外数据。因此，考虑到报文的其他内容，Length 字段必须具有所需的最小值。
Type:
类型
This 1-octet unsigned integer indicates the type code of the message. This document defines the following type codes:
这个 1 八位无符号整数表示报文的类型代码。本文件定义了以下类型代码：
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 连接建立后，双方发送的第一个报文是 OPEN 报文。如果 OPEN 信息被接受，则会回发一条确认 OPEN 的 KEEPALIVE 信息。
In addition to the fixed-size BGP header, the OPEN message contains the following fields:
除了固定大小的 BGP 报头外，OPEN 报文还包含以下字段：
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 八位无符号整数表示报文的协议版本号。当前的 BGP 版本号是 4。
My Autonomous System:
我的自治系统
This 2-octet unsigned integer indicates the Autonomous System number of the sender.
这个 2 八位无符号整数表示发送方的自治系统编号。
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 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.
这个 2 八位无符号整数表示发送者建议的 "保持定时器 "值的秒数。收到 OPEN 消息后，BGP 说话者必须使用其配置的 "保持时间 "和 OPEN 消息中收到的 "保持时间 "中的较小值来计算 "保持计时器 "的值。保持时间必须为零或至少三秒。系统实施可以根据 "保持时间 "拒绝连接。计算值表示从发送方接收连续 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 Identifier 的值设置为分配给该 BGP 说话者的 IP 地址。BGP Identifier 的值在启动时确定，对每个本地接口和 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 八位无符号整数表示可选参数字段的总长度（以八位字节为单位）。如果该字段值为零，则表示没有可选参数。
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.
该字段包含一个可选参数列表，其中每个参数都以 <参数类型、参数长度、参数值> 三元组的形式编码。
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.
参数类型（Parameter Type）是一个八位字节字段，用于明确标识各个参数。参数长度是一个八位字节字段，包含以八位字节为单位的参数值字段的长度。参数值是一个长度可变的字段，根据参数类型字段的值进行解释。
[RFC3392] defines the Capabilities Optional Parameter.
[RFC3392]定义了能力可选参数。
The minimum length of the OPEN message is 29 octets (including the message header).
OPEN 报文的最小长度为 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 information loops and some other anomalies may be detected and removed from inter-AS routing.
UPDATE 消息用于在 BGP 对等方之间传输路由信息。UPDATE 消息中的信息可用于构建一个描述各自治系统关系的图。通过应用即将讨论的规则，可检测路由信息循环和其他一些异常情况，并将其从自治系统间路由中移除。
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):
UPDATE 消息用于向对等设备宣传共享共同路径属性的可行路由，或从服务中撤销多条不可行路由（见 3.1）。UPDATE 消息可同时公布一条可行路由并从服务中撤销多条不可行路由。UPDATE 报文始终包括固定大小的 BGP 报头，还包括其他字段，如下所示（注意，某些所示字段可能不会出现在每个 UPDATE 报文中）：
+-----------------------------------------------------+
| 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 表示没有路由退出服务，并且此 UPDATE 报文中没有 WITHDRAWN ROUTES 字段。
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 地址前缀都以 < 长度、前缀> 的 2 元组形式编码，其字段描述如下：
+---------------------------+
| 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 地址前缀的长度（比特）。长度为 0 表示前缀匹配所有 IP 地址（前缀本身为 0 个八位位组）。
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 八位无符号整数表示路径属性字段的总长度（以八位字节为单位）。它的值允许按以下规定确定网络层可达性字段的长度。
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 表示该 UPDATE 报文中既没有网络层可达性信息字段，也没有路径属性字段。
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.
每个 UPDATE 消息中都有一个长度可变的路径属性序列，但只包含撤销路由的 UPDATE 消息除外。每个路径属性都是一个长度可变的三元组 <属性类型、属性长度、属性值>。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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）。对于众所周知的属性和可选的非传递属性，Partial 位必须设置为 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:
ORIGIN 是众所周知的强制属性，用于定义路径信息的来源。数据八位位组可以有以下值：
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 INCOMPLETE - 通过其他方式获取的网络层可达性信息
Usage of this attribute is defined in 5.1.1.
该属性的用法在 5.1.1 中定义。
b) AS_PATH (Type Code 2):
b) AS_PATH（类型代码 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 路径段由一个三元组 < 路径段类型、路径段长度、路径段值> 表示。
The path segment type is a 1-octet length field with the following values defined:
路径段类型是一个长度为 1 八位字节的字段，定义了以下值：
Value Segment Type
价值细分类型
1 AS_SET: unordered set of ASes a route in the UPDATE message has traversed
1 AS_SET：UPDATE 消息中的路由所穿越的 AS 的无序集合
2 AS_SEQUENCE: ordered set of ASes a route in the UPDATE message has traversed
2 AS_SEQUENCE：UPDATE 消息中的路由所遍历的 AS 的有序集合
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 八位字节长度的字段，包含路径段值字段中 AS 的个数（而不是八位字节数）。
The path segment value field contains one or more AS numbers, each encoded as a 2-octet length field.
路径段值字段包含一个或多个 AS 号，每个 AS 号以 2 八位字节长度字段编码。
Usage of this attribute is defined in 5.1.2.
该属性的用法在 5.1.2 中定义。
c) NEXT_HOP (Type Code 3):
c) NEXT_HOP（类型代码 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 地址，该地址应被用作 UPDATE 消息中网络层可达性信息字段所列目的地的下一跳。
Usage of this attribute is defined in 5.1.3.
该属性的用法在 5.1.3 中定义。
d) MULTI_EXIT_DISC (Type Code 4):
d) MULTI_EXIT_DISC（类型代码 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) LOCAL_PREF（类型代码 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) ATOMIC_AGGREGATE （类型代码 6）
ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0.
ATOMIC_AGGREGATE 是众所周知的任意属性，长度为 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.
AGGREGATOR 是长度为 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
UPDATE 报文长度 - 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.
其中，UPDATE 报文长度是在固定大小的 BGP 报文头中编码的值，总路径属性长度和撤销路由长度是在 UPDATE 报文的可变部分中编码的值，23 是固定大小的 BGP 报文头、总路径属性长度字段和撤销路由长度字段的总长度。
Reachability information is encoded as one or more 2-tuples of the form <length, prefix>, whose fields are described below:
可达性信息编码为一个或多个形式为 < 长度、前缀> 的 2 元组，其字段描述如下：
+---------------------------+
| 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 地址前缀的长度（比特）。长度为 0 表示前缀匹配所有 IP 地址（前缀本身为 0 个八位位组）。
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).
UPDATE 报文的最小长度为 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.
一个 UPDATE 消息最多只能公布一组路径属性，但可以公布多个目的地，前提是这些目的地共享这些属性。给定 UPDATE 报文中包含的所有路径属性都适用于 UPDATE 报文 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.
一条 UPDATE 消息可列出多条要退出服务的路由。每条此类路由都由其目的地（以 IP 前缀表示）标识，它在 BGP 说话者--BGP 说话者连接的上下文中明确标识了该路由，而该路由之前已被向其做过广告。
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.
更新（UPDATE）报文可能只公布将退出服务的路由，在这种情况下，报文将不包括路径属性或网络层可达性信息。相反，UPDATE 报文可能只公布一条可行的路由，在这种情况下，WITHDRAWN ROUTES 字段就不必出现。
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.
更新报文不应在 "撤回路由"（WITHDRAWN ROUTES）和 "网络层可达性信息"（Network Layer Reachability Information）字段中包含相同的地址前缀。但是，BGP 说话者必须能够处理这种形式的 UPDATE 消息。BGP 说话者应将这种形式的 UPDATE 消息视为 WITHDRAWN ROUTES 不包含地址前缀。
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 的保持（keep-alive）机制来确定是否可与对等网络连接。相反，在对等节点之间交换 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code:
错误代码：
This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined:
这个 1 八位无符号整数表示通知类型。已定义的错误代码如下：
Error Code Symbolic Name Reference
错误代码 符号名称 参考
1 Message Header Error Section 6.1
1 报文头错误 第 6.1 节
2 OPEN Message Error Section 6.2
2 OPEN 信息错误 第 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 八位无符号整数提供了有关所报错误性质的更具体信息。每个错误代码可能有一个或多个与之相关的错误子代码。如果没有定义适当的错误子代码，则错误子代码字段使用零（无特定）值。
Message Header Error subcodes:
报文头错误子代码：
1 - Connection Not Synchronized. 2 - Bad Message Length. 3 - Bad Message Type.
1 - 连接不同步。2 - 报文长度错误。3 - 报文类型错误。
OPEN Message Error subcodes:
OPEN Message 错误子代码：
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 - 错误的对等 AS。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 - 无效 ORIGIN 属性。7 - [已废弃 - 参见附录 A]。8 - NEXT_HOP 属性无效。9 - 可选属性错误。10 - 无效网络字段。11 - 畸形 AS_PATH。
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.
本节将讨论 UPDATE 报文的路径属性。
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 的 UPDATE 消息中。其他属性则可自行决定，可以或不可以在特定的 UPDATE 消息中发送。
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 实现都支持所有可选属性。对未识别的可选属性的处理由属性标志八位位组（attribute flags octet）中的传递位（Transitive bit）的设置决定。具有未识别的传递性可选属性的路径应该被接受。如果具有未识别的传递性可选属性的路径被接受并传递给其他 BGP 对等体，那么该路径的未识别的传递性可选属性必须与路径一起传递给其他 BGP 对等体，并将属性标志八位位组中的部分位设置为 1。如果具有公认的传递性可选属性的路径被接受并传递给其他 BGP 对等体，且 Attribute Flags 八位位组中的 Partial 位被之前的某个 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.
同一属性（具有相同类型的属性）不能在特定 UPDATE 报文的路径属性字段中出现多次。
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.
强制类别是指如果 UPDATE 消息中包含 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
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.
ORIGIN 是众所周知的强制属性。ORIGIN 属性由发起相关路由信息的发言者生成。任何其他发言者都不得更改其值。
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 是众所周知的强制属性。该属性标识了此 UPDATE 报文中携带的路由信息所经过的自治系统。该列表的组件可以是 AS_SET 或 AS_SEQUENCE。
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 说话者的 UPDATE 消息中学到的路由时，它会根据路由将被发送到的 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_PATH 属性。
b) When a given BGP speaker advertises the route to an external peer, the advertising speaker updates the AS_PATH attribute as follows: 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.
b) 当某个 BGP 发言者向外部对等方发布路由广告时，发布广告的发言者会按以下方式更新 AS_PATH 属性：1) 如果 AS_PATH 的第一个路径段是 AS_SEQUENCE 类型，本地系统会将自己的 AS 号码作为序列的最后一个元素进行预输入（将其放在与协议报文中八进制数位置相对应的最左边）。如果预输入行为会导致 AS_PATH 段溢出（即超过 255 个 AS），则应预输入一个 AS_SEQUENCE 类型的新段，并将自己的 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_PATH 的第一个路径段是 AS_SET 类型，本地系统就会在 AS_PATH 中预置一个 AS_SEQUENCE 类型的新路径段，并在该路径段中包含自己的 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_PATH 为空，本地系统就会创建一个 AS_SEQUENCE 类型的路径段，将自己的 AS 放入该路径段，并将该路径段放入 AS_PATH。
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) 发端发言人在发送给外部对等节点的所有 UPDATE 消息的 AS_PATH 属性中的 AS_SEQUENCE 类型的路径段中包含自己的 AS 号码。在这种情况下，发端说话者自治系统的 AS 号将是路径段的唯一条目，该路径段也将是 AS_PATH 属性中的唯一段。
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) 发端发言者在发送给内部对等者的所有 UPDATE 消息中包含一个空 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:
NEXT_HOP 是众所周知的强制属性，它定义了路由器的 IP 地址，该地址应被用作 UPDATE 报文中所列目的地的下一跳。NEXT_HOP 属性的计算方法如下：
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 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).
1) 在向内部对等体发送报文时，如果路由不是本地起源的，则 BGP 发言者不应修改 NEXT_HOP 属性，除非它已被显式配置为将自己的 IP 地址作为 NEXT_HOP 进行通告。在向内部对等方公布本地生成的路由时，BGP 发言者应使用路由器的接口地址作为 NEXT_HOP，发言者可通过该路由器到达所公布的网络。如果路由直接连接到发言者，或者如果发言者可通过路由器到达所宣布网络的接口地址是内部对等地址，则 BGP 发言者应使用自己的 IP 地址作为 NEXT_HOP 属性（用于到达对等地址的接口地址）。
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 发言者可以使用内部对等路由器（或内部路由器）的接口地址作为 NEXT_HOP 属性，只要对等路由器 X 与该地址共享一个子网。这是一种 "第三方 "NEXT_HOP 属性。
- 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.
- 否则，如果所宣布的路由是从外部对等节点处学习的，则发言人可以在 NEXT_HOP 属性中使用发言人自己用于本地路由计算的任何相邻路由器的 IP 地址（从接收到的 NEXT_HOP 属性中得知），前提是对等节点 X 与该地址共享一个公共子网。这是 "第三方 "NEXT_HOP 属性的第二种形式。
- 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 演讲者的一个接口共享一个共同子网，演讲者可在 NEXT_HOP 属性中使用与该接口相关联的 IP 地址。这被称为 "第一方 "NEXT_HOP 属性。
- 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 说话者应在 NEXT_HOP 属性中使用该说话者用于建立与对等 X 的 BGP 连接的接口的 IP 地址。
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).
- 扬声器可以配置为传播 NEXT_HOP 属性。在这种情况下，当广播扬声器从其某个对等体学习到的路由时，广播路由的 NEXT_HOP 属性与学习到的路由的 NEXT_HOP 属性完全相同（扬声器不会修改 NEXT_HOP 属性）。
- 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 演讲者应使用演讲者在 NEXT_HOP 属性中使用的接口 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.
通常情况下，NEXT_HOP 属性的选择是为了选择最短的可用路径。BGP 说话者必须能够支持禁用第三方 NEXT_HOP 属性广告，以便处理不完善的桥接媒体。
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 讲路者发起的路由不得使用对等方的地址作为 NEXT_HOP 向对等方发布。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 发言者使用 NEXT_HOP 属性来确定实际出站接口和直接下一跳地址，这些接口和地址应被用来将中转数据包转发到相关目的地。
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.
直接下一跳地址是通过对 NEXT_HOP 属性中的 IP 地址执行递归路由查找操作，并使用路由表的内容来确定的，如果存在多个费用相等的条目，则选择一个条目。解析 NEXT_HOP 属性中 IP 地址的路由表条目将始终指定出站接口。如果条目指定了一个附加子网，但未指定下一跳地址，则 NEXT_HOP 属性中的地址应被用作直接下一跳地址。如果条目还指定了下一跳地址，则应将该地址用作数据包转发的直接下一跳地址。
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 接收，MULTI_EXIT_DISC 属性可通过 IBGP 传播给同一 AS 内的其他 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 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).
BGP 发言者必须实施一种机制（基于本地配置），允许从路由中删除 MULTI_EXIT_DISC 属性。如果 BGP 发言者被配置为从路由中删除 MULTI_EXIT_DISC 属性，则必须在确定路由的优先程度和执行路由选择（决策过程阶段 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 说话者向其他内部对等方发送的所有 UPDATE 消息中。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 联盟 [RFC3065] 外，BGP 发言者不得在向外部对等方发送的 UPDATE 消息中包含此属性。如果该属性包含在从外部对等体收到的 UPDATE 消息中，则接收方必须忽略该属性，BGP 联盟 [RFC3065] 的情况除外。
ATOMIC_AGGREGATE is a well-known discretionary attribute.
ATOMIC_AGGREGATE 是众所周知的自由属性。
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_PATH 通常包括一个 AS_SET，该 AS_SET 由聚合路由的 AS 集组成。在许多情况下，网络管理员可以确定聚合路由是否可以在不包含 AS_SET 的情况下安全地进行广告发布，并且不会形成路由环路。
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_SET 而被聚合的路由的 AS_PATH 中存在的部分 AS 号码，则聚合路由在向对等方发布广告时，应包含 ATOMIC_AGGREGATE 属性。
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute SHOULD NOT remove the attribute when propagating the route to other speakers.
收到带有 ATOMIC_AGGREGATE 属性的路由的 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.
收到带有 ATOMIC_AGGREGATE 属性的路由的 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.
收到带有 ATOMIC_AGGREGATE 属性的路由的 BGP 说话者需要注意，路由的 NLRI 中指定的通往目的地的实际路径虽然具有无环路属性，但可能不是路由的 AS_PATH 属性中指定的路径。
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.
AGGREGATOR 是一个可选的传递属性，可以包含在通过聚合形成的更新中（见第 9.2.2.2 节）。执行路由聚合的 BGP 发言者可添加 AGGREGATOR 属性，该属性应包含其自身的 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 连接）。如果未指定错误子代码，则必须使用 0。
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。如果报文头的标记字段与预期值不符，则发生同步错误，错误子代码必须设为连接未同步。
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
- 如果 OPEN 报文的长度字段小于 OPEN 报文的最小长度，或
- if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or
- 如果 UPDATE 报文的长度字段小于 UPDATE 报文的最小长度，或
- 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（打开）报文时检测到的所有错误都必须通过发送带有错误代码 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 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.
如果接收到的 OPEN 消息的版本字段中的版本号不受支持，则错误子代码必须设置为不受支持的版本号。数据字段是一个 2 八位无符号整数，表示本地支持的最大版本号，小于远程 BGP 对等体标价的版本号（如接收到的 OPEN 消息所示）；如果本地支持的最小版本号大于远程 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.
如果 OPEN（打开）报文的自主系统字段不可接受，则错误子码必须设置为 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.
如果 OPEN 报文的保持时间字段不可接受，则错误子代码必须设置为不可接受的保持时间。实施必须拒绝一秒或两秒的保持时间值。实现可以拒绝任何建议的保持时间。接受 "保持时间 "的实现必须使用协商的 "保持时间 "值。
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.
如果 OPEN 消息的 BGP Identifier（BGP 标识符）字段在语法上不正确，则错误子代码必须设置为 Bad BGP Identifier（BGP 标识符错误）。语法正确性是指 BGP Identifier 字段代表一个有效的单播 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.
如果 OPEN（打开）报文中的一个可选参数未被识别，则错误子码必须设置为不支持的可选参数。
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 报文时检测到的所有错误都必须通过发送带有错误代码 UPDATE 报文错误的 NOTIFICATION 报文来说明。错误子代码详细说明了错误的具体性质。
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).
如果任何已识别属性的属性标志（Attribute Flags）与属性类型代码（Attribute Type Code）相冲突，则错误子代码必须设置为属性标志错误（Attribute Flags Error）。数据字段必须包含错误属性（类型、长度和值）。
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).
如果任何已识别属性的 "属性长度"（Attribute Length）与预期长度（基于属性类型代码）相冲突，则 "错误子代码"（Error Subcode）必须设置为 "属性长度错误"（Attribute Length Error）。数据字段必须包含错误属性（类型、长度和值）。
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).
如果 ORIGIN 属性具有未定义的值，则错误子代码必须设置为无效 Origin 属性。数据字段必须包含未识别的属性（类型、长度和值）。
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 属性字段语法错误，则错误子代码必须设置为无效 NEXT_HOP 属性。数据字段必须包含错误的属性（类型、长度和值）。语法正确意味着 NEXT_HOP 属性代表一个有效的 IP 主机地址。
The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct:
NEXT_HOP 中的 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 跳，NEXT_HOP 中的 IP 地址必须是用于建立 BGP 连接的发送方 IP 地址，或者与 NEXT_HOP 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_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.
如果从外部对等体接收到 UPDATE 消息，本地系统可检查 AS_PATH 属性中最左边的 AS（与协议消息中八位位组的位置有关）是否等于发送消息的对等体的自治系统编号。如果检查确定情况并非如此，则必须将 "错误子代码"（Error Subcode）设置为 "畸形 AS_PATH"。
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.
如果任何属性在 UPDATE 报文中出现不止一次，则错误子代码必须设置为畸形属性列表。
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.
更新（UPDATE）报文中的 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 的 UPDATE 报文将被视为有效的 UPDATE 报文。
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.
如果系统在 OPEN 消息的保持时间字段中指定的时间内没有连续收到 KEEPALIVE、UPDATE 和/或 NOTIFICATION 消息，则会发送带有保持计时器已过期错误代码的 NOTIFICATION 消息，并关闭 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 有限状态机检测到的任何错误（如收到意外事件）都会通过发送带有错误代码 "有限状态机错误 "的 NOTIFICATION 消息来显示。
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 对等方可在任何给定时间选择通过发送带有错误代码 Cease 的通知消息来关闭其 BGP 连接。但是，当本节所示的致命错误确实存在时，不得使用 Cease NOTIFICATION 消息。
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 连接，因为从邻居收到的地址前缀数超过了本地配置的上限，那么说话者必须向邻居发送带有错误代码 Cease 的通知消息。发言者也可以在本地对此进行记录。
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 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:
收到 OPEN 消息后，本地系统必须检查处于 OpenConfirm 状态的所有连接。如果 BGP 发言者通过协议之外的方式知道了对等方的 BGP 标识符，它也可以检查处于 OpenSent 状态的连接。如果在这些连接中，有一个与远程 BGP 说话者的连接，其 BGP 标识符与 OPEN 消息中的标识符相同，且该连接与接收 OPEN 消息的连接发生碰撞，则本地系统将执行以下碰撞解决程序：
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 标识符（如 OPEN 消息中所指定）进行比较。比较 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 连接（已处于 OpenConfirm 状态的连接），并接受远程系统发起的 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 连接（与新收到的 OPEN 消息相关的连接），并继续使用现有的连接（已处于 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.
通过发送带有错误代码 Cease 的通知消息，可关闭 BGP 连接（由碰撞解决程序产生）。
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 说话者支持的最高版本号开始。如果打开尝试失败，并出现错误代码（OPEN Message Error）和错误子代码（Unsupported Version Number），则 BGP 发言者可获得其尝试的版本号、其对等方尝试的版本号、其对等方在通知消息中传递的版本号以及其支持的版本号。如果两个对等方确实支持一个或多个通用版本，那么这将使它们能够快速确定最高的通用版本。为了支持 BGP 版本协商，BGP 的未来版本必须保留 OPEN 和 NOTIFICATION 消息的格式。
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) AcceptConnectionsUnconfiguredPeers 2) AllowAutomaticStart 3) AllowAutomaticStop 4) CollisionDetectEstablishedState 5.允许自动停止 4) CollisionDetectEstablishedState 5)阻尼先锋振荡 6)延迟打开 7) DelayOpenTime 8)8) DelayOpenTimer 9) IdleHoldTime 10) IdleHoldTimer 11) PassiveTcpEstablishment 12) SendNOTIFICATIONwithoutOPEN 13) TrackTcpState
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 组：DelayOpen、DelayOpenTime、DelayOpenTimer 第 2 组：DampPeerOscillations、IdleHoldTime、IdleHoldTimerDampPeerOscillations, 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
可选会话属性：允许自动启动、允许自动停止、阻尼同行振荡、闲置时间、闲置定时器
Option 1: AllowAutomaticStart
选项 1：允许自动启动
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 对等连接 FSM 的逻辑确定应重新启动 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：允许自动停止
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：DampPeerOscillations
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：空闲等待计时器
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
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
可选会话属性：PassiveTcpEstablishment, TrackTcpState
Option 1: PassiveTcpEstablishment Description: This option indicates that the BGP FSM will passively wait for the remote BGP peer to establish the BGP TCP connection.
选项 1：PassiveTcpEstablishment（被动 TCP 建立） 描述：该选项表示 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
可选会话属性：延迟打开、延迟打开时间、延迟打开计时器、发送无打开通知、碰撞检测建立状态
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）内延迟发送 OPEN 消息。延迟时间允许远程 BGP 对等方有时间发送第一条 OPEN 消息。
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 connection. The DelayOpenTimer_Expires event (Event 12) is described in Section 8.1.3.
描述DelayOpenTimer 可选会话属性用于延迟发送连接上的 OPEN 消息。DelayOpenTimer_Expires 事件（事件 12）在第 8.1.3 节中有描述。
Value: Time in seconds
值：时间（秒
Option 4: SendNOTIFICATIONwithoutOPEN
选项 4：发送未打开的通知
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 允许对等方发送通知而无需先发送 OPEN 消息。如果没有这个可选会话属性，BGP 连接就会假定，在对等方发送 NOTIFICATION 消息之前，必须先由对等方发送 OPEN 消息。
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 实现的现有功能阐明 BGP FSM 描述。可选会话属性可能是为某个实现预先定义的，无法通过管理接口读取现有的正确实现。随着更新的 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 有限状态机发出了某种启动或停止机制的信号。事件 5 "AutomaticStart_with_PassiveTcpEstablishment "就是这种组合的一个例子。通过该事件，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（ManualStart）和事件 2（ManualStop）是强制性管理事件。所有其他管理事件都是可选事件（事件 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.
在某些实现中，可选会话属性的设置可能是隐式的，因此可能无法通过外部操作符操作进行显式设置。第 8.2.1.5 节描述了这些可选会话属性的隐式设置。下面描述的管理状态在某些实现中也可能是隐式的，外部操作员无法直接配置。
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.
可选属性状态：PassiveTcpEstablishment 属性应设置为 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) 如果支持 PassiveTcpEstablishment 可选会话属性，则应将其设置为 FALSE。3) 如果支持 DampPeerOscillations，则在发生此事件时应将其设置为 FALSE。
Event 4: ManualStart_with_PassiveTcpEstablishment
事件 4： ManualStart_with_PassiveTcpEstablishment
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.
定义本地系统管理员手动启动对等设备连接，但已启用 PassiveTcpEstablishment。PassiveTcpEstablishment 可选属性表示对等设备将在建立连接前监听。
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) 如果发生此事件，PassiveTcpEstablishment 属性应设置为 "true"。2) 如果发生此事件，DampPeerOscillations 属性应设置为 FALSE。
Event 5: AutomaticStart_with_PassiveTcpEstablishment
事件 5：自动启动（AutomaticStart_with_PassiveTcpEstablishment
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.
定义：本地系统在启用 PassiveTcpEstablishment 后自动启动 BGP 连接。PassiveTcpEstablishment 可选属性表示对等方将在建立连接前监听。
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) PassiveTcpEstablishment 属性应设置为 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) PassiveTcpEstablishment 属性应设置为 FALSE。
Event 7: AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment
事件 7：自动启动_带有_阻尼同行振荡_和_被动 TcpEstablishment
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 对等连接，并启用对等振荡抑制和 PassiveTcpEstablishment。阻尼持续对等点振荡的具体方法由实现决定，不在本文档讨论范围之内。
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) PassiveTcpEstablishment 属性应设置为 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_Expires
Definition: An event generated when the ConnectRetryTimer expires.
定义ConnectRetryTimer 过期时生成的事件。
Status: Mandatory
状态强制性
Event 10: HoldTimer_Expires
事件 10：定时器到期
Definition: An event generated when the HoldTimer expires.
定义HoldTimer 过期时生成的事件。
Status: Mandatory
状态强制性
Event 11: KeepaliveTimer_Expires
事件 11：KeepaliveTimer_Expires
Definition: An event generated when the KeepaliveTimer expires.
定义KeepaliveTimer 过期时生成的事件。
Status: Mandatory
状态强制性
Event 12: DelayOpenTimer_Expires
事件 12： DelayOpenTimer_Expires
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_Expires
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 可选属性设置为 "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_Valid
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 地址和无效目标 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_CR_无效
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.
BGP 目的地端口号应为 179，由 IANA 定义。
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_CR_Acked
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：TcpConnectionConfirmed
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.
定义当收到有效的 OPEN 报文时，就会生成一个事件。
Status: Mandatory
状态强制性
Optional Attribute Status: 1) The DelayOpen optional attribute SHOULD be set to FALSE. 2) The DelayOpenTimer SHOULD not be running.
可选属性状态：1) 延迟打开可选属性应设置为 FALSE。2) DelayOpenTimer 不应运行。
Event 20: BGPOpen with DelayOpenTimer running
事件 20：运行延迟打开计时器的 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.
定义：如果已成功建立传输连接的对等点收到了有效的 OPEN 消息，而该对等点目前正在延迟发送 BGP OPEN 消息，则会生成一个事件。
Status: Optional
状态可选
Optional Attribute Status: 1) The DelayOpen attribute SHOULD be set to TRUE. 2) The DelayOpenTimer SHOULD be running.
可选属性状态：1) 延迟打开属性应设置为 "true"。2) DelayOpenTimer 应该正在运行。
Event 21: BGPHeaderErr
事件 21：BGPHeaderErr
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.
定义当接收到 OPEN 报文并出现错误时，就会产生一个事件。
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.
定义当处理传入的 OPEN（打开）报文时检测到连接碰撞，且该连接已被选择断开时，在管理上生成的事件。有关碰撞检测的更多信息，请参阅第 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) CollisionDetectEstablishedState（碰撞检测已建立状态）可选属性应设置为 "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：NotifMsgVerErr
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：更新信息
Definition: An event is generated when a valid UPDATE message is received.
定义接收到有效的 UPDATE 消息时会生成一个事件。
Status: Mandatory
状态强制性
Event 28: UpdateMsgErr
事件 28：UpdateMsgErr
Definition: An event is generated when an invalid UPDATE message is received.
定义接收到无效的 UPDATE 信息时会生成一个事件。
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 连接中发送第一个 TCP SYN 数据包的一方）称为传出方。被动或监听方（第一个 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 和 PassiveTcpEstablishment，则必须支持事件 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 连接。不会为对等节点分配资源。本地系统响应 ManualStart 事件（事件 1）或 AutomaticStart 事件（事件 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:
本地系统响应 ManualStart_with_PassiveTcpEstablishment 事件（事件 4）或 AutomaticStart_with_PassiveTcpEstablishment 事件（事件 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),
- AutomaticStart_with_DampPeerOscillations （事件 6）、
- AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment (Event 7),
- AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment（事件 7）、
- IdleHoldTimer_Expires (Event 13).
- IdleHoldTimer_Expires （事件 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,
- 向其对等节点发送 OPEN 消息、
- 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_Valid 事件（事件 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_Invalid 事件（事件 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
- 会将延迟打开计时器设置为初始值，并且
- 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,
- 向其对等节点发送 OPEN 消息、
- 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 运行期间收到 OPEN 信息（事件 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,
- 发送 OPEN 信息、
- 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）或 OPEN 报文检查检测到错误（事件 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:
如果收到带有版本错误的 NOTIFICATION 消息（事件 24），本地系统将检查 DelayOpenTimer。如果 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 会话属性，则本地系统会发送带有 Cease 的通知、
- 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,
- 向其远程对等节点发送 OPEN 消息、
- 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.
还建议将此状态转换的 HoldTimer 值设为 4 分钟。
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_Valid 事件（事件 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_Invalid 事件（事件 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
- 会将延迟打开计时器设置为初始值（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,
- 向其对等节点发送 OPEN 消息、
- 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:
如果收到 OPEN（打开）报文，且 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,
- 发送 OPEN 信息、
- 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
否则，如果 HoldTimer 为零
- 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）或 OPEN 报文检查检测到错误（事件 22）（参见第 6.2 节），则本地系统：
- (optionally) sends a NOTIFICATION message with the appropriate error code if the SendNOTIFICATIONwithoutOPEN attribute is set to TRUE,
- (可选）如果 SendNOTIFICATIONwithoutOPEN 属性设置为 "true"，则发送带有相应错误代码的 NOTIFICATION 消息、
- 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:
如果收到带有版本错误的 NOTIFICATION 消息（事件 24），本地系统将检查 DelayOpenTimer。如果 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 增加一个、
- (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 等待来自其对等网络的 OPEN 消息。
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_Expires （事件 10）发生，本地系统就会启动：
- sends a 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,
- 会递增 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.
如果收到 TcpConnection_Valid（事件 14）、Tcp_CR_Acked（事件 16）或 TcpConnectionConfirmed（事件 17）事件，则第二个 TCP 连接可能正在进行中。第二个 TCP 连接将根据连接碰撞处理（第 6.8 节）进行跟踪，直到收到 OPEN 消息。
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:
收到 OPEN（打开）报文后，将检查所有字段是否正确。如果 OPEN 报文中没有错误（事件 19），本地系统就会发送 OPEN 报文：
- 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.)
如果协商的保持时间值为零，则不启动 HoldTimer 和 KeepaliveTimer。如果自治系统字段的值与本地自治系统编号相同，则该连接为 "内部 "连接；否则为 "外部 "连接。(这将影响 UPDATE 处理（如下所述）。
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）或 OPEN 报文检查检测到错误（事件 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 CollisionDetectDump event occurs when the BGP implementation determines, by means outside the scope of this document, that a connection collision has occurred.
当收到有效的 BGP OPEN 消息（事件 19 或事件 20）时，需要应用碰撞检测机制（第 6.8 节）。有关比较的详情，请参阅第 6.8 节。当 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:
打开确认状态：
In this state, BGP waits for a KEEPALIVE or NOTIFICATION message.
在此状态下，BGP 等待 KEEPALIVE 或 NOTIFICATION 消息。
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,
- 发送带有 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,
- 发送带有 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），则本地系统将发送 KEEPALIVE 消息：
- 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.
- 仍处于 OpenConfirmed 状态。
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_Valid 事件（事件 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）或 NOTIFICATION 消息（事件 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:
如果本地系统收到带有版本错误的通知报文（NotifMsgVerErr (事件 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:
如果本地系统收到有效的 OPEN（打开）报文（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:
如果收到 OPEN 报文，将检查所有字段是否正确。如果 BGP 报文头检查（BGPHeaderErr (事件 21)）或 OPEN 报文检查检测到错误（见第 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:
如果在处理另一个 OPEN 消息期间，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 可与其对等方交换 UPDATE、NOTIFICATION 和 KEEPALIVE 消息。
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,
- 发送带有 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 收到的 UPDATE 信息中包含给定对等点的前缀数，以至于收到的总前缀数超过了配置的最大前缀数。本地系统会自动断开对等点连接。
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,
- 发送包含错误代码保持计时器已过期的通知信息、
- 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_CR_Invalid 事件（事件 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），第二个连接应被跟踪，直到它发送 OPEN 消息。
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:
如果接收到有效的 OPEN 消息（BGPOpen (事件 19)），且 CollisionDetectEstablishedState 可选属性为 TRUE，则将检查 OPEN 消息是否与任何其他连接发生碰撞（第 6.8 节）。如果 BGP 实现认为此连接需要终止，它将处理 OpenCollisionDump 事件（事件 23）。如果需要终止此连接，本地系统将处理 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 的 NOTIFICATION 消息（事件 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:
如果本地系统收到 UPDATE 信息（事件 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:
如果本地系统接收到 UPDATE 报文，且 UPDATE 报文错误处理程序（见第 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.
只能在 "已建立 "状态下接收 UPDATE 消息。在任何其他状态下接收 UPDATE 消息都是错误。收到 UPDATE 消息后，将按照第 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.
如果 UPDATE 消息包含一个非空的 WITHDRAWN ROUTES（撤回路由）字段，则应从 Adj-RIB-In 中删除该字段中包含的目的地（以 IP 前缀表示）的先前已发布路由。该 BGP 发言者应运行其 "决策过程"（Decision Process），因为先前公布的路由已不再可用。
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.
如果 UPDATE 消息包含一条可行路由，则 Adj-RIB-In 将按以下方式更新该路由：如果新路由的 NLRI 与当前存储在 Adj-RIB-In 中的路由的 NLRI 相同，则新路由应取代 Adj-RIB-In 中的旧路由，从而隐式地从服务中撤销旧路由。否则，如果 Adj-RIB-In 中没有 NLRI 与新路由相同的路由，则应将新路由放入 Adj-RIB-In。
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-RIBs-In 中的路由，从而为后续广告选择路由。决策过程的输出是将向对等方发布广告的路由集；选定的路由将根据策略存储在本地发言人的 Adj-RIBs-Out 中。
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-RIBs-In 中包含的路由上运行，并负责
- 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-RIB 中。
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) 第 3 阶段在 Loc-RIB 被修改后调用。它负责根据 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 发言者从对等方接收到宣传新路由、替换路由或撤销路由的 UPDATE 消息时，就会调用第 1 阶段决策功能。
The Phase 1 decision function is a separate process,f which completes when it has no further work to do.
第 1 阶段的决策功能是一个单独的流程f ，当它没有其他工作要做时就会结束。
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，并在对 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.
如果路由是从内部对等设备上学习的，则会将 LOCAL_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 读广告中的 LOCAL_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.
第 1 阶段完成后，将调用第 2 阶段的决策功能。第 2 阶段功能是一个单独的流程，当它没有其他工作要做时就会结束。第 2 阶段流程会考虑 Adj-RIBs-In 中所有符合条件的路由。
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 阶段功能在开始运行之前会锁定所有 Adj-RIB-In，并在完成后解除锁定。
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 路由的 NEXT_HOP 属性描述的地址不可解析，或如果该路由安装在路由表中将变得不可解析，则必须将该 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_PATH 属性包含 AS 循环，则该 BGP 路由应从第 2 阶段决策功能中排除。AS 循环检测是通过扫描完整的 AS 路径（如 AS_PATH 属性中指定的），并检查本地系统的自治系统编号是否没有出现在 AS 路径中来完成的。BGP 发言者的操作被配置为接受 AS 路径中包含其自身自治系统编号的路由，这不属于本文档的讨论范围。
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-RIBs-In 中存在可行路由的每一组目的地，本地 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-RIB 中，替换当前在 Loc-RIB 中保留的通往同一目的地的任何路由。在路由表中安装新的 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.
本地发言人必须根据所选路由的 NEXT_HOP 属性确定直接下一跳地址（参见第 5.1.3 节）。如果立即下一跳或到 NEXT_HOP（NEXT_HOP 通过 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 路由转发任何数据包之前，必须将其相关的 NEXT_HOP 地址解析为直接（直接连接的）下一跳地址，并将该地址（或多个地址）最终用于实际数据包转发。
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-RIB 和路由表中删除。但是，相应的不可解析路由应保留在 Adj-RIBs-In 中（以防它们变成可解析路由）。
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) 如果路由表中至少有一条可解析路由 Rte2 与 Rte1 的中间网络地址相匹配，且未通过 Rte1 进行递归解析（直接或间接），则仅引用中间网络地址的路由 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) 如果引用的接口状态为 up，且该接口上启用了 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 路由的 NEXT_HOP 匹配的路由时，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.
同样重要的是，实施过程中不要考虑那些一旦安装到路由表中就无法解析的可行路由，即使其 NEXT_HOP 可使用路由表的当前内容解析（此类路由的一个例子是相互递归路由）。这种检查可确保 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 发言者都能确定到路由的 NEXT_HOP 属性所描述地址的路径成本（内部距离），并遵循相同的路由选择算法。
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_PATH 属性中存在 AS 号数最少且不并列的路由。请注意，在计算这个数字时，无论集合中有多少个 AS，AS_SET 都算作 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 属性较差的路由。MULTI_EXIT_DISC 仅在从同一相邻 AS（相邻 AS 由 AS_PATH 属性决定）学习的路由之间具有可比性。没有 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
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.
同样，neighbourAS(n) 也是一个返回接收路由的邻居 AS 的函数。如果路由是通过 IBGP 学习的，且另一个 IBGP 发言者不是路由的发起者，那么它就是另一个 IBGP 发言者学习路由的邻居 AS。如果路由是通过 IBGP 学习的，而另一个 IBGP 发言者 (a) 发起了路由，或 (b) 通过聚合创建了路由，且聚合路由的 AS_PATH 属性为空或以 AS_SET 开头，则它是本地 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 学习的路由子集中移除 MULTI_EXIT_DISC，而所选的 "最佳" EBGP 学习的路由不会移除 MULTI_EXIT_DISC，那么在与 IBGP 学习的路由进行比较时就必须使用 MULTI_EXIT_DISC。对于 IBGP 学习的路由，MULTI_EXIT_DISC 必须在路由比较中使用，以达到 "决策过程 "中的这一步骤。将 EBGP 学习的路由的 MULTI_EXIT_DISC 与 IBGP 学习的路由进行比较，然后移除 MULTI_EXIT_DISC 属性并公布该路由，已被证明会导致路由循环。
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) 删除任何内部成本较低的路由。路由的内部成本是通过使用路由表计算到路由 NEXT_HOP 的度量来确定的。如果路由的 NEXT_HOP 跳可以到达，但无法确定成本，则应跳过这一步（等同于认为所有路由的成本相同）。
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 Identifier 值最低的 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 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).
根据配置的策略，Loc-RIB 中的所有路由都会被处理为 Adj-RIB-Out。该策略可排除将 Loc-RIB 中的路由安装到特定 Adj-RIB-Out 中。除非路由表可适当转发该路由所描述的目的地和 NEXT_HOP，否则不得在 Adj-RIB-Out 中安装该路由。如果 Loc-RIB 中的路由被排除在特定 Adj-RIB-Out 之外，则必须通过 UPDATE 消息（请参阅 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-RIBs-Out 和路由表更新完成后，本地 BGP 发言者运行 9.2 的 Update-Send 流程。
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 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.
如果 BGP 发言者收到重叠路由，则决策过程必须根据配置的接受策略考虑这两条路由。如果一条较小路由和一条较具体路由都被接受，那么 "决策过程 "必须在 Loc-RIB 中安装较小路由和较具体路由，或者将两条路由聚合，并在 Loc-RIB 中安装聚合路由，前提是两条路由的 NEXT_HOP 属性值相同。
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_SET 中包含用于形成聚合的所有 AS，或者在路由中添加 ATOMIC_AGGREGATE 属性。该属性现在主要是信息属性。随着不支持无类路由的 IP 路由协议的淘汰，以及不支持无类路由的路由器和主机实现的淘汰，不再需要去聚合。路由不应去聚类。特别是，带有 ATOMIC_AGGREGATE 属性的路由不得去聚类。也就是说，该路由的 NLRI 不能更具体。沿这样的路由转发并不能保证 IP 数据包实际上只遍历路由的 AS_PATH 属性中列出的 AS。
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.
更新发送进程负责向所有对等方发布 UPDATE 消息。例如，它将决策进程选择的路由分发给其他 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 说话者从内部对等体接收到 UPDATE 消息时，接收的 BGP 说话者不得将该 UPDATE 消息中包含的路由信息重新分配给其他内部对等体（除非该说话者充当 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-RIBs-Out。所有新安装的路由和所有没有替代路由的新不可行路由都应通过 UPDATE 消息向其对等方发布。
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.
如果生成的 UPDATE 消息中包含与先前广告相同的 BGP 路由，则 BGP 发言者不应在其 Adj-RIB-Out 中广告给定的可行 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-RIB 中任何被标记为不可行的路由都将被删除。自治系统内可到达目的地的变更也应在 UPDATE 消息中公布。
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.
如果由于 UPDATE 报文最大大小的限制（见第 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 协议限制路由流量（即 UPDATE 消息），以限制发布 UPDATE 消息所需的链路带宽和决策进程消化 UPDATE 消息所含信息所需的处理能力。
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.
参数 MinRouteAdvertisementIntervalTimer 决定了 BGP 发言者向对等方发布和/或撤回到特定目的地的路由之间必须间隔的最短时间。尽管 MinRouteAdvertisementIntervalTimer 的值是根据每个 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 说话者向同行发送的两条 UPDATE 消息，如果是向某些共同目的地集公布可行路由和/或撤销不可行路由，则必须至少间隔 MinRouteAdvertisementIntervalTimer（最小路由广告间隔计时器）。要做到这一点，只能为每一组共同目的地保留一个单独的计时器。这将是不必要的开销。任何能确保从 BGP 说话者向同行发送的两条 UPDATE 消息之间的间隔至少为 MinRouteAdvertisementIntervalTimer（最小路由广告间隔计时器），并能确保间隔的恒定上限是可接受的。
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) 内部对等节点使用的 MinRouteAdvertisementIntervalTimer 应短于外部对等节点使用的 MinRouteAdvertisementIntervalTimer，或 (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.
本程序不限制路由选择的速率，只限制路由广告的速率。如果在等待 MinRouteAdvertisementIntervalTimer（最小路由广告间隔计时器）到期期间多次选择新路由，则应在 MinRouteAdvertisementIntervalTimer（最小路由广告间隔计时器）结束时公布最后选择的路由。
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 决定了连续发布 UPDATE 消息（报告发布 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:
决策过程可选择通过以下任一方法减少 Adj-RIBs-Out 中的信息量：
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 地址前缀表示。在地址结构与自治系统管理员控制的系统之间存在对应关系的情况下，可以减少 UPDATE 报文中携带的 NLRI 的大小。
b) AS_PATHs:
b) AS_PATHs：
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_SEQUENCE 或无序的 AS_SET。AS_SET 用于第 9.2.2.2 节所述的路由聚合算法。无论 AS_PATH 在多个 AS_PATH 中出现过多少次，AS_SET 都只列出一次，从而减少了 AS_PATH 信息的大小。
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_SET 意味着 NLRI 中列出的目的地可以通过至少部分组成自治系统的路径到达。AS_SET 提供了足够的信息来避免路由信息循环；但是，使用 AS_SET 可能会删除潜在的可行路径，因为这些路径不再以 AS_SEQUENCE 的形式单独列出。在实践中，这可能不是一个问题，因为一旦 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-RIBs-Out 中的路由信息量。
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.
不得聚合具有不同 MULTI_EXIT_DISC 属性的路由。
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_PATH 属性中第一个元素是 AS_SET，则路由的发起路由器不应将 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.
NEXT_HOP：当聚合具有不同 NEXT_HOP 属性的路由时，聚合路由的 NEXT_HOP 属性应标识执行聚合的 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 属性：如果聚合路由中至少有一条路由的 ORIGIN 值为 INCOMPLETE，则聚合路由的 ORIGIN 属性值必须为 INCOMPLETE。否则，如果聚合路由中至少有一条路由的 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_PATH 属性：如果要聚合的路由具有相同的 AS_PATH 属性，则聚合路由的 AS_PATH 属性与每个单独路由相同。
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 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_PATH 属性，我们将 AS_PATH 属性中的每个 AS 建模为一个元组 <type，value>，其中 "type "表示 AS 所属路径段的类型（如 AS_SEQUENCE、AS_SET），"value "表示 AS 编号。如果要聚合的路由具有不同的 AS_PATH 属性，那么聚合的 AS_PATH 属性必须满足以下所有条件：
- 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_PATH 中所有 AS_SEQUENCE 类型的图元都应出现在要聚合的初始路由集中的所有 AS_PATH 中。
- 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_PATH 中所有 AS_SET 类型的元组都应至少出现在初始集合中的一个 AS_PATH 中（它们既可以是 AS_SET 类型，也可以是 AS_SEQUENCE 类型）。
- 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_PATH 中任何 AS_SEQUENCE 类型的元组 X，如果该元组在聚合 AS_PATH 中排在元组 Y 之前，则无论 Y 的类型如何，在初始集合中每个包含 Y 的 AS_PATH 中，X 都排在 Y 之前。
- No tuple of type AS_SET with the same value SHALL appear more than once in the aggregated AS_PATH.
- 在聚合 AS_PATH 中，具有相同值的 AS_SET 类型元组不得出现一次以上。
- 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.
- 具有相同值的 AS_SEQUENCE 类型的多个图元，只有在与另一个相同类型和值的图元相邻时，才能出现在汇总的 AS_PATH 中。
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_PATH 属性所共有的元组的最长前导序列（如上定义）。将此序列作为聚合 AS_PATH 属性的前导序列。
- 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_PATH 属性中其余图元的类型设为 AS_SET，并把它们追加到聚合的 AS_PATH 属性中。
- 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_PATH 有多个具有相同值的元组（无论元组的类型如何），则通过从聚合 AS_PATH 属性中删除 AS_SET 类型的元组，除一个元组外消除所有其他元组。
- 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.
- 对于聚合 AS_PATH 中的每一对相邻图元，如果两个图元的类型相同，则将它们合并在一起，只要这样做不会导致生成长度大于 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.
ATOMIC_AGGREGATE：如果要聚合的路由中至少有一条具有 ATOMIC_AGGREGATE 路径属性，则聚合路由也应具有此属性。
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).
AGGREGATOR：要聚合的路由中的任何 AGGREGATOR 属性都不得包含在聚合路由中。执行路由聚合的 BGP 说话者可以附加新的 AGGREGATOR 属性（请参阅第 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 说话者可通过向 BGP 注入以其他方式（如通过 IGP）获取的路由信息来创建 BGP 路由。生成 BGP 路由的 BGP 说话者通过 "决策过程"（见第 9.1 节）为这些路由分配优先级（如根据本地配置）。作为更新流程的一部分，这些路由也可能被分发到本地 AS 内的其他 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 节）和 MinRouteAdvertisementIntervalTimer（见第 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 支持 DelayOpenTimer 和 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 的初始值。建议的 HoldTime 默认值为 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 的默认值为 HoldTime 的 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 连接上 MinRouteAdvertisementIntervalTimer 的建议默认值为 30 秒。
The suggested default value for the MinRouteAdvertisementIntervalTimer on IBGP connections is 5 seconds.
IBGP 连接上 MinRouteAdvertisementIntervalTimer 的建议默认值为 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、MinRouteAdvertisementIntervalTimer 和 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.
澄清 AGGREGATOR 属性中 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_PATH 属性中包含一个以上自身 AS 实例的能力，用于 AS 间流量工程。
Clarification of the various types of NEXT_HOPs.
澄清各类 NEXT_HOP。
Clarification of the use of the ATOMIC_AGGREGATE attribute.
澄清 ATOMIC_AGGREGATE 属性的使用。
The relationship between the immediate next hop, and the next hop as specified in the NEXT_HOP path attribute.
直接下一跳与 NEXT_HOP 路径属性中指定的下一跳之间的关系。
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（AS 路由环路）已被弃用。
OPEN Message Error subcode 5 (Authentication Failure) has been deprecated.
OPEN 报文错误子代码 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.
已引入一个新属性 ATOMIC_AGGREGATE，以确保某些聚合不会被去聚合。另一个新属性 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.
为确保保持定时器的对称性，现在保持定时器是按连接协商确定的。现在支持 0 的保持计时器。
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 连接碰撞，在 OPEN 消息中增加了一个新字段（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.
新文件不再限制 NEXT_HOP 路径属性中传递的路由器必须与 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.
为了适应 BSD 4.3 版提供的 TCP 用户界面，有必要对 [RFC1105] 有限状态机稍作改动。
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 报文头中删除，并添加到 OPEN 报文中。
2. The version field has been removed from the BGP header and added to the OPEN message.
2. 版本字段已从 BGP 报文头中删除，并添加到 OPEN 报文中。
3. The Link Type field has been removed from the OPEN message.
3. 链接类型字段已从 OPEN（打开）报文中删除。
4. The OPEN CONFIRM message has been eliminated and replaced with implicit confirmation, provided by the KEEPALIVE message.
4. 取消了 OPEN CONFIRM 消息，代之以 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. 更新（UPDATE）报文的格式发生了重大变化。更新信息中增加了新字段，以支持多个路径属性。
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 PUSH 功能，则在传输每个 BGP 报文时都应设置 PUSH 标志。设置 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 说话者如果需要撤回一个目的地并发送关于更具体或不太具体的路由的更新，应将它们合并到同一 UPDATE 消息中。
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_SET 排序
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_SET 中的 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_PATH 聚合
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_PATH 属性，我们将每个 AS 建模为一个元组 <type，value>，其中 "type "表示 AS 所属路径段的类型（如 AS_SEQUENCE、AS_SET），"value "表示 AS 编号。如果两个 AS 对应的 <type, value> 元组相同，则称这两个 AS 相同。
The algorithm to aggregate two AS_PATH attributes works as follows:
聚合两个 AS_PATH 属性的算法如下：
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_PATH 属性中，找出在两个 AS_PATH 属性中相对顺序相同的相同 AS（如上定义）。两个 AS（X 和 Y）在以下任一情况下被称为顺序相同：
- X precedes Y in both AS_PATH attributes, or - Y precedes X in both AS_PATH attributes.
- X 在两个 AS_PATH 属性中都在 Y 之前，或 - Y 在两个 AS_PATH 属性中都在 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_PATH 属性由(a)中确定的 AS 组成，其顺序与它们在要聚合的 AS_PATH 属性中出现的顺序完全相同。如果(a)中确定的两个连续的 AS 在要聚合的两个 AS_PATH 属性中都不是紧接着对方，那么两个属性中的中间 AS（两个连续 AS 之间相同的 AS）就会合并成一个 AS_SET 路径段，该路径段由两个 AS_PATH 属性中的中间 AS 组成。然后，该路径段被放置在聚合属性(a)中确定的两个连续 AS 之间。如果(a)中确定的两个连续 AS 在一个属性中紧随其后，但在另一个属性中不紧随其后，则后者的中间 AS 合并为一个 AS_SET 路径段。然后，将该路径段置于聚合属性(a)中确定的两个连续 AS 之间。
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) 对于聚合 AS_PATH 中的每一对相邻图元，如果两个图元的类型相同，则将它们合并在一起，前提是这样做不会导致生成长度大于 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_PATH 属性中出现不止一次，则应从聚合 AS_PATH 属性中删除该 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
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 UPDATE 消息可携带一个或多个路径属性，每个属性包含一个 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
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
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
This document defines the following OPEN Message Error subcodes:
本文件定义了以下 OPEN 报文错误子代码：
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:
本文件定义了以下 UPDATE 报文错误子代码：
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., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[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, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Informative References
参考性文献
[RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC1092] Rekhter, J., "EGP and policy based routing in the new NSFNET backbone", RFC 1092, February 1989.
[RFC1092] Rekhter, J., "EGP and policy based routing in the new NSFNET backbone", RFC 1092, February 1989.
[RFC1093] Braun, H., "NSFNET routing architecture", RFC 1093, February 1989.
[RFC1093] Braun, H., "NSFNET 路由结构"，RFC 1093，1989 年 2 月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105] Lougheed、K. 和 Y. Rekhter，"边界网关协议（BGP）"，RFC 1105，1989 年 6 月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[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. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1772] Rekhter, Y. and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[Rekhter, Y. and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[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., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[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., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[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., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[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., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[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
Yakov Rekhter 瞻博网络
EMail: [email protected]
Tony Li
托尼-李
EMail: [email protected]
Susan Hares NextHop Technologies, Inc. 825 Victors Way Ann Arbor, MI 48108
Susan Hares NextHop Technologies, Inc.825 Victors Way Ann Arbor, MI 48108
Phone: (734)222-1610 EMail: [email protected]
电话：(734)222-1610 电子邮件：[email protected]
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 不对任何知识产权或其他权利的有效性或范围，或可能声称与本文档所述技术的实施或使用有关的权利，或在多大程度上可以或不可以获得此类权利下的任何许可采取任何立场；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 秘书处披露的知识产权副本、将提供的任何许可保证，或为本规范的实施者或用户使用此类专有权而试图获得一般许可或授权的结果，均可从 http://www.ietf.org/ipr 的 IETF 在线知识产权库中获取。
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 [email protected].
IETF 邀请任何有关方面提请其注意可能涉及实施本标准所需技术的任何版权、专利或专利申请，或其他专有权利。请将信息发送至 IETF：[email protected]。
Acknowledgement
致谢
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC 编辑职能的经费由 IETF 行政支持活动 (IASA) 提供。