Network Working Group D. Thaler
Request for Comments: 3913 Microsoft
Category: Informational September 2004
Network Working Group D. Thaler
Request for Comments: 3913 Microsoft
Category: Informational September 2004
Border Gateway Multicast Protocol (BGMP): Protocol Specification
边界网关多播协议（BGMP）：协议规范
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants.
本文档描述了边界网关多播协议（BGMP），一种用于域间多播路由的协议。BGMP为活动多播组构建共享树，并允许接收方域在需要时构建特定于源的域间分发分支。BGMP本机支持“源特定多播”（SSM）。为了还支持“任意源多播”（ASM），BGMP要求每个多播组与单个根关联（在BGMP中称为根域）。它要求多播地址空间的不同范围与不同的域相关联（例如，与基于单播前缀的多播寻址相关联）。然后，这些域中的每个域都成为其范围内所有组的共享域树的根。如果会话发起方的地址分配器从其自己域的空间部分选择地址，从而使根域对会话参与者中的至少一个是本地的，则组播参与者通常将获得更好的组播服务。
Table of Contents
目录
1. Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Interaction with the EGP . . . . . . . . . . . . . . . . 8
4.2. Multicast Data Packet Processing . . . . . . . . . . . . 9
4.3. BGMP processing of Join and Prune messages and
notifications. . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Receiving Joins. . . . . . . . . . . . . . . . . 10
4.3.2. Receiving Prune Notifications. . . . . . . . . . 11
4.3.3. Receiving Route Change Notifications . . . . . . 12
4.3.4. Receiving (S,G) Poison-Reverse messages. . . . . 12
4.4. Interaction with M-IGP components. . . . . . . . . . . . 13
4.4.1. Interaction with DVMRP and PIM-DM. . . . . . . . 14
4.4.2. Interaction with PIM-SM. . . . . . . . . . . . . 15
4.4.3. Interaction with CBT . . . . . . . . . . . . . . 16
4.4.4. Interaction with MOSPF . . . . . . . . . . . . . 17
4.5. Operation over Multi-access Networks . . . . . . . . . . 17
4.6. Interaction between (S,G) state and G-routes . . . . . . 18
5. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Message Header Format. . . . . . . . . . . . . . . . . . 19
5.2. OPEN Message Format. . . . . . . . . . . . . . . . . . . 19
5.3. UPDATE Message Format. . . . . . . . . . . . . . . . . . 23
5.4. Encoding examples. . . . . . . . . . . . . . . . . . . . 27
5.5. KEEPALIVE Message Format . . . . . . . . . . . . . . . . 27
5.6. NOTIFICATION Message Format. . . . . . . . . . . . . . . 28
6. BGMP Error Handling. . . . . . . . . . . . . . . . . . . . . . 30
6.1. Message Header error handling. . . . . . . . . . . . . . 30
6.2. OPEN message error handling. . . . . . . . . . . . . . . 30
6.3. UPDATE message error handling. . . . . . . . . . . . . . 31
6.4. NOTIFICATION message error handling. . . . . . . . . . . 32
6.5. Hold Timer Expired error handling. . . . . . . . . . . . 32
6.6. Finite State Machine error handling. . . . . . . . . . . 32
6.7. Cease. . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.8. Connection collision detection . . . . . . . . . . . . . 32
7. BGMP Version Negotiation . . . . . . . . . . . . . . . . . . . 33
7.1. BGMP Capability Negotiation. . . . . . . . . . . . . . . 34
8. BGMP Finite State machine. . . . . . . . . . . . . . . . . . . 34
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
1. Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Interaction with the EGP . . . . . . . . . . . . . . . . 8
4.2. Multicast Data Packet Processing . . . . . . . . . . . . 9
4.3. BGMP processing of Join and Prune messages and
notifications. . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Receiving Joins. . . . . . . . . . . . . . . . . 10
4.3.2. Receiving Prune Notifications. . . . . . . . . . 11
4.3.3. Receiving Route Change Notifications . . . . . . 12
4.3.4. Receiving (S,G) Poison-Reverse messages. . . . . 12
4.4. Interaction with M-IGP components. . . . . . . . . . . . 13
4.4.1. Interaction with DVMRP and PIM-DM. . . . . . . . 14
4.4.2. Interaction with PIM-SM. . . . . . . . . . . . . 15
4.4.3. Interaction with CBT . . . . . . . . . . . . . . 16
4.4.4. Interaction with MOSPF . . . . . . . . . . . . . 17
4.5. Operation over Multi-access Networks . . . . . . . . . . 17
4.6. Interaction between (S,G) state and G-routes . . . . . . 18
5. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Message Header Format. . . . . . . . . . . . . . . . . . 19
5.2. OPEN Message Format. . . . . . . . . . . . . . . . . . . 19
5.3. UPDATE Message Format. . . . . . . . . . . . . . . . . . 23
5.4. Encoding examples. . . . . . . . . . . . . . . . . . . . 27
5.5. KEEPALIVE Message Format . . . . . . . . . . . . . . . . 27
5.6. NOTIFICATION Message Format. . . . . . . . . . . . . . . 28
6. BGMP Error Handling. . . . . . . . . . . . . . . . . . . . . . 30
6.1. Message Header error handling. . . . . . . . . . . . . . 30
6.2. OPEN message error handling. . . . . . . . . . . . . . . 30
6.3. UPDATE message error handling. . . . . . . . . . . . . . 31
6.4. NOTIFICATION message error handling. . . . . . . . . . . 32
6.5. Hold Timer Expired error handling. . . . . . . . . . . . 32
6.6. Finite State Machine error handling. . . . . . . . . . . 32
6.7. Cease. . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.8. Connection collision detection . . . . . . . . . . . . . 32
7. BGMP Version Negotiation . . . . . . . . . . . . . . . . . . . 33
7.1. BGMP Capability Negotiation. . . . . . . . . . . . . . . 34
8. BGMP Finite State machine. . . . . . . . . . . . . . . . . . . 34
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
It has been suggested that inter-domain "any-source" multicast is better supported with a rendezvous mechanism whereby members receive sources' data packets without any sort of global broadcast (e.g., MSDP broadcasts source information, PIM-DM [PIMDM] and DVMRP [DVMRP] broadcast initial data packets, and MOSPF [MOSPF] broadcasts membership information). PIM-SM [PIMSM] and CBT [CBT] use a shared group-tree, to which all members join and thereby hear from all sources (and to which non-members do not join and thereby hear from no sources).
有人建议，域间“任何源”多播最好通过会合机制得到支持，其中成员接收源的数据包而不进行任何类型的全局广播（例如，MSDP广播源信息，PIM-DM[PIMDM]和DVMRP[DVMRP]广播初始数据包，以及MOSPF[MOSPF]广播会员信息）。PIM-SM[PIMSM]和CBT[CBT]使用一个共享组树，所有成员都加入到该树中，从而从所有源中听到消息（非成员不加入该树，因此从没有源中听到消息）。
This document describes BGMP, a protocol for inter-domain multicast routing. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP builds shared trees for active multicast groups, and allows domains to build source-specific, inter-domain, distribution branches where needed. Building upon concepts from PIM-SM and CBT, BGMP requires that each global multicast group be associated with a single root. However, in BGMP, the root is an entire exchange or domain, rather than a single router.
本文档描述了BGMP，一种用于域间多播路由的协议。BGMP本机支持“源特定多播”（SSM）。为了支持“任意源多播”（ASM），BGMP为活动多播组构建共享树，并允许域在需要时构建特定于源的域间分发分支。基于PIM-SM和CBT的概念，BGMP要求每个全局多播组与单个根相关联。但是，在BGMP中，根节点是整个交换或域，而不是单个路由器。
For non-source-specific groups, BGMP assumes that ranges of the multicast address space have been associated (e.g., with Unicast-Prefix-Based Multicast [V4PREFIX,V6PREFIX] addressing) with selected domains. Each such domain then becomes the root of the shared domain-trees for all groups in its range. An address allocator will generally achieve better distribution trees if it takes its multicast addresses from its own domain's part of the space, thereby causing the root domain to be local.
对于非源特定组，BGMP假设多播地址空间的范围已与选定域关联（例如，与基于单播前缀的多播[V4PREFIX，V6PREFIX]寻址）。然后，每个这样的域成为其范围内所有组的共享域树的根。如果地址分配器从其自己域的空间部分获取其多播地址，从而使根域成为本地的，则通常会获得更好的分发树。
BGMP uses TCP as its transport protocol. This eliminates the need to implement message fragmentation, retransmission, acknowledgement, and sequencing. BGMP uses TCP port 264 for establishing its connections. This port is distinct from BGP's port to provide protocol independence, and to facilitate distinguishing between protocol packets (e.g., by packet classifiers, diagnostic utilities, etc.)
BGMP使用TCP作为其传输协议。这样就不需要实现消息分段、重传、确认和排序。BGMP使用TCP端口264建立连接。该端口不同于BGP的端口，以提供协议独立性，并便于区分协议数据包（例如，通过数据包分类器、诊断实用程序等）
Two BGMP peers form a TCP connection between one another, and exchange messages to open and confirm the connection parameters. They then send incremental Join/Prune Updates as group memberships change. BGMP does not require periodic refresh of individual entries. KeepAlive messages are sent periodically to ensure the liveness of the connection. 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 if the error is a fatal one.
两个BGMP对等点在彼此之间形成TCP连接，并交换消息以打开和确认连接参数。然后，当组成员身份发生变化时，它们会发送增量加入/删除更新。BGMP不需要定期刷新单个条目。定期发送KeepAlive消息以确保连接的活跃性。通知消息是针对错误或特殊情况发送的。如果连接遇到错误情况，将发送通知消息，如果错误是致命的，则连接将关闭。
This document uses the following technical terms:
本文件使用以下技术术语：
Domain: A set of one or more contiguous links and zero or more routers surrounded by one or more multicast border routers. Note that this loose definition of domain also applies to an external link between two domains, as well as an exchange.
域：由一个或多个连续链路和由一个或多个多播边界路由器包围的零个或多个路由器组成的集合。请注意，域的这种松散定义也适用于两个域之间的外部链接以及交换。
Root Domain: When constructing a shared tree of domains for some group, one domain will be the "root" of the tree. The root domain receives data from each sender to the group, and functions as a rendezvous domain toward which member domains can send inter-domain joins, and to which sender domains can send data.
根域：当为某个组构建域的共享树时，一个域将是该树的“根”。根域从组的每个发送方接收数据，并充当会合域，成员域可以向其发送域间加入，发送方域可以向其发送数据。
Multicast RIB: The Routing Information Base, or routing table, used to calculate the "next-hop" towards a particular address for multicast traffic.
多播RIB：路由信息库或路由表，用于计算多播流量朝向特定地址的“下一跳”。
Multicast IGP (M-IGP): A generic term for any multicast routing protocol used for tree construction within a domain. Typical examples of M-IGPs are: PIM-SM, PIM-DM, DVMRP, MOSPF, and CBT.
多播IGP（M-IGP）：用于在域内构建树的任何多播路由协议的通用术语。M-IGP的典型示例有：PIM-SM、PIM-DM、DVMRP、MOSPF和CBT。
EGP: A generic term for the interdomain unicast routing protocol in use. Typically, this will be some version of BGP which can support a Multicast RIB, such as MBGP [MBGP], containing both unicast and multicast address prefixes.
EGP：目前使用的域间单播路由协议的通用术语。通常，这将是BGP的某个版本，它可以支持多播RIB，例如MBGP[MBGP]，包含单播和多播地址前缀。
Component: The portion of a border router associated with (and logically inside) a particular domain that runs the multicast IGP (M-IGP) for that domain, if any. Each border router thus has zero or more components inside routing domains. In addition, each border router with external links that do not fall inside any routing domain will have an inter-domain component that runs BGMP.
组件：边界路由器的一部分，与特定域相关（逻辑上在该域内），该域为该域运行多播IGP（M-IGP），如果有的话。因此，每个边界路由器在路由域内具有零个或多个组件。此外，每个具有不属于任何路由域的外部链接的边界路由器将具有运行BGMP的域间组件。
External peer: A border router in another multicast AS (autonomous system, as used in BGP), to which a BGMP TCP-connection is open. If BGP is being used as the EGP, a separate "eBGP" TCP-connection will also be open to the same peer.
外部对等点：另一个多播AS（自治系统，用于BGP）中的边界路由器，BGMP TCP连接已打开。如果将BGP用作EGP，则还将向同一对等方打开一个单独的“eBGP”TCP连接。
Internal peer: Another border router of the same multicast AS. If BGP is being used as the EGP, the border router either speaks iBGP ("internal" BGP) directly to internal peers in a full mesh, or indirectly through a route reflector [REFLECT].
内部对等：与多播相同的另一个边界路由器。如果BGP被用作EGP，则边界路由器要么直接向全网中的内部对等方说出iBGP（“内部”BGP），要么通过路由反射器间接说出[REFLECT]。
Next-hop peer: The next-hop peer towards a given IP address is the next EGP router on the path to the given address, according to multicast RIB routes in the EGP's routing table (e.g., in MBGP, routes whose Subsequent Address Family Identifier field indicates that the route is valid for multicast traffic).
下一跳对等点：根据EGP路由表中的多播RIB路由，指向给定IP地址的下一跳对等点是指向给定地址路径上的下一个EGP路由器（例如，在MBGP中，其后续地址族标识符字段指示路由对多播流量有效的路由）。
target: Either an EGP peer, or an M-IGP component.
目标：EGP对等机或M-IGP组件。
Tree State Table: This is a table of (S-prefix,G) and (*,G-prefix) entries that have been explicitly joined by a set of targets. Each entry has, in addition to the source and group addresses and masks, a list of targets that have explicitly requested data (on behalf of directly connected hosts or downstream routers). (S,G) entries also have an "SPT" bit.
树状态表：这是一个由一组目标显式连接的（S-prefix，G）和（*，G-prefix）项组成的表。除了源地址、组地址和掩码外，每个条目都有一个明确请求数据的目标列表（代表直接连接的主机或下游路由器）。（S，G）条目也有一个“SPT”位。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[RFC2119]中所述进行解释。
BGMP maintains group-prefix state in response to messages from BGMP peers and notifications from M-IGP components. Group-shared trees are rooted at the domain advertising the group prefix covering those groups. When a receiver joins a specific group address, the border router towards the root domain generates a group-specific Join message, which is then forwarded Border-Router-by-Border-Router towards the root domain (see Figure 1). BGMP Join and Prune messages are sent over TCP connections between BGMP peers, and BGMP protocol state is refreshed by KEEPALIVE messages periodically sent over TCP.
BGMP维护组前缀状态，以响应来自BGMP对等方的消息和来自M-IGP组件的通知。组共享树植根于发布组前缀的域，该前缀覆盖这些组。当一个接收者加入一个特定的组地址时，朝向根域的边界路由器生成一个特定于组的加入消息，然后由边界路由器向根域转发该消息（见图1）。BGMP加入和删减消息通过BGMP对等方之间的TCP连接发送，BGMP协议状态由通过TCP定期发送的保留消息刷新。
BGMP routers build group-specific bidirectional forwarding state as they process the BGMP Join messages. Bidirectional forwarding state means that packets received from any target are forwarded to all other targets in the target list without any RPF checks. No group-specific state or traffic exists in parts of the network where there are no members of that group.
BGMP路由器在处理BGMP加入消息时建立特定于组的双向转发状态。双向转发状态意味着从任何目标接收的数据包被转发到目标列表中的所有其他目标，而无需任何RPF检查。网络中没有组成员的部分不存在特定于组的状态或流量。
BGMP routers optionally build source-specific unidirectional forwarding state, only where needed, to be compatible with source-specific trees (SPTs) used by some M-IGPs (e.g., DVMRP, PIM-DM, or PIM-SM), or to construct trees for source-specific groups. A domain that uses an SPT-based M-IGP may need to inject multicast packets from external sources via different border routers (to be compatible with the M-IGP RPF checks) which thus act as "surrogates". For example, in the Transit_1 domain, data from Src_A arrives at BR12, but must be injected by BR11. A surrogate router may create a source-specific BGMP branch if no shared tree state exists. Note: stub domains with a single border router, such as Rcvr_Stub_7 in Figure 1, receive all multicast data packets through that router, to which all RPF checks point. Therefore, stub domains never build source-specific state.
BGMP路由器可选择仅在需要时构建源特定的单向转发状态，以与某些M-IGP（例如DVMRP、PIM-DM或PIM-SM）使用的源特定树（SPT）兼容，或为源特定组构建树。使用基于SPT的M-IGP的域可能需要通过不同的边界路由器（与M-IGP RPF检查兼容）从外部源注入多播数据包，从而充当“代理”。例如，在Transit_1域中，来自Src_A的数据到达BR12，但必须由BR11注入。如果不存在共享树状态，代理路由器可以创建源特定的BGMP分支。注意：带有单个边界路由器的存根域，如图1中的Rcvr_存根_7，通过该路由器接收所有多播数据包，所有RPF检查都指向该路由器。因此，存根域从不构建特定于源的状态。
Root_Domain
[BR91]--------------------------\
| |
[BR32] [BR41]
Transit_3 Transit_4
[BR31] [BR42] [BR43]
| | |
[BR22] [BR52] [BR53]
Transit_2 Transit_5
[BR21] [BR51]
| |
[BR12] [BR61]
Transit_1[BR11]----------[BR62]Stub_6
[BR13] (Src_A)
| (Rcvr_D)
-------------------
| |
[BR71] [BR81]
Rcvr_Stub_7 Src_only_Stub_8
(Rcvr_C) (Src_B)
Root_Domain
[BR91]--------------------------\
| |
[BR32] [BR41]
Transit_3 Transit_4
[BR31] [BR42] [BR43]
| | |
[BR22] [BR52] [BR53]
Transit_2 Transit_5
[BR21] [BR51]
| |
[BR12] [BR61]
Transit_1[BR11]----------[BR62]Stub_6
[BR13] (Src_A)
| (Rcvr_D)
-------------------
| |
[BR71] [BR81]
Rcvr_Stub_7 Src_only_Stub_8
(Rcvr_C) (Src_B)
Figure 1: Example inter-domain topology. [BRxy] represents a BGMP border router. Transit_X is a transit domain network. *_Stub_X is a stub domain network.
图1：域间拓扑示例。[BRxy]表示BGMP边界路由器。Transit_X是一个传输域网络*_Stub_X是一个存根域网络。
Data packets are forwarded based on a combination of BGMP and M-IGP rules. The router forwards to a set of targets according to a matching (S,G) BGMP tree state entry if it exists. If not found, the router checks for a matching (*,G) BGMP tree state entry. If neither is found, then the packet is sent natively to the next-hop EGP peer for G, according to the Multicast RIB (for example, in the case of a non-member sender such as Src_B in Figure 1). If a matching entry was found, the packet is forwarded to all other targets in the target
数据包根据BGMP和M-IGP规则的组合进行转发。路由器根据匹配的（S，G）BGMP树状态条目（如果存在）转发到一组目标。如果未找到，路由器将检查匹配的（*，G）BGMP树状态条目。如果两者均未找到，则根据多播RIB（例如，在图1中的非成员发送方（如Src_B））将数据包以本机方式发送到G的下一跳EGP对等方。如果找到匹配条目，则数据包将转发到目标中的所有其他目标
list. In this way BGMP trees forward data in a bidirectional manner. If a target is an M-IGP component then forwarding is subject to the rules of that M-IGP protocol.
列表通过这种方式，BGMP树以双向方式转发数据。如果目标是M-IGP组件，则转发受该M-IGP协议规则的约束。
Several other protocols, or protocol proposals, build shared trees within domains [PIMSM, CBT]. The design choices made for BGMP result from our focus on Inter-Domain multicast in particular. The design choices made by PIM-SM and CBT are better suited to the wide-area intra-domain case. There are three major differences between BGMP and other shared-tree protocols:
其他几个协议或协议提案在域内建立共享树[PIMSM，CBT]。BGMP的设计选择源于我们对域间多播的关注。PIM-SM和CBT所做的设计选择更适合广域域内情况。BGMP和其他共享树协议之间有三个主要区别：
(1) Unidirectional vs. Bidirectional trees
(1) 单向树与双向树
Bidirectional trees (using bidirectional forwarding state as described above) minimize third party dependence which is essential in the inter-domain context. For example, in Figure 1, stub domains 7 and 8 would like to exchange multicast packets without being dependent on the quality of connectivity of the root domain. However, unidirectional shared trees (i.e., those using RPF checks) have more aggressive loop prevention and share the same processing rules as source-specific entries which are inherently unidirectional.
双向树（使用如上所述的双向转发状态）最小化了域间上下文中必不可少的第三方依赖性。例如，在图1中，存根域7和8希望在不依赖根域的连接质量的情况下交换多播数据包。但是，单向共享树（即使用RPF检查的树）具有更积极的循环预防，并与源特定项共享相同的处理规则，这些源特定项本质上是单向的。
The lack of third party dependence concerns in the INTRA domain case reduces the incentive to employ bidirectional trees. BGMP supports bidirectional trees because it has to, and because it can without excessive cost.
在域内情况下，缺乏第三方依赖性问题降低了采用双向树的动机。BGMP支持双向树，因为它必须这样做，而且可以在不增加额外成本的情况下实现。
(2) Source-specific distribution trees/branches
(2) 特定于源的分布树/分支
In a departure from other shared tree protocols, source-specific BGMP state is built ONLY where (a) it is needed to pull the multicast traffic down to a BGMP router that has source-specific (S,G) state, and (b) that router is NOT already on the shared tree (i.e., has no (*,G) state), and (c) that router does not want to receive packets via encapsulation from a router which is on the shared tree. BGMP provides source-specific branches because most M-IGP protocols in use today build source-specific trees. BGMP's source-specific branches eliminate the unnecessary overhead of encapsulations for high data rate sources from the shared tree's ingress router to the surrogate injector (e.g., from BR12 to BR11 in Figure 1). Moreover, cases in which shared paths are significantly longer than SPT paths will also benefit.
与其他共享树协议不同，只在以下情况下构建源特定的BGMP状态：（a）需要将多播通信向下拉至具有源特定（S，G）状态的BGMP路由器，以及（b）路由器不在共享树上（即没有（*，G）状态）和（c）该路由器不希望通过封装从共享树上的路由器接收数据包。BGMP提供特定于源代码的分支，因为目前使用的大多数M-IGP协议都构建特定于源代码的树。BGMP的源特定分支消除了从共享树入口路由器到代理注入器（例如，图1中从BR12到BR11）的高速数据源封装的不必要开销。此外，共享路径明显长于SPT路径的情况也将受益。
However, except for source-specific group distribution trees, we do not build source-specific inter-domain trees in general because (a) inter-domain connectivity is generally less rich than intra-domain
然而，除了特定于源的组分布树之外，我们通常不构建特定于源的域间树，因为（a）域间连接通常不如域内连接丰富
connectivity, so shared distribution trees should have more acceptable path length and traffic concentration properties in the inter-domain context, than in the intra-domain case, and (b) by having the shared tree state always take precedence over source-specific tree state, we avoid ambiguities that can otherwise arise.
连接，因此共享分发树在域间上下文中应该比在域内上下文中具有更多可接受的路径长度和流量集中属性，并且（b）通过使共享树状态始终优先于特定于源的树状态，我们避免了可能出现的歧义。
In summary, BGMP trees are, in a sense, a hybrid between PIM-SM and CBT trees.
总之，从某种意义上说，BGMP树是PIM-SM和CBT树的杂交。
(3) Method of choosing root of group shared tree
(3) 组共享树根的选择方法
The choice of a group's shared-tree-root has implications for performance and policy. In the intra-domain case it is sometimes assumed that all potential shared-tree roots (RPs/Cores) within the domain are equally suited to be the root for a group that is initiated within that domain. In the INTER-domain case, there is far more opportunity for unacceptably poor locality, and administrative control of a group's shared-tree root. Therefore in the intra-domain case, other protocols sometimes treat all candidate roots (RPs or Cores) as equivalent and emphasize load sharing and stability to maximize performance. In the Inter-Domain case, all roots are not equivalent, and we adopt an approach whereby a group's root domain is not random but is subject to administrative control.
选择组的共享树根会影响性能和策略。在域内情况下，有时假设域内的所有潜在共享树根（RPs/核心）都同样适合作为在该域内发起的组的根。在域间的情况下，有更多的机会出现不可接受的局部性差和对组的共享树根的管理控制。因此，在域内情况下，其他协议有时将所有候选根（RPs或核心）视为等效的，并强调负载共享和稳定性，以最大限度地提高性能。在域间情况下，所有根都不相等，我们采用的方法是，组的根域不是随机的，而是受管理控制的。
In this section, we describe the detailed protocol that border routers perform. We assume that each border router conforms to the component-based model described in [INTEROP], modulo one correction to section 3.2 ("BGMP" Dispatcher), as follows:
在本节中，我们将描述边界路由器执行的详细协议。我们假设每个边界路由器都符合[INTEROP]中描述的基于组件的模型，按照第3.2节（“BGMP”Dispatcher）的一个修正进行模化，如下所示：
The iif owner of a (*,G) entry is the component owning the next-hop interface towards the nominal root of G, in the multicast RIB.
（*，G）项的iif所有者是拥有多播RIB中G的标称根的下一跳接口的组件。
The fundamental requirements imposed by BGMP are that:
BGMP的基本要求是：
(1) For a given source-specific group and source, BGMP must be able to look up the next-hop towards the source in the Multicast RIB, and
(1) 对于给定的特定于源的组和源，BGMP必须能够在多播RIB中查找指向源的下一跳，并且
(2) For a given non-source-specific group, BGMP will map the group address to a nominal "root" address, and must be able to look up the next-hop towards that address in the Multicast RIB.
(2) 对于给定的非源特定组，BGMP将把组地址映射到一个标称的“根”地址，并且必须能够在多播RIB中查找指向该地址的下一跳。
BGMP determines the nominal "root" address as follows. If the multicast address is a Unicast-Prefix-based Multicast address, then the nominal root address is the embedded unicast prefix, padded with a suffix of 0 bits to form a full address.
BGMP确定标称“根”地址，如下所示。如果多播地址是基于单播前缀的多播地址，则标称根地址是嵌入的单播前缀，用0位后缀填充以形成完整地址。
For example, if the IPv6 group address is ff2e:0100:1234:5678:9abc:def0::123, then the unicast prefix is 1234:5678:9abc:def0/64, and the nominal root address would be 1234:5678:9abc:def0::. (This address is in fact the subnet router anycast address [IPv6AA].)
例如，如果IPv6组地址为ff2e:0100:1234:5678:9abc:def0:：123，则单播前缀为1234:5678:9abc:def0/64，且标称根地址为1234:5678:9abc:def0:：。（该地址实际上是子网路由器选播地址[IPv6AA]。）
Support for any-source-multicast using any address other than a Unicast-prefix-based Multicast Address is outside the scope of this document.
对使用基于单播前缀的多播地址以外的任何地址的任何源多播的支持超出了本文档的范围。
For BGMP rules to be applied, an incoming packet must first be "accepted":
要应用BGMP规则，必须首先“接受”传入数据包：
o If the packet arrived on an interface owned by an M-IGP, the M-IGP component determines whether the packet should be accepted or dropped according to its rules. If the packet is accepted, the packet is forwarded (or not forwarded) out any other interfaces owned by the same component, as specified by the M-IGP.
o 如果数据包到达M-IGP拥有的接口上，M-IGP组件将根据其规则确定是接受还是丢弃数据包。如果数据包被接受，则根据M-IGP的规定，将数据包转发（或不转发）到同一组件拥有的任何其他接口。
o If the packet was received over a point-to-point interface owned by BGMP, the packet is accepted.
o 如果通过BGMP拥有的点对点接口接收数据包，则接受该数据包。
o If the packet arrived on a multiaccess network interface owned by BGMP, the packet is accepted if it is receiving data on a source-specific branch, if it is the designated forwarder for the longest matching route for S, or for the longest matching route for the nominal root of G.
o 如果数据包到达BGMP拥有的多址网络接口，则如果数据包在源特定分支上接收数据，如果数据包是S的最长匹配路由或G的标称根的最长匹配路由的指定转发器，则该数据包被接受。
If the packet is accepted, then the router checks the tree state table for a matching (S,G) entry. If one is found, but the packet was not received from the next hop target towards S (if the entry's SPT bit is True), or was not received from the next hop target towards G (if the entry's SPT bit is False) then the packet is dropped and no further actions are taken. If no (S,G) entry was found, the router then checks for a matching (*,G) entry.
如果数据包被接受，路由器将检查树状态表中是否有匹配的（S，G）条目。如果找到一个，但数据包没有从下一跳目标接收到朝向S（如果条目的SPT位为True），或者没有从下一跳目标接收到朝向G（如果条目的SPT位为False），则数据包被丢弃，并且不采取进一步的措施。如果没有找到（S，G）条目，路由器将检查匹配的（*，G）条目。
If neither is found, then the packet is forwarded towards the next-hop peer for the nominal root of G, according to the Multicast RIB. If a matching entry was found, the packet is forwarded to all other targets in the target list.
如果两者均未找到，则根据多播RIB，将数据包转发到G的标称根的下一跳对等方。如果找到匹配条目，则数据包将转发到目标列表中的所有其他目标。
Forwarding to a target which is an M-IGP component means that the packet is forwarded out any interfaces owned by that component according to that component's multicast forwarding rules.
转发到作为M-IGP组件的目标意味着根据该组件的多播转发规则将数据包转发出该组件拥有的任何接口。
When the BGMP component receives a (*,G) or (S,G) Join alert from another component, or a BGMP (S,G) or (*,G) Join message from an external peer, it searches the tree state table for a matching entry. If an entry is found, and that peer is already listed in the target list, then no further actions are taken.
当BGMP组件从另一个组件收到（*，G）或（S，G）连接警报，或从外部对等方收到BGMP（S，G）或（*，G）连接消息时，它会在树状态表中搜索匹配的条目。如果找到一个条目，并且该对等方已列在目标列表中，则不会采取进一步的操作。
Otherwise, if no (*,G) or (S,G) entry was found, one is created. In the case of a (*,G), the target list is initialized to contain the next-hop peer towards the nominal root of G, if it is an external peer. If the peer is internal, the target list is initialized to contain the M-IGP component owning the next-hop interface. If there is no next-hop peer (because the nominal root of G is inside the domain), then the target list is initialized to contain the next-hop component. If an (S,G) entry exists for the same G for which the (*,G) Join is being processed, and the next-hop peers toward S and the nominal root of G are different, the BGMP router must first send a (S,G) Prune message toward the source and clear the SPT bit on the (S,G) entry, before activating the (*,G) entry.
否则，如果未找到（*，G）或（S，G）条目，则创建一个条目。在a（*，G）的情况下，如果目标列表是外部对等点，则将其初始化为包含朝向G的标称根的下一跳对等点。如果对等方是内部的，则初始化目标列表以包含拥有下一跳接口的M-IGP组件。如果没有下一跳对等点（因为G的标称根在域内），则初始化目标列表以包含下一跳组件。如果正在处理（*，G）联接的同一个G存在（S，G）项，并且朝向S的下一跳对等点和G的标称根不同，则BGMP路由器必须首先向源发送（S，G）删减消息，并在激活（*，G）项之前清除（S，G）项上的SPT位。
When creating (S,G) state, if the source is internal to the BGMP speaker's domain, a "Poison-Reverse" bit (PR-bit) is set. This bit indicates that the router may receive packets matching (S,G) anyway due to the BGMP speaker being a member of a domain on the path between S and the root domain. (Depending on the M-IGP protocol, it may in fact receive such packets anyway only if it is the best exit for the nominal root of G.)
创建（S，G）状态时，如果源位于BGMP扬声器域内部，则设置“有毒反转”位（PR位）。此位表示由于BGMP扬声器是S和根域之间路径上的域的成员，路由器可能会接收到任何匹配（S，G）的数据包。（取决于M-IGP协议，事实上，仅当它是G的标称根的最佳出口时，它才可能接收此类数据包。）
The target from which the Join was received is then added to the target list. The router then looks up S or the nominal root of G in the Multicast RIB to find the next-hop EGP peer. If the target list, not including the next-hop target towards G for a (*,G) entry, becomes non-null as a result, the next-hop EGP peer must be notified as follows:
然后将接收加入的目标添加到目标列表中。路由器然后在多播RIB中查找S或G的标称根，以找到下一跳EGP对等点。如果目标列表（不包括（*，G）条目的下一跳目标）因此变为非空，则必须按如下方式通知下一跳EGP对等方：
a) If the next-hop peer towards the nominal root of G (for a (*,G) entry) is an external peer, a BGMP (*,G) Join message is unicast to the external peer. If the next-hop peer towards S (for an (S,G) entry) is an external peer, and the router does NOT have any active (*,G) state for that group address G, a BGMP (S,G) Join message is unicast to the external peer. A BGMP (S,G) Join
a) 如果朝向G的标称根的下一跳对等方（对于（*，G）条目）是外部对等方，则BGMP（*，G）连接消息单播到外部对等方。如果朝向S的下一跳对等方（对于（S，G）条目）是外部对等方，并且路由器对于该组地址G没有任何活动（*，G）状态，则BGMP（S，G）加入消息单播到外部对等方。BGMP（S，G）连接
message is never sent to an external peer by a router that also contains active (*,G) state for the same group. If the next-hop peer towards S (for an (S,G entry) is an external peer and the router DOES have active (*,G) state for that group G, the SPT bit is always set to False.
同样包含同一组的活动（*，G）状态的路由器从不将消息发送到外部对等方。如果朝向S的下一跳对等方（对于（S，G条目）是外部对等方，并且路由器确实具有该组G的活动（*，G）状态，则SPT位始终设置为False。
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Join alert is sent to the M-IGP component owning the next-hop interface.
b) 如果下一跳对等方是内部对等方，则（*，G）或（S，G）加入警报将发送给拥有下一跳接口的M-IGP组件。
c) If there is no next-hop peer, a (*,G) or (S,G) Join alert is sent to the M-IGP component owning the next-hop interface.
c) 如果没有下一跃点对等点，则会向拥有下一跃点接口的M-IGP组件发送（*，G）或（S，G）加入警报。
Finally, if an (S,G) Join is received from an internal peer, the peer should be stored with the M-IGP component target. If (S,G) state exists with the PR-bit set, and the next-hop towards the nominal root for G is through the M-IGP component, an (S,G) Poison-Reverse message is immediately sent to the internal peer.
最后，如果从内部对等方接收到（S，G）连接，则该对等方应与M-IGP组件目标一起存储。如果设置PR位时存在（S，G）状态，并且通过M-IGP组件到达G的标称根的下一个跃点，则会立即向内部对等方发送（S，G）中毒反向消息。
If an (S,G) Join is received from an external peer, and (S,G) state exists with the PR-bit set, and the local BGMP speaker is the best exit for the nominal root of G, and the next-hop towards the nominal root for G is through the interface towards the external peer, an (S,G) Poison-Reverse message is immediately sent to the external peer.
如果从外部对等方接收到（S，G）连接，并且（S，G）状态与PR位一起存在，并且本地BGMP扬声器是G的标称根的最佳出口，并且G的标称根的下一个跃点是通过指向外部对等方的接口，则会立即向外部对等方发送（S，G）有毒反向消息。
When the BGMP component receives a (*,G) or (S,G) Prune alert from another component, or a BGMP (*,G) or (S,G) Prune message from an external peer, it searches the tree state table for a matching entry. If no (S,G) entry was found for an (S,G) Prune, but (*,G) state exists, an (S,G) entry is created, with the target list copied from the (*,G) entry. If no matching entry exists, or if the component or peer is not listed in the target list, no further actions are taken.
当BGMP组件从另一个组件收到（*，G）或（S，G）修剪警报，或从外部对等方收到BGMP（*，G）或（S，G）修剪消息时，它会在树状态表中搜索匹配的条目。如果未找到（S，G）修剪的（S，G）项，但（*，G）状态存在，则会创建（S，G）项，并从（*，G）项复制目标列表。如果不存在匹配条目，或者如果目标列表中未列出组件或对等体，则不会采取进一步的操作。
Otherwise, the component or peer is removed from the target list. If the target list becomes null as a result, the next-hop peer towards the nominal root of G (for a (*,G) entry), or towards S (for an (S,G) entry if and only if the BGMP router does NOT have any corresponding (*,G) entry), must be notified as follows.
否则，将从目标列表中删除组件或对等对象。如果目标列表因此变为空，则必须按如下方式通知朝向G的标称根的下一跳对等方（对于（*，G）条目）或朝向S的下一跳对等方（对于（S，G）条目，当且仅当BGMP路由器没有任何对应的（*，G）条目时）。
a) If the peer is an external peer, a BGMP (*,G) or (S,G) Prune message is unicast to it.
a) 如果该对等方是外部对等方，则BGMP（*，G）或（S，G）Prune消息将单播到该对等方。
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Prune alert is sent to the M-IGP component owning the next-hop interface.
b) 如果下一跳对等方是内部对等方，则会向拥有下一跳接口的M-IGP组件发送（*，G）或（S，G）修剪警报。
c) If there is no next-hop peer, a (*,G) or (S,G) Prune alert is sent to the M-IGP component owning the next-hop interface.
c) 如果没有下一跳对等点，则会向拥有下一跳接口的M-IGP组件发送（*，G）或（S，G）修剪警报。
When a border router receives a route for a new prefix in the multicast RIB, or a existing route for a prefix is withdrawn, a route change notification for that prefix must be sent to the BGMP component. In addition, when the next hop peer (according to the multicast RIB) changes, a route change notification for that prefix must be sent to the BGMP component.
当边界路由器接收到多播RIB中新前缀的路由，或前缀的现有路由被撤回时，必须向BGMP组件发送该前缀的路由更改通知。此外，当下一跳对等点（根据多播RIB）更改时，必须向BGMP组件发送该前缀的路由更改通知。
In addition, in IPv4 (only), an internal route for each class-D prefix associated with the domain (if any) MUST be injected into the multicast RIB in the EGP by the domain's border routers.
此外，在IPv4（仅限IPv4）中，与域（如果有）关联的每个D类前缀的内部路由必须由域的边界路由器注入EGP中的多播RIB。
When a route for a new group prefix is learned, or an existing route for a group prefix is withdrawn, or the next-hop peer for a group prefix changes, a BGMP router updates all affected (*,G) target lists. The router sends a (*,G) Join to the new next-hop target, and a (*,G) Prune to the old next-hop target, as appropriate. In addition, if any (S,G) state exists with the PR-bit set:
当学习新组前缀的路由，或撤销组前缀的现有路由，或更改组前缀的下一跳对等方时，BGMP路由器将更新所有受影响的（*，G）目标列表。路由器向新的下一跳目标发送（*，G）连接，并根据需要向旧的下一跳目标发送（*，G）删减。此外，如果PR位设置存在任何（S，G）状态：
o If the BGMP speaker has just become the best exit for the nominal root of G, an (S,G) Poison Reverse message with the PR-bit set is sent as noted below.
o 如果BGMP扬声器刚刚成为G的标称根的最佳出口，则会发送一条PR位设置为的（S，G）有毒反向消息，如下所述。
o If the BGMP speaker was the best exit for the nominal root of G and is no longer, an (S,G) Poison Reverse message with the PR-bit clear is sent as noted below.
o 如果BGMP扬声器是G的标称根的最佳出口，并且不再是，则发送PR位为clear的（S，G）有毒反向消息，如下所述。
The (S,G) Poison-Reverse messages are sent to all external peers on the next-hop interface towards the nominal root of G from which (S,G) Joins have been received.
（S，G）有毒反向消息被发送到下一跳接口上的所有外部对等方，朝向已从中接收（S，G）连接的G的标称根。
When an existing route for a source prefix is withdrawn, or the next-hop peer for a source prefix changes, a BGMP router updates all affected (S,G) target lists. The router sends a (S,G) Join to the new next-hop target, and a (S,G) Prune to the old next-hop target, as appropriate.
当源前缀的现有路由被撤销，或源前缀的下一跳对等方发生更改时，BGMP路由器将更新所有受影响的（S，G）目标列表。路由器向新的下一跳目标发送（S，G）连接，并根据需要向旧的下一跳目标发送（S，G）删减。
When a BGMP speaker receives an (S,G) Poison-Reverse message from a peer, it sets the PR-bit on the (S,G) state to match the PR-bit in the message, and looks up the next-hop towards the nominal root of G. If the next-hop target is an M-IGP component, it forwards the (S,G) Poison Reverse message to all internal peers of that component from
当BGMP扬声器接收到来自对等方的（S，G）有毒反向消息时，它将（S，G）状态上的PR位设置为与消息中的PR位匹配，并向G的标称根查找下一跳。如果下一跳目标是M-IGP组件，它将（S，G）有毒反向消息转发给来自该组件的所有内部对等方
which it has received (S,G) Joins. If the next-hop target is an external peer on a given interface, it forwards the (S,G) Poison Reverse message to all external peers on that interface.
它已经收到（S，G）连接。如果下一个跃点目标是给定接口上的外部对等点，则它会将（S，G）有毒反向消息转发给该接口上的所有外部对等点。
When a BGMP speaker receives an (S,G) Poison-Reverse message from an external peer, with the PR-bit set, and the speaker has received no (S,G) Joins from any other peers (e.g., only from the M-IGP, or has (S,G) state due to encapsulation as described in 5.4.1), it knows that its own (S,G) Join is unnecessary, and should send an (S,G) Prune.
当BGMP扬声器接收到来自外部对等方的（S，G）有毒反向消息，且PR位已设置，且扬声器未收到来自任何其他对等方的（S，G）连接（例如，仅来自M-IGP，或由于5.4.1中所述的封装而具有（S，G）状态），它知道其自身的（S，G）连接是不必要的，并且应发送（S，G）删减。
When a BGMP speaker receives an (S,G) Poison-Reverse message from an internal peer, with the PR-bit set, and the speaker is the best exit for the nominal root of G, and has (S,G) prune state, an (S,G) Join message is sent to cancel the prune state and the state is deleted.
当BGMP说话者从内部对等方接收到（S，G）有害反向消息，且PR位已设置，且说话者是G的标称根的最佳出口，且具有（S，G）修剪状态时，将发送（S，G）加入消息以取消修剪状态，并删除该状态。
When an M-IGP component on a border router first learns that there are internally-reached members for a group G (whose scope is larger than that domain), a (*,G) Join alert is sent to the BGMP component. Similarly, when an M-IGP component on a border router learns that there are no longer internally-reached members for a group G (whose scope is larger than a single domain), a (*,G) Prune alert is sent to the BGMP component.
当边界路由器上的M-IGP组件首次得知G组（其范围大于该域）有内部到达的成员时，会向BGMP组件发送（*，G）加入警报。类似地，当边界路由器上的M-IGP组件得知G组（其范围大于单个域）不再有内部到达的成员时，会向BGMP组件发送（*，G）修剪警报。
At any time, any M-IGP domain MAY decide to join a source-specific branch for some external source S and group G. When the M-IGP component in the border router that is the next-hop router for a particular source S learns that a receiver wishes to receive data from S on a source-specific path, an (S,G) Join alert is sent to the BGMP component. When it is learned that such receivers no longer exist, an (S,G) Prune alert is sent to the BGMP component. Recall that the BGMP component will generate external source-specific Joins only where the source-specific branch does not coincide with the shared tree distribution tree for that group.
在任何时候，任何M-IGP域都可能决定加入某些外部源S和组G的源特定分支。当作为特定源S的下一跳路由器的边界路由器中的M-IGP组件得知接收器希望在源特定路径上从S接收数据时，会向BGMP组件发送（S，G）加入警报。当得知此类接收器不再存在时，将向BGMP组件发送（S，G）删减警报。回想一下，只有在源特定分支与该组的共享树分发树不一致的情况下，BGMP组件才会生成外部源特定联接。
Finally, we will require that the border router that is the next-hop internal peer for a particular address S or the nominal root of G be able to forward data for a matching tree state table entry to all members within the domain. This requirement has implications on specific M-IGPs as follows.
最后，我们将要求作为特定地址S或G的标称根的下一跳内部对等方的边界路由器能够将匹配树状态表条目的数据转发给域内的所有成员。该要求对特定M-IGP有如下影响。
DVMRP and PIM-DM are both "broadcast and prune" protocols in which every data packet must pass an RPF check against the packet's source address, or be dropped. If the border router receiving packets from an external source is the only BR to inject the route for the source into the domain, then there are no problems. For example, this will always be true for stub domains with a single border router (see Figure 1). Otherwise, the border router receiving packets externally is responsible for encapsulating the data to any other border routers that must inject the data into the domain for RPF checks to succeed.
DVMRP和PIM-DM都是“广播和删减”协议，其中每个数据包都必须通过针对数据包源地址的RPF检查，否则将被丢弃。如果从外部源接收数据包的边界路由器是将源的路由注入域的唯一BR，则没有问题。例如，对于具有单个边界路由器的存根域来说，这总是正确的（参见图1）。否则，外部接收数据包的边界路由器负责将数据封装到任何其他边界路由器，这些路由器必须将数据注入域中，以便RPF检查成功。
When an intended border router injector for a source receives encapsulated packets from another border router in its domain, it should create source-specific (S,G) BGMP state. Note that the border router may be configured to do this on a data-rate triggered basis so that the state is not created for very low data-rate/intermittent sources. If source-specific state is created, then its incoming interface points to the virtual encapsulation interface from the border router that forwarded the packet, and it has an SPT flag that is initialized to be False.
当源的预期边界路由器注入器从其域中的另一个边界路由器接收到封装的数据包时，它应该创建特定于源的（S，G）BGMP状态。请注意，边界路由器可配置为在数据速率触发的基础上执行此操作，以便不会为非常低的数据速率/间歇源创建状态。如果创建了特定于源的状态，则其传入接口指向转发数据包的边界路由器的虚拟封装接口，并且它具有一个初始化为False的SPT标志。
When the (S,G) BGMP state is created, the BGMP component will in turn send a BGMP (S,G) Join message to the next-hop external peer towards S if there is no (*,G) state for that same group, G. The (S,G) BGMP state will have the SPT bit set to False if (*,G) BGMP state is present.
创建（S，G）BGMP状态时，如果同一组G没有（*，G）状态，则BGMP组件将向下一跳外部对等方发送BGMP（S，G）加入消息。如果存在（*，G）BGMP状态，则（S，G）BGMP状态将SPT位设置为False。
When the first data packet from S arrives from the external peer and matches on the BGMP (S,G) state, and IF there is no (*,G) state, the router sets the SPT flag to True, resets the incoming interface to point to the external peer, and sends a BGMP (S,G) Prune message to the border router that was encapsulating the packets (e.g., in Figure 1, BR11 sends the (Src_A,G) Prune to BR12). When the border router with (*,G) state receives the prune for (S,G), it then deletes that border router from its list of targets.
当来自S的第一个数据包从外部对等方到达并与BGMP（S，G）状态匹配时，如果没有（*，G）状态，路由器将SPT标志设置为True，重置传入接口以指向外部对等方，并向封装数据包的边界路由器发送BGMP（S，G）删减消息（例如，在图1中，BR11将（Src_A，g）修剪发送给BR12）。当带（*，g）状态的边界路由器接收到（S，g）的修剪时，它将从其目标列表中删除该边界路由器。
If the decapsulator receives a (S,G) Poison Reverse message with the PR-bit set, it will forward it to the encapsulator (which may again forward it up the shared tree according to normal BGMP rules), and both will delete their BGMP (S,G) state.
如果解除封装器接收到设置了PR位的（S，G）毒物反向消息，则将其转发给封装器（根据正常BGMP规则，封装器可能再次将其转发到共享树上），并且两者都将删除其BGMP（S，G）状态。
PIM-DM and DVMRP present an additional problem, i.e., no protocol mechanism exists for joining and pruning entire groups; only joins and prunes for individual sources are available. As a result, BGMP does not currently support such protocols being used in a transit domain.
PIM-DM和DVMRP还存在另一个问题，即不存在加入和修剪整个组的协议机制；只有单个源的联接和修剪可用。因此，BGMP目前不支持传输域中使用的此类协议。
Protocols such as PIM-SM build unidirectional shared and source-specific trees. As with DVMRP and PIM-DM, every data packet must pass an RPF check against some group-specific or source-specific address.
PIM-SM等协议构建单向共享和特定于源的树。与DVMRP和PIM-DM一样，每个数据包都必须通过针对特定于组或特定于源的地址的RPF检查。
The fewest encapsulations/decapsulations will be done when the intra-domain tree is rooted at the next-hop internal peer (which becomes the RP) towards the nominal root of G, since in general that router will receive the most packets from external sources. To achieve this, each BGMP border router to a PIM-SM domain should send Candidate-RP-Advertisements within the domain for those groups for which it is the shared-domain tree ingress router. When the border router that is the RP for a group G receives an external data packet, it forwards the packet according to the M-IGP (i.e., PIM-SM) shared-tree outgoing interface list.
当域内树在朝向G的标称根的下一跳内部对等点（成为RP）扎根时，将进行最少的封装/解除封装，因为通常路由器将从外部源接收最多的数据包。为了实现这一点，每个到PIM-SM域的BGMP边界路由器应在域内为其为共享域树入口路由器的那些组发送候选RP广告。当作为G组的RP的边界路由器接收到外部数据分组时，它根据M-IGP（即，PIM-SM）共享树传出接口列表转发该分组。
Other border routers will receive data packets from external sources that are farther down the bidirectional tree of domains. When a border router that is not the RP receives an external packet for which it does not have a source-specific entry, the border router treats it like a local source by creating (S,G) state with a Register flag set, based on normal PIM-SM rules; the Border router then encapsulates the data packets in PIM-SM Registers and unicasts them to the RP for the group. As explained above, the RP for the inter-domain group will be one of the other border routers of the domain.
其他边界路由器将从域的双向树下更远的外部源接收数据包。当非RP的边界路由器接收到其没有源特定条目的外部分组时，边界路由器通过基于正常PIM-SM规则创建带有寄存器标志集的（S，G）状态，将其视为本地源；然后，边界路由器将数据包封装在PIM-SM寄存器中，并将其单播到该组的RP。如上所述，域间组的RP将是域的其他边界路由器之一。
If a source's data rate is high enough, DRs within the PIM-SM domain may switch to the shortest path tree. If the shortest path to an external source is via the group's ingress router for the shared tree, the new (S,G) state in the BGMP border router will not cause BGMP (S,G) Joins because that border router will already have (*,G) state. If however, the shortest path to an external source is via some other border router, that border router will create (S,G) BGMP state in response to the M-IGP (S,G) Join alert. In this case, because there is no local (*,G) state to suppress it, the border router will send a BGMP (S,G) Join to the next-hop external peer towards S, in order to pull the data down directly. (See BR11 in Figure 1). As in normal PIM-SM operation, those PIM-SM routers that have (*,G) and (S,G) state pointing to different incoming interfaces will prune that source off the shared tree. Therefore, all internal interfaces may be eventually pruned off the internal shared tree.
如果源的数据速率足够高，PIM-SM域中的DRs可能会切换到最短路径树。如果到外部源的最短路径是通过共享树的组入口路由器，则BGMP边界路由器中的新（s，G）状态将不会导致BGMP（s，G）加入，因为该边界路由器将已经具有（*，G）状态。但是，如果到外部源的最短路径是通过其他边界路由器，则该边界路由器将创建（S，G）BGMP状态以响应M-IGP（S，G）加入警报。在这种情况下，因为没有本地（*，G）状态来抑制它，边界路由器将向下一跳外部对等方发送一个BGMP（S，G）连接到S，以便直接向下拉数据。（参见图1中的BR11）。与正常的PIM-SM操作一样，那些具有（*，G）和（S，G）状态指向不同传入接口的PIM-SM路由器将从共享树中删除该源。因此，所有内部接口最终都可能从内部共享树中删除。
After the border router sends a BGMP (S,G) Join, if its (S,G) state has the PR-bit clear, a (S,G) Poison-Reverse message (with the PR-bit clear) is sent to the ingress router for G. The ingress router then creates (S,G) if it does not already exist, and removes the next hop towards the nominal root of G from the target list.
边界路由器发送BGMP（S，G）连接后，如果其（S，G）状态为PR位清除，则向G的入口路由器发送（S，G）有毒反向消息（PR位清除）。入口路由器然后创建（S，G）（如果它不存在），并从目标列表中移除朝向G的标称根的下一跳。
If the border router later receives an (S,G) Poison-Reverse message with the PR-bit set, the Poison-Reverse message is forwarded to the ingress router for G. The best-exit router then creates (S,G) state if it does not already exist, and puts the next hop towards the nominal root of G in the target list if not already present.
如果边界路由器随后接收到设置了PR位的（S，G）有毒反向消息，则有毒反向消息将转发到G的入口路由器。如果（S，G）状态不存在，则最佳出口路由器将创建（S，G）状态，如果尚未存在，则将下一跳置于目标列表中G的标称根。
CBT builds bidirectional shared trees but must address two points of compatibility with BGMP. First, CBT can not accommodate more than one border router injecting a packet. Therefore, if a CBT domain does have multiple external connections, the M-IGP components of the border routers are responsible for insuring that only one of them will inject data from any given source.
CBT构建双向共享树，但必须解决与BGMP的两个兼容性问题。首先，CBT不能容纳多个边界路由器注入一个数据包。因此，如果CBT域具有多个外部连接，则边界路由器的M-IGP组件负责确保其中只有一个将从任何给定源注入数据。
Second, CBT cannot process source-specific Joins or Prunes. Two options thus exist for each CBT domain:
其次，CBT无法处理特定于源的联接或删减。因此，每个CBT域有两个选项：
Option A: The CBT component interprets a (S,G) Join alert as if it were an (*,G) Join alert, as described in [INTEROP]. That is, if it is not already on the core-tree for G, then it sends a CBT (*,G) JOIN-REQUEST message towards the core for G. Similarly, when the CBT component receives an (S,G) Prune alert, and the child interface list for a group is NULL, then it sends a (*,G) QUIT_NOTIFICATION towards the core for G. This option has the disadvantage of pulling all data for the group G down to the CBT domain when no members exist.
选项A:CBT组件将（S，G）连接警报解释为（*，G）连接警报，如[INTEROP]中所述。也就是说，如果它不在G的核心树上，那么它将向G的核心发送CBT（*，G）JOIN-REQUEST消息。类似地，当CBT组件接收到（S，G）删减警报，并且组的子接口列表为空时，它将发送（*，G）向G的核心发出退出通知。此选项的缺点是，当不存在任何成员时，会将G组的所有数据向下拉至CBT域。
Option B: The CBT domain does not propagate any routes to their external peers for the Multicast RIB unless it is known that no other path exists to that prefix (e.g., routes for prefixes internal to the domain or in a singly-homed customer's domain may be propagated). This insures that source-specific joins are never received unless the source's data already passes through the domain on the shared tree, in which case the (S,G) Join need not be propagated anyway. BGMP border routers will only send source-specific Joins or Prunes to an external peer if that external peer advertises source-prefixes in the EGP. If a BGMP-CBT border router does receive an (S,G) Join or Prune, that border router should ignore the message.
选项B：CBT域不会将任何路由传播到多播RIB的外部对等方，除非知道该前缀不存在其他路径（例如，可以传播域内部或单独驻留的客户域中前缀的路由）。这可以确保永远不会收到源特定的联接，除非源的数据已经通过共享树上的域，在这种情况下，（s，G）联接无论如何都不需要传播。如果外部对等方在EGP中播发源前缀，BGMP边界路由器将只向外部对等方发送源特定的加入或删减。如果BGMP-CBT边界路由器确实收到（S，G）加入或删减，则该边界路由器应忽略该消息。
To minimize en/de-capsulations, CBTv2 BR's may follow the same scheme as described under PIM-SM above, in which Candidate-Core advertisements are sent for those groups for which it is the shared-tree ingress router.
为了最小化en/de封装，CBTv2 BR可遵循上述PIM-SM中所述的相同方案，其中为其为共享树入口路由器的那些组发送候选核心广告。
As with CBTv2, MOSPF cannot process source-specific Joins or Prunes, and the same two options are available. Therefore, an MOSPF domain may either:
与CBTv2一样，MOSPF无法处理特定于源的联接或修剪，并且有两个相同的选项可用。因此，MOSPF域可以是：
Option A: send a Group-Membership-LSA for all of G in response to a (S,G) Join alert, and "prematurely age" it out (when no other downstream members exist) in response to an (S,G) Prune alert, OR
选项A：发送所有G的组成员身份LSA以响应（S，G）加入警报，并“过早老化”它（当不存在其他下游成员时）以响应（S，G）删减警报，或
Option B: not propagate any routes to their external peers for the Multicast RIB unless it is known that no other path exists to that prefix (e.g., routes for prefixes internal to the domain or in a singly-homed customer's domain may be propagated)
选项B：不将任何路由传播到多播RIB的外部对等方，除非已知该前缀不存在其他路径（例如，可以传播域内部或单独驻留的客户域中前缀的路由）
Multiaccess links require special handling to prevent duplicates. The following mechanism enables BGMP to operate over multiaccess links which do not run an M-IGP. This avoids broadcast-and-prune behavior and does not require (S,G) state.
多址链路需要特殊处理以防止重复。以下机制使BGMP能够在不运行M-IGP的多址链路上运行。这避免了广播和修剪行为，并且不需要（S，G）状态。
To elect a designated forwarder per prefix, BGMP uses a FWDR_PREF message to exchange "forwarder preference" values for each prefix. The peer with the highest forwarder preference becomes the designated forwarder, with ties broken by lowest BGMP Identifier. The designated forwarder is the router responsible for forwarding packets up the tree, and is the peer to which joins will be sent.
为了根据前缀选择指定的转发器，BGMP使用FWDR_PREF消息为每个前缀交换“转发器首选项”值。具有最高转发器首选项的对等方成为指定的转发器，其联系被最低的BGMP标识符打破。指定的转发器是负责向树上转发数据包的路由器，是将向其发送加入的对等方。
When BGMP first learns that a route exists in the multicast RIB whose next-hop interface is NOT the multiaccess link, the BGMP router sends a BGMP FWDR_PREF message for the prefix, to all BGMP peers on the LAN. The FWDR_PREF message contains a "forwarder preference value" for the local router, and the same value MUST be sent to all peers on the LAN. Likewise, when the prefix is no longer reachable, a FWDR_PREF of 0 is sent to all peers on the LAN.
当BGMP第一次得知多播RIB中存在下一跳接口不是多址链路的路由时，BGMP路由器向LAN上的所有BGMP对等方发送前缀的BGMP FWDR_PREF消息。FWDR_PREF消息包含本地路由器的“转发器首选项值”，并且必须将相同的值发送到LAN上的所有对等方。同样，当前缀不再可访问时，将向LAN上的所有对等方发送0的FWDR_PREF。
Whenever a BGMP router calculates the next-hop peer towards a particular address, and that peer is reached over a BGMP-owned multiaccess LAN, the designated forwarder is used instead.
每当BGMP路由器计算到一个特定地址的下一跳对等点，并且通过BGMP拥有的多址LAN到达该对等点时，就会使用指定的转发器。
When a BGMP router receives a FWDR_PREF message from a peer, it looks up the matching route in its multicast RIB, and calculates the new designated forwarder. If the router has tree state entries whose parent target was the old forwarder, it sends Joins to the new forwarder and Prunes to the old forwarder.
当BGMP路由器收到来自对等方的FWDR_PREF消息时，它会在其多播RIB中查找匹配的路由，并计算新指定的转发器。如果路由器具有其父目标为旧转发器的树状态条目，则它将联接发送到新转发器，并将修剪发送到旧转发器。
When a BGMP router which is NOT the designated forwarder receives a packet on the multiaccess link, it is silently dropped.
当不是指定转发器的BGMP路由器在多址链路上接收到数据包时，该数据包将被静默丢弃。
Finally, this mechanism prevents duplicates where full peering exists on a "logical" link. Where full peering does not exist, steps must be taken (outside of BGMP) to present separate logical interfaces to BGMP, each of which is a link with full peering. This might entail, for example, using different link-layer address mappings, doing encapsulation, or changing the physical media.
最后，这种机制防止在“逻辑”链接上存在完全对等的情况下发生重复。如果不存在完全对等，则必须采取步骤（在BGMP之外）向BGMP提供单独的逻辑接口，每个逻辑接口都是具有完全对等的链路。例如，这可能需要使用不同的链路层地址映射、进行封装或更改物理介质。
As discussed earlier, routers with (*,G) state will not propagate (S,G) joins. However, a special case occurs when (S,G) state coincides with the G-route (or route towards the nominal root of G). When this occurs, care must be taken so that the data will reach the root domain without causing duplicates or black holes. For this reason, (S,G) state on the path between the source and the root domain is annotated as being "poison-reversed". A PR-bit is kept for this purpose, which is updated by (UN)POISON_REVERSE messages.
如前所述，状态为（*，G）的路由器不会传播（S，G）连接。然而，当（S，G）状态与G路径（或朝向G的标称根的路径）重合时，会出现一种特殊情况。发生这种情况时，必须小心，以便数据能够到达根域，而不会造成重复或黑洞。因此，源域和根域之间路径上的（S，G）状态被注释为“反向”。为此保留一个PR位，该位由（UN）POINTION_REVERSE消息更新。
The PR-bit indicates to BGMP nodes whether they need to forward packets up towards the root domain. For example, in a case where an (S,G) branch exists, a transit domain may get packets along the (S,G) branch, and needs to know whether to (also) forward them up towards the root domain. If the domain in question is on the path between S and the root domain, then the answer is yes (and the PR bit will be set on the S,G state). If the domain in question is not on the path between S and the root domain, then the answer is no (and the PR bit will be clear on the S,G state).
PR位向BGMP节点指示它们是否需要将数据包向上转发到根域。例如，在存在（S，G）分支的情况下，传输域可以沿着（S，G）分支获取数据包，并且需要知道是否（也）将它们转发到根域。如果所讨论的域位于S和根域之间的路径上，则答案为是（并且PR位将设置为S，G状态）。如果所讨论的域不在S和根域之间的路径上，则答案为否（并且在S，G状态下PR位将清除）。
This section describes message formats used by BGMP.
本节介绍BGMP使用的消息格式。
Messages are sent over a reliable transport protocol connection. 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.
消息通过可靠的传输协议连接发送。消息只有在完全接收后才被处理。最大消息大小为4096个八位字节。所有实现都需要支持此最大消息大小。
All fields labelled "Reserved" below must be transmitted as 0, and ignored upon receipt.
下面标记为“保留”的所有字段必须作为0传输，并在收到时忽略。
Each message has a fixed-size (4-byte) 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:
每条消息都有一个固定大小（4字节）的头。根据消息类型，报头后面可能有数据部分，也可能没有数据部分。这些字段的布局如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets. Thus, e.g., it allows one to locate in the transport-level stream the start of the next message. The value of the Length field must always be at least 4 and no greater than 4096, and may be further constrained, depending on the message type. No "padding" of extra data after the message is allowed, so the Length field must have the smallest value required given the rest of the message.
长度：这个2-octet无符号整数表示消息的总长度，包括消息头，以八位字节为单位。因此，例如，它允许在传输级流中定位下一消息的开始。长度字段的值必须始终至少为4且不大于4096，并且可以根据消息类型进行进一步约束。不允许在消息之后“填充”额外数据，因此长度字段必须具有给定消息其余部分所需的最小值。
Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined:
类型：此1-octet无符号整数表示消息的类型代码。定义了以下类型代码：
1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
1-打开2-更新3-通知4-保留
After a transport protocol 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. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.
建立传输协议连接后，各方发送的第一条消息是开放消息。如果打开的消息是可接受的，则返回确认打开的KEEPALIVE消息。确认打开后，可以交换更新、保留和通知消息。
In addition to the fixed-size BGMP header, the OPEN message contains the following fields:
除了固定大小的BGMP标头外，打开消息还包含以下字段：
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 | Rsvd| AddrFam | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGMP Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsvd| AddrFam | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGMP Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: This 1-octet unsigned integer indicates the protocol version number of the message. The current BGMP version number is 1.
版本：此1-octet无符号整数表示消息的协议版本号。当前BGMP版本号为1。
AddrFam: The IANA-assigned address family number of the BGMP Identifier. These include (among others):
AddrFam:BGMP标识符的IANA分配地址系列号。这些措施包括（除其他外）：
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)
Hold Time: This 2-octet unsigned integer indicates the number of seconds that the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, a BGMP 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 by the sender.
保持时间：这个2-octet无符号整数表示发送方为保持计时器的值建议的秒数。收到打开消息后，BGMP扬声器必须使用其配置的保持时间和打开消息中接收到的保持时间中的较小者来计算保持计时器的值。保持时间必须为零或至少三秒。实现可以基于保持时间拒绝连接。计算出的值表示发件人在收到连续的KEEPALIVE和/或UPDATE消息之间可能经过的最大秒数。
BGMP Identifier: This 4-octet (for IPv4) or 16-octet (IPv6) unsigned integer indicates the BGMP Identifier of the sender. A given BGMP speaker sets the value of its BGMP Identifier to a globally-unique value assigned to that BGMP speaker (e.g., an IPv4 address). The value of the BGMP Identifier is determined on startup and is the same for every BGMP session opened.
BGMP标识符：此4个八位字节（对于IPv4）或16个八位字节（IPv6）的无符号整数表示发送方的BGMP标识符。给定的BGMP扬声器将其BGMP标识符的值设置为分配给该BGMP扬声器的全局唯一值（例如，IPv4地址）。BGMP标识符的值在启动时确定，并且对于打开的每个BGMP会话都相同。
Optional Parameters: This field may contain a list of optional parameters, where each parameter is encoded as a <Parameter Length, Parameter Type, Parameter Value> triplet. The combined length of all optional parameters can be derived from the Length field in the message header.
可选参数：此字段可能包含可选参数列表，其中每个参数都编码为<parameter Length，parameter Type，parameter Value>三元组。所有可选参数的组合长度可以从消息头中的长度字段中导出。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Parameter Type is a one octet field that unambiguously identifies individual parameters. Parameter Length is a one octet field that contains the length of the Parameter Value field in octets. Parameter Value is a variable length field that is interpreted according to the value of the Parameter Type field.
参数类型是一个八位字节字段，可以明确标识各个参数。参数长度是一个八位字节字段，包含参数值字段的八位字节长度。参数值是根据参数类型字段的值解释的可变长度字段。
This document defines the following Optional Parameters:
本文档定义了以下可选参数：
a) Authentication Information (Parameter Type 1): This optional parameter may be used to authenticate a BGMP peer. The Parameter Value field contains a 1-octet Authentication Code followed by a variable length Authentication Data.
a) 身份验证信息（参数类型1）：此可选参数可用于对BGMP对等方进行身份验证。参数值字段包含一个1-octet身份验证代码，后跟一个可变长度的身份验证数据。
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code:
身份验证代码：
This 1-octet unsigned integer indicates the authentication mechanism being used. Whenever an authentication mechanism is specified for use within BGMP, three things must be included in the specification:
此1-octet无符号整数表示正在使用的身份验证机制。每当在BGMP中指定使用身份验证机制时，规范中必须包括三项内容：
- the value of the Authentication Code which indicates use of the mechanism, and - the form and meaning of the Authentication Data.
- 表示使用该机制的身份验证代码的值，以及-身份验证数据的形式和含义。
Note that a separate authentication mechanism may be used in establishing the transport level connection.
注意，在建立传输级连接时可以使用单独的认证机制。
Authentication Data:
身份验证数据：
The form and meaning of this field is a variable-length field depend on the Authentication Code.
此字段的形式和含义是一个可变长度字段，取决于身份验证代码。
The minimum length of the OPEN message is 12 octets (including message header).
打开消息的最小长度为12个八位字节（包括消息头）。
b) Capability Information (Parameter Type 2): This is an Optional Parameter that is used by a BGMP-speaker to convey to its peer the list of capabilities supported by the speaker. The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below:
b) 能力信息（参数类型2）：这是一个可选参数，BGMP演讲者使用该参数向其对等方传达演讲者支持的能力列表。该参数包含一个或多个三元组<Capability Code，Capability Length，Capability Value>，其中每个三元组的编码如下所示：
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
Capability Code:
能力代码：
Capability Code is a one octet field that unambiguously identifies individual capabilities.
能力代码是一个八位字段，明确标识单个能力。
Capability Length:
能力长度：
Capability Length is a one octet field that contains the length of the Capability Value field in octets.
Capability Length是一个八位字节字段，包含以八位字节为单位的Capability Value字段的长度。
Capability Value:
能力价值：
Capability Value is a variable length field that is interpreted according to the value of the Capability Code field.
能力值是根据能力代码字段的值解释的可变长度字段。
A particular capability, as identified by its Capability Code, may occur more than once within the Optional Parameter.
由能力代码标识的特定能力可能在可选参数中出现多次。
This document reserves Capability Codes 128-255 for vendor-specific applications.
本文件保留供应商特定应用的能力代码128-255。
This document reserves value 0.
此文档保留值0。
Capability Codes (other than those reserved for vendor specific use) are assigned only by the IETF consensus process and IESG approval.
能力代码（为供应商特定用途保留的代码除外）仅由IETF共识流程和IESG批准分配。
UPDATE messages are used to transfer Join/Prune/FwdrPref information between BGMP peers. The UPDATE message always includes the fixed-size BGMP header, and one or more attributes as described below.
更新消息用于在BGMP对等方之间传输加入/删除/FwdrPref信息。更新消息始终包括固定大小的BGMP标头和一个或多个属性，如下所述。
The message format below allows compact encoding of (*,G) Joins and Prunes, while allowing the flexibility needed to do other updates such as (S,G) Joins and Prunes towards sources as well as on the shared tree. In the discussion below, an Encoded-Address-Prefix is of the form:
下面的消息格式允许对（*，G）连接和修剪进行压缩编码，同时允许对源和共享树进行（S，G）连接和修剪等其他更新所需的灵活性。在下面的讨论中，编码地址前缀的形式如下：
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
+-+-+-+-+-+-+-+-+
|EnTyp| AddrFam |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+
|EnTyp| AddrFam |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EnTyp: 0 - All 1's Mask. The Mask field is 0 bytes long. 1 - Mask length included. The Mask field is 4 bytes long, and contains the mask length, in bits. 2 - Full Mask included. The Mask field is the same length as the Address field, and contains the full bitmask.
EnTyp:0-所有1的掩码。掩码字段的长度为0字节。1-包括遮罩长度。掩码字段的长度为4字节，包含掩码长度（以位为单位）。2-包括完整的面具。掩码字段的长度与地址字段的长度相同，并且包含完整的位掩码。
AddrFam: The IANA-assigned address family number of the encoded prefix.
AddrFam：编码前缀的IANA分配地址系列号。
Address: The address associated with the given prefix to be encoded. The length is determined based on the Address Family.
地址：与要编码的给定前缀关联的地址。长度根据地址族确定。
Mask: The mask associated with the given prefix. The format (or absence) of this field is determined by the EnTyp field.
掩码：与给定前缀关联的掩码。此字段的格式（或不存在）由EnTyp字段确定。
Each attribute is of the form:
每个属性的形式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All attributes are 4-byte aligned.
所有属性都是4字节对齐的。
Length: The Length is the length of the entire attribute, including the length, type, and data fields. If other attributes are nested within the data field, the length includes the size of all such nested attributes.
长度：长度是整个属性的长度，包括长度、类型和数据字段。如果其他属性嵌套在数据字段中，则长度包括所有此类嵌套属性的大小。
Type:
类型：
Types 128-255 are reserved for "optional" attributes. If a required attribute is unrecognized, a NOTIFICATION will be sent and the connection will be closed if the error is a fatal one. Unrecognized optional attributes are simply ignored.
128-255类型保留用于“可选”属性。如果无法识别所需的属性，则会发送通知，如果错误是致命错误，则会关闭连接。无法识别的可选属性将被忽略。
0 - JOIN 1 - PRUNE 2 - GROUP 3 - SOURCE 4 - FWDR_PREF 5 - POISON_REVERSE
0-加入1-修剪2-组3-源4-FWDR_PREF 5-毒药_反转
a) JOIN (Type Code 0)
a) 联接（类型代码0）
The JOIN attribute indicates that all GROUP or SOURCE options nested immediately within the JOIN option should be joined.
“联接”属性表示应联接紧嵌套在联接选项中的所有组或源选项。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a JOIN attribute.
连接属性中不能立即嵌套任何连接、修剪或FWDR_PREF属性。
b) PRUNE (Type Code 1)
b) 修剪（类型代码1）
The PRUNE attribute indicates that all GROUP or SOURCE attributes nested immediately within the PRUNE attribute should be pruned.
PRUNE属性表示应修剪直接嵌套在PRUNE属性中的所有组或源属性。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a PRUNE attribute.
不能立即将联接、修剪或FWDR_PREF属性嵌套在修剪属性中。
c) GROUP (Type Code 2)
c) 组（类型代码2）
The GROUP attribute identifies a given group-prefix. In addition, any attributes nested immediately within the GROUP attribute also apply to the given group-prefix.
GROUP属性标识给定的组前缀。此外，直接嵌套在组属性中的任何属性也适用于给定的组前缀。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoded-Address-Prefix The multicast group prefix to be joined to pruned, in the format described above. Nested Attributes No GROUP, SOURCE, or FWDR_PREF attributes may be immediately nested within a GROUP attribute.
编码地址前缀要加入到修剪的多播组前缀，格式如上所述。嵌套属性组、源或FWDR_PREF属性不能立即嵌套在组属性中。
d) SOURCE (Type Code 3):
d) 来源（类型代码3）：
The SOURCE attribute identifies a given source-prefix. In addition, any attributes nested immediately within the SOURCE attribute also apply to the given source-prefix.
SOURCE属性标识给定的源前缀。此外，直接嵌套在源属性中的任何属性也适用于给定的源前缀。
The SOURCE attribute has the following format:
源属性具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoded-Address-Prefix The Source-prefix in the format described above. Nested Attributes No GROUP, SOURCE, or FWDR_PREF attributes may be immediately nested within a SOURCE attribute.
编码地址前缀采用上述格式的源前缀。嵌套属性源属性中不能立即嵌套任何组、源或FWDR_PREF属性。
e) FWDR_PREF (Type Code 4)
e) FWDR_PREF（类型代码4）
The FWDR_PREF attribute provides a forwarder preference value for all GROUP or SOURCE attributes nested immediately within the FWDR_PREF attribute. It is used by a BGMP speaker to inform other BGMP speakers of the originating speaker's degree of preference for a given group or source prefix. Usage of this attribute is described in 5.5.
FWDR_PREF属性为直接嵌套在FWDR_PREF属性中的所有组或源属性提供转发器首选项值。BGMP说话人使用它通知其他BGMP说话人发话人对给定组或源前缀的偏好程度。5.5中描述了此属性的用法。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preference Value A 32-bit non-negative integer. Nested Attributes No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a FWDR_PREF attribute.
首选项值为32位非负整数。嵌套属性不能立即将联接、修剪或FWDR_PREF属性嵌套在FWDR_PREF属性中。
e) POISON_REVERSE (Type Code 5)
e) 反向（类型代码5）
The POISON_REVERSE attribute provides a "poison-reverse" (PR-bit) value for all SOURCE attributes nested immediately within the POISON_REVERSE attribute. It is used by a BGMP speaker to inform
POISON_REVERSE属性为直接嵌套在POISON_REVERSE属性中的所有源属性提供“POISON REVERSE”（PR位）值。BGMP扬声器使用它来通知
other BGMP speakers from which it has received (S,G) Joins that they are on the path of domains between the source and the root domain.
它从中接收（S，G）连接的其他BGMP扬声器表示它们位于源域和根域之间的域路径上。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P The PR-bit value. Nested Attributes No attributes in the document other than SOURCE may be immediately nested within a POISON_REVERSE attribute.
P PR位值。嵌套属性除源属性外，文档中的任何属性都不能立即嵌套在反向属性中。
Below are enumerated examples of how various updates are built using nested attributes, where A ( B ) denotes that attribute B is nested within attribute A.
下面列举了如何使用嵌套属性构建各种更新的示例，其中A（B）表示属性B嵌套在属性A中。
(*,G-prefix) Join: JOIN ( GROUP )
(*,G-prefix) Prune: PRUNE ( GROUP )
(S,G) Join towards S : GROUP ( JOIN ( SOURCE ) )
(S,G) Join cancelling prune towards root of G: GROUP ( JOIN ( SOURCE ) )
(S,G) Prune towards S: GROUP ( PRUNE ( SOURCE ) )
(S,G) Prune towards root of G: GROUP ( PRUNE ( SOURCE ) )
Switch from (*,G) to (S,G): PRUNE ( GROUP ( JOIN ( SOURCE ) ) )
Switch from (S,G) to (*,G): JOIN ( GROUP )
Initial (*,G) Join with S pruned: JOIN ( GROUP ( PRUNE ( SOURCE ) ) )
Forwarder preference announcement for G-prefix: FWDR_PREF ( GROUP )
Forwarder preference announcement for S-prefix: FWDR_PREF ( SOURCE )
(*,G-prefix) Join: JOIN ( GROUP )
(*,G-prefix) Prune: PRUNE ( GROUP )
(S,G) Join towards S : GROUP ( JOIN ( SOURCE ) )
(S,G) Join cancelling prune towards root of G: GROUP ( JOIN ( SOURCE ) )
(S,G) Prune towards S: GROUP ( PRUNE ( SOURCE ) )
(S,G) Prune towards root of G: GROUP ( PRUNE ( SOURCE ) )
Switch from (*,G) to (S,G): PRUNE ( GROUP ( JOIN ( SOURCE ) ) )
Switch from (S,G) to (*,G): JOIN ( GROUP )
Initial (*,G) Join with S pruned: JOIN ( GROUP ( PRUNE ( SOURCE ) ) )
Forwarder preference announcement for G-prefix: FWDR_PREF ( GROUP )
Forwarder preference announcement for S-prefix: FWDR_PREF ( SOURCE )
BGMP does not use any transport protocol-based keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between the last KEEPALIVE or UPDATE message sent, and the time at which a KEEPALIVE message is sent, 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.
BGMP不使用任何基于传输协议的保持活动机制来确定对等点是否可访问。相反，在对等方之间交换KEEPALIVE消息的频率足够高，不会导致保持计时器过期。从上次发送的KEEPALIVE或UPDATE消息到发送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 a message header, and has a length of 4 octets.
KEEPALIVE消息仅由消息头组成，长度为4个八位字节。
A NOTIFICATION message is sent when an error condition is detected. The BGMP connection is closed immediately after sending it if the error is a fatal one.
当检测到错误情况时，将发送通知消息。如果错误是致命的，则BGMP连接在发送后立即关闭。
In addition to the fixed-size BGMP header, the NOTIFICATION message contains the following fields:
除了固定大小的BGMP标头外，通知消息还包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O-bit: Open-bit. If clear, the connection will be closed. If set, indicates the error is not fatal.
O形钻头：开式钻头。如果清除，将关闭连接。如果设置，则表示错误不是致命的。
Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined:
错误代码：此1-octet无符号整数表示通知的类型。已定义以下错误代码：
Error Code Symbolic Name Reference
错误代码符号名称引用
1 Message Header Error Section 9.1
1消息头错误第9.1节
2 OPEN Message Error Section 9.2
2打开消息错误第9.2节
3 UPDATE Message Error Section 9.3
3更新消息错误第9.3节
4 Hold Timer Expired Section 9.5
4第9.5节中的保持计时器过期
5 Finite State Machine Error Section 9.6
5有限状态机错误第9.6节
6 Cease Section 9.7
6.第9.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. The notation (MC) below indicates the error is a fatal one and the O-bit must be clear. Non-fatal subcodes SHOULD be sent with the O-bit set.
错误子代码：此1-octet无符号整数提供有关报告错误性质的更具体信息。每个错误代码可能有一个或多个与之关联的错误子代码。如果未定义适当的错误子代码，则错误子代码字段将使用零（非特定）值。下面的符号（MC）表示错误是致命错误，O位必须清除。非致命子代码应与O位集一起发送。
Message Header Error subcodes:
消息头错误子代码：
2 - Bad Message Length (MC) 3 - Bad Message Type (MC)
2-错误消息长度（MC）3-错误消息类型（MC）
OPEN Message Error subcodes:
打开消息错误子代码：
1 - Unsupported Version (MC) 4 - Unsupported Optional Parameter 5 - Authentication Failure (MC) 6 - Unacceptable Hold Time (MC) 7 - Unsupported Capability (MC)
1-不支持的版本（MC）4-不支持的可选参数5-身份验证失败（MC）6-不可接受的保持时间（MC）7-不支持的功能（MC）
UPDATE Message Error subcodes:
更新消息错误子代码：
1 - Malformed Attribute List (MC) 2 - Unrecognized Attribute Type 5 - Attribute Length Error (MC) 10 - Invalid Address 11 - Invalid Mask 13 - Unrecognized Address Family 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 7 below for more details.
1-格式不正确的属性列表（MC）2-无法识别的属性类型5-属性长度错误（MC）10-无效地址11-无效掩码13-无法识别的地址族数据：此可变长度字段用于诊断通知的原因。数据字段的内容取决于错误代码和错误子代码。详见下文第7节。
Note that the length of the Data field can be determined from the message Length field by the formula:
请注意，数据字段的长度可以通过以下公式从消息长度字段中确定：
Message Length = 6 + Data Length
消息长度=6+数据长度
The minimum length of the NOTIFICATION message is 6 octets (including message header).
通知消息的最小长度为6个八位字节（包括消息头）。
This section describes actions to be taken when errors are detected while processing BGMP messages. BGMP Error Handling is similar to that of BGP [BGP].
本节描述在处理BGMP消息时检测到错误时要采取的操作。BGMP错误处理与BGP[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 BGMP connection is closed if the error is a fatal one. If no Error Subcode is specified, then a zero must be used.
当检测到此处描述的任何情况时，将发送带有指示错误代码、错误子代码和数据字段的通知消息，如果错误是致命错误，则关闭BGMP连接。如果未指定错误子代码，则必须使用零。
The phrase "the BGMP connection is closed" means that the transport protocol connection has been closed and that all resources for that BGMP connection have been deallocated. The remote peer is removed from the target list of all tree state entries.
短语“BGMP连接已关闭”表示传输协议连接已关闭，且该BGMP连接的所有资源已被释放。远程对等方将从所有树状态项的目标列表中删除。
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 are indicated by sending the NOTIFICATION message with Error Code Message Header Error. The Error Subcode elaborates on the specific nature of the error.
处理消息头时检测到的所有错误都通过发送带有错误代码消息头错误的通知消息来指示。错误子代码详细说明了错误的具体性质。
If the Length field of the message header is less than 4 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 4, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field.
如果消息头的长度字段小于4或大于4096，或者如果打开消息的长度字段小于打开消息的最小长度，或者如果更新消息的长度字段小于更新消息的最小长度，或者如果保留消息的长度字段不等于4，然后将错误子代码设置为错误消息长度。数据字段包含错误的长度字段。
If the Type field of the message header is not recognized, then the Error Subcode is set to Bad Message Type. The Data field contains the erroneous Type field.
如果无法识别消息头的类型字段，则错误子代码将设置为错误消息类型。数据字段包含错误的类型字段。
All errors detected while processing the OPEN message are indicated by sending the NOTIFICATION message with Error Code OPEN Message Error. The Error Subcode elaborates on the specific nature of the error.
处理打开的消息时检测到的所有错误都通过发送带有错误代码的通知消息来指示。错误子代码详细说明了错误的具体性质。
If the version number contained in the Version field of the received OPEN message is not supported, then the Error Subcode is 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 BGMP peer bid (as indicated in the received OPEN message).
如果接收到的打开消息的版本字段中包含的版本号不受支持，则错误子代码将设置为不受支持的版本号。数据字段是一个2-octet无符号整数，表示本地支持的最大版本号小于远程BGMP对等bid的版本号（如收到的打开消息中所示）。
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 which accepts a Hold Time MUST use the negotiated value for the Hold Time.
如果打开消息的保持时间字段不可接受，则必须将错误子代码设置为不可接受的保持时间。实现必须拒绝一秒或两秒的保持时间值。实施可以拒绝任何提议的保持时间。接受保留时间的实现必须使用保留时间的协商值。
If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode is set to Unsupported Optional Parameters.
如果无法识别打开消息中的一个可选参数，则错误子代码将设置为不受支持的可选参数。
If the OPEN message carries Authentication Information (as an Optional Parameter), then the corresponding authentication procedure is invoked. If the authentication procedure (based on Authentication Code and Authentication Data) fails, then the Error Subcode is set to Authentication Failure.
如果OPEN消息包含身份验证信息（作为可选参数），则调用相应的身份验证过程。如果身份验证过程（基于身份验证代码和身份验证数据）失败，则错误子代码设置为“身份验证失败”。
If the OPEN message indicates that the peer does not support a capability which the receiver requires, the receiver may send a NOTIFICATION message to the peer, and terminate peering. The Error Subcode in the message is set to Unsupported Capability. The Data field in the NOTIFICATION message lists the set of capabilities that cause the speaker to send the message. Each such capability is encoded the same way as it was encoded in the received OPEN message.
如果开放消息指示对等方不支持接收方所需的功能，则接收方可向对等方发送通知消息，并终止对等。消息中的错误子代码设置为不支持的功能。通知消息中的数据字段列出了导致扬声器发送消息的一组功能。每一个这样的功能都以与接收到的开放消息相同的方式编码。
All errors detected while processing the UPDATE message are indicated by sending the NOTIFICATION message with Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error.
处理更新消息时检测到的所有错误都通过发送带有错误代码的通知消息UPDATE message Error来指示。错误子代码详细说明了错误的具体性质。
If any recognized attribute has Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode is set to Attribute Length Error. The Data field contains the erroneous attribute (type, length and value).
如果任何已识别属性的属性长度与预期长度冲突（基于属性类型代码），则错误子代码将设置为属性长度错误。数据字段包含错误的属性（类型、长度和值）。
If the Encoded-Address-Prefix field in some attribute is syntactically incorrect, then the Error Subcode is set to Invalid Prefix Field.
如果某些属性中的编码地址前缀字段在语法上不正确，则错误子代码将设置为无效前缀字段。
If any other is encountered when processing attributes (such as invalid nestings), then the Error Subcode is set to Malformed Attribute List, and the problematic attribute is included in the data field.
如果在处理属性（例如无效嵌套）时遇到任何其他问题，则错误子代码将设置为格式错误的属性列表，并且有问题的属性将包含在数据字段中。
If a peer sends a NOTIFICATION message, and there is an error in that message, there is unfortunately no means of reporting this error via a subsequent NOTIFICATION message. Any such error, such as 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 and/or UPDATE and/or NOTIFICATION messages within the period specified in the Hold Time field of the OPEN message, then the NOTIFICATION message with Hold Timer Expired Error Code must be sent and the BGMP connection closed.
如果系统在打开消息的保持时间字段中指定的时间段内未连续收到KEEPALIVE和/或UPDATE和/或NOTIFICATION消息，则必须发送带有保持计时器过期错误代码的通知消息，并关闭BGMP连接。
Any error detected by the BGMP Finite State Machine (e.g., receipt of an unexpected event) is indicated by sending the NOTIFICATION message with Error Code Finite State Machine Error.
BGMP有限状态机检测到的任何错误（例如，接收到意外事件）通过发送错误代码为有限状态机错误的通知消息来指示。
In absence of any fatal errors (that are indicated in this section), a BGMP peer may choose at any given time to close its BGMP connection by sending the NOTIFICATION message with Error Code Cease. However, the Cease NOTIFICATION message must not be used when a fatal error indicated by this section does exist.
在没有任何致命错误（在本节中指出）的情况下，BGMP对等方可以在任何给定时间通过发送带有错误代码STOP的通知消息来选择关闭其BGMP连接。但是，当本节指示的致命错误确实存在时，不得使用停止通知消息。
If a pair of BGMP speakers try simultaneously to establish a TCP connection to each other, then two parallel connections between this pair of speakers might well be formed. We refer to this situation as connection collision. Clearly, one of these connections must be closed.
如果一对BGMP扬声器同时尝试彼此建立TCP连接，则这对扬声器之间可能会形成两个并行连接。我们将这种情况称为连接冲突。显然，其中一个连接必须关闭。
Based on the value of the BGMP Identifier a convention is established for detecting which BGMP connection is to be preserved when a collision does occur. The convention is to compare the BGMP
基于BGMP标识符的值，建立了一个约定，用于在发生冲突时检测要保留的BGMP连接。惯例是比较BGMP
Identifiers of the peers involved in the collision and to retain only the connection initiated by the BGMP speaker with the higher-valued BGMP Identifier.
参与冲突的对等方的标识符，并仅保留由BGMP说话人使用更高值的BGMP标识符启动的连接。
Upon receipt of an OPEN message, the local system must examine all of its connections that are in the OpenConfirm state. A BGMP speaker may also examine connections in an OpenSent state if it knows the BGMP Identifier of the peer by means outside of the protocol. If among these connections there is a connection to a remote BGMP speaker whose BGMP Identifier equals the one in the OPEN message, then the local system performs the following collision resolution procedure:
收到打开的消息后，本地系统必须检查所有处于OpenConfirm状态的连接。如果BGMP说话者通过协议之外的方式知道对等方的BGMP标识符，则也可以在OpenSent状态下检查连接。如果在这些连接中存在到远程BGMP扬声器的连接，其BGMP标识符等于打开消息中的标识符，则本地系统执行以下冲突解决过程：
1. The BGMP Identifier of the local system is compared to the BGMP Identifier of the remote system (as specified in the OPEN message).
1. 将本地系统的BGMP标识符与远程系统的BGMP标识符进行比较（如打开消息中所指定）。
2. If the value of the local BGMP Identifier is less than the remote one, the local system closes BGMP connection that already exists (the one that is already in the OpenConfirm state), and accepts BGMP connection initiated by the remote system.
2. 如果本地BGMP标识符的值小于远程BGMP标识符的值，则本地系统将关闭已存在的BGMP连接（已处于OpenConfirm状态的连接），并接受远程系统启动的BGMP连接。
3. Otherwise, the local system closes newly created BGMP 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. 否则，本地系统将关闭新创建的BGMP连接（与新接收到的打开消息相关联的连接），并继续使用现有连接（已处于OpenConfirm状态的连接）。
Comparing BGMP Identifiers is done by treating them as (4-octet long) unsigned integers.
比较BGMP标识符的方法是将它们视为（4个八位组长）无符号整数。
A connection collision with an existing BGMP connection that is in Established states causes unconditional closing of the newly created connection. Note that a connection collision cannot be detected with connections that are in Idle, or Connect, or Active states.
与处于已建立状态的现有BGMP连接的连接冲突会导致无条件关闭新创建的连接。请注意，对于处于空闲、连接或活动状态的连接，无法检测到连接冲突。
Closing the BGMP connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
关闭BGMP连接（由冲突解决过程产生）是通过发送带有错误代码STOP的通知消息来完成的。
BGMP speakers may negotiate the version of the protocol by making multiple attempts to open a BGMP connection, starting with the highest version number each supports. If an open attempt fails with an Error Code OPEN Message Error, and an Error Subcode Unsupported Version Number, then the BGMP 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
BGMP扬声器可以通过多次尝试打开BGMP连接来协商协议的版本，从各自支持的最高版本号开始。如果打开尝试失败，错误代码为“打开消息错误”，错误子代码为“不支持的版本号”，则BGMP扬声器可使用其尝试的版本号、其对等方尝试的版本号、其对等方在通知消息中传递的版本号，以及
version numbers that 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 BGMP version negotiation, future versions of BGMP must retain the format of the OPEN and NOTIFICATION messages.
它支持的版本号。如果两个对等点确实支持一个或多个通用版本，那么这将允许它们快速确定最高的通用版本。为了支持BGMP版本协商，BGMP的未来版本必须保留打开和通知消息的格式。
When a BGMP speaker sends an OPEN message to its BGMP peer, the message may include an Optional Parameter, called Capabilities. The parameter lists the capabilities supported by the speaker.
当BGMP扬声器向其BGMP对等方发送开放消息时，该消息可能包含一个可选参数，称为“能力”。该参数列出了扬声器支持的功能。
A BGMP speaker may use a particular capability when peering with another speaker only if both speakers support that capability. A BGMP speaker determines the capabilities supported by its peer by examining the list of capabilities present in the Capabilities Optional Parameter carried by the OPEN message that the speaker receives from the peer.
只有当两个扬声器都支持某一功能时，BGMP扬声器才能在与另一个扬声器进行对等时使用该功能。BGMP演讲者通过检查演讲者从对等方接收到的开放消息所携带的capabilities可选参数中存在的能力列表来确定其对等方支持的能力。
This section specifies BGMP operation in terms of a Finite State Machine (FSM). Following is a brief summary and overview of BGMP operations by state as determined by this FSM.
本节根据有限状态机（FSM）指定BGMP操作。以下是本FSM确定的按州划分的BGMP操作的简要总结和概述。
Initially BGMP is in the Idle state.
最初，BGMP处于空闲状态。
Idle state:
空闲状态：
In this state BGMP refuses all incoming BGMP connections. No resources are allocated to the peer. In response to the Start event (initiated by either system or operator) the local system initializes all BGMP resources, starts the ConnectRetry timer, initiates a transport connection to the other BGMP peer, while listening for a connection that may be initiated by the remote BGMP peer, and changes its state to Connect. The exact value of the ConnectRetry timer is a local matter, but should be sufficiently large to allow TCP initialization.
在此状态下，BGMP拒绝所有传入的BGMP连接。没有资源分配给对等方。为响应启动事件（由系统或操作员启动），本地系统初始化所有BGMP资源，启动连接重试计时器，启动到其他BGMP对等方的传输连接，同时侦听远程BGMP对等方可能启动的连接，并将其状态更改为连接。ConnectRetry计时器的确切值是本地问题，但应该足够大，以允许TCP初始化。
If a BGMP speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent BGMP errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive generation of
如果BGMP扬声器检测到错误，它将关闭连接并将其状态更改为空闲。要摆脱空闲状态，需要生成启动事件。如果自动生成此类事件，则持续的BGMP错误可能会导致扬声器持续拍打。为了避免这种情况，建议不要立即为之前由于错误而转换为空闲的对等方生成启动事件。对于之前由于错误而转换为空闲的对等方，连续生成
Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry.
如果此类事件是自动生成的，则启动事件应呈指数增长。初始计时器的值应为60秒。每次连续重试的时间应加倍。
Any other event received in the Idle state is ignored.
在空闲状态下接收到的任何其他事件都将被忽略。
Connect state:
连接状态：
In this state BGMP is waiting for the transport protocol connection to be completed.
在此状态下，BGMP正在等待传输协议连接完成。
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, and changes its state to OpenSent. If the transport protocol connect fails (e.g., retransmission timeout), the local system restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote BGMP peer, and changes its state to Active state.
如果传输协议连接成功，本地系统将清除ConnectRetry计时器，完成初始化，向其对等方发送打开消息，并将其状态更改为OpenSent。如果传输协议连接失败（例如，重传超时），本地系统将重新启动ConnectRetry计时器，继续侦听远程BGMP对等方可能发起的连接，并将其状态更改为活动状态。
In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to the other BGMP peer, continues to listen for a connection that may be initiated by the remote BGMP peer, and stays in the Connect state.
响应ConnectRetry timer expired事件，本地系统重新启动ConnectRetry timer，启动到其他BGMP对等方的传输连接，继续侦听可能由远程BGMP对等方启动的连接，并保持连接状态。
The Start event is ignored in the Connect state.
在连接状态下忽略启动事件。
In response to any other event (initiated by either system or operator), the local system releases all BGMP resources associated with this connection and changes its state to Idle.
为了响应任何其他事件（由系统或操作员启动），本地系统释放与此连接相关的所有BGMP资源，并将其状态更改为空闲。
Active state:
活动状态：
In this state BGMP is trying to acquire a peer by listening for an incoming transport protocol connection.
在此状态下，BGMP正试图通过侦听传入的传输协议连接来获取对等方。
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested.
如果传输协议连接成功，本地系统将清除ConnectRetry计时器，完成初始化，向其对等方发送打开消息，将其保持计时器设置为大值，并将其状态更改为OpenSent。建议保持计时器值为4分钟。
In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to other BGMP peer, continues to listen for a connection that may be initiated by the remote BGMP peer, and changes its state to Connect.
响应ConnectRetry timer expired事件，本地系统重新启动ConnectRetry timer，启动到其他BGMP对等方的传输连接，继续侦听可能由远程BGMP对等方启动的连接，并将其状态更改为Connect。
If the local system detects that a remote peer is trying to establish BGMP connection to it, and the IP address of the remote peer is not an expected one, the local system restarts the ConnectRetry timer, rejects the attempted connection, continues to listen for a connection that may be initiated by the remote BGMP peer, and stays in the Active state.
如果本地系统检测到远程对等方正在尝试建立与它的BGMP连接，并且远程对等方的IP地址不是预期的，则本地系统将重新启动ConnectRetry计时器，拒绝尝试的连接，继续侦听远程BGMP对等方可能发起的连接，并保持活动状态。
The Start event is ignored in the Active state.
启动事件在活动状态下被忽略。
In response to any other event (initiated by either system or operator), the local system releases all BGMP resources associated with this connection and changes its state to Idle.
为了响应任何其他事件（由系统或操作员启动），本地系统释放与此连接相关的所有BGMP资源，并将其状态更改为空闲。
OpenSent state:
OpenSent状态：
In this state BGMP waits for an OPEN message from its peer. When an OPEN message is received, all fields are checked for correctness. If the BGMP message header checking or OPEN message checking detects an error (see Section 6.2), or a connection collision (see Section 6.8) the local system sends a NOTIFICATION message and changes its state to Idle.
在此状态下，BGMP等待来自其对等方的打开消息。当收到打开的消息时，将检查所有字段的正确性。如果BGMP消息头检查或打开消息检查检测到错误（参见第6.2节）或连接冲突（参见第6.8节），本地系统将发送通知消息并将其状态更改为空闲。
If there are no errors in the OPEN message, BGMP sends a KEEPALIVE message and sets a KeepAlive timer. The Hold Timer, which was originally set to a large value (see above), is replaced with the negotiated Hold Time value (see section 4.2). If the negotiated Hold Time value is zero, then the Hold Time timer and KeepAlive timers are not started. If the configured remote Autonomous System value for this peering is the same as the local Autonomous System number, then the connection is an "internal" connection; otherwise, it is "external". Finally, the state is changed to OpenConfirm.
如果打开的消息中没有错误，BGMP将发送KEEPALIVE消息并设置KEEPALIVE计时器。最初设置为大值（见上文）的保持计时器将替换为协商的保持时间值（见第4.2节）。如果协商的保持时间值为零，则保持时间计时器和保留时间计时器不会启动。如果为该对等配置的远程自治系统值与本地自治系统编号相同，则该连接为“内部”连接；否则，它是“外部的”。最后，状态更改为OpenConfirm。
If a disconnect notification is received from the underlying transport protocol, the local system closes the BGMP connection, restarts the ConnectRetry timer, while continue listening for connection that may be initiated by the remote BGMP peer, and goes into the Active state.
如果从基础传输协议接收到断开连接通知，本地系统将关闭BGMP连接，重新启动ConnectRetry计时器，同时继续侦听可能由远程BGMP对等方启动的连接，并进入活动状态。
If the Hold Timer expires, the local system sends NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
如果保持计时器过期，本地系统将发送错误代码为保持计时器过期的通知消息，并将其状态更改为空闲。
In response to the Stop event (initiated by either system or operator) the local system sends NOTIFICATION message with Error Code Cease and changes its state to Idle.
为响应停止事件（由系统或操作员启动），本地系统发送带有错误代码Stop的通知消息，并将其状态更改为Idle。
The Start event is ignored in the OpenSent state.
在OpenSent状态下忽略启动事件。
In response to any other event the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle.
为了响应任何其他事件，本地系统发送错误代码为有限状态机错误的通知消息，并将其状态更改为空闲。
Whenever BGMP changes its state from OpenSent to Idle, it closes the BGMP (and transport-level) connection and releases all resources associated with that connection.
只要BGMP将其状态从OpenSent更改为Idle，它就会关闭BGMP（和传输级别）连接并释放与该连接相关的所有资源。
OpenConfirm state:
OpenConfirm状态：
In this state BGMP waits for a KEEPALIVE or NOTIFICATION message.
在此状态下，BGMP等待KEEPALIVE或通知消息。
If the local system receives a KEEPALIVE message, it changes its state to Established.
如果本地系统接收到KEEPALIVE消息，它会将其状态更改为“已建立”。
If the Hold Timer expires before a KEEPALIVE message is received, the local system sends NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
如果在收到KEEPALIVE消息之前保持计时器过期，本地系统将发送错误代码为保持计时器过期的通知消息，并将其状态更改为空闲。
If the local system receives a NOTIFICATION message, it changes its state to Idle.
如果本地系统收到通知消息，它会将其状态更改为空闲。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
如果KeepAlive计时器过期，本地系统将发送KeepAlive消息并重新启动其KeepAlive计时器。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
如果从基础传输协议接收到断开连接通知，则本地系统将其状态更改为空闲。
In response to the Stop event (initiated by either system or operator) the local system sends NOTIFICATION message with Error Code Cease and changes its state to Idle.
为响应停止事件（由系统或操作员启动），本地系统发送带有错误代码Stop的通知消息，并将其状态更改为Idle。
The Start event is ignored in the OpenConfirm state.
在OpenConfirm状态下忽略启动事件。
In response to any other event the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle.
为了响应任何其他事件，本地系统发送错误代码为有限状态机错误的通知消息，并将其状态更改为空闲。
Whenever BGMP changes its state from OpenConfirm to Idle, it closes the BGMP (and transport-level) connection and releases all resources associated with that connection.
每当BGMP将其状态从OpenConfirm更改为Idle时，它就会关闭BGMP（和传输级别）连接并释放与该连接相关的所有资源。
Established state:
既定国家：
In the Established state BGMP can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
在已建立状态下，BGMP可以与其对等方交换更新、通知和保留消息。
If the local system receives an UPDATE or KEEPALIVE message, it restarts its Hold Timer, if the negotiated Hold Time value is non-zero.
如果本地系统收到UPDATE或KEEPALIVE消息，如果协商的保持时间值为非零，则会重新启动其保持计时器。
If the local system receives a NOTIFICATION message, it changes its state to Idle.
如果本地系统收到通知消息，它会将其状态更改为空闲。
If the local system receives an UPDATE message and the UPDATE message error handling procedure (see Section 6.3) detects an error, the local system sends a NOTIFICATION message and changes its state to Idle.
如果本地系统收到更新消息，且更新消息错误处理程序（见第6.3节）检测到错误，则本地系统发送通知消息并将其状态更改为空闲。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
如果从基础传输协议接收到断开连接通知，则本地系统将其状态更改为空闲。
If the Hold Timer expires, the local system sends a NOTIFICATION message with Error Code Hold Timer Expired and changes its state to Idle.
如果保持计时器过期，本地系统将发送一条通知消息，错误代码为保持计时器过期，并将其状态更改为空闲。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
如果KeepAlive计时器过期，本地系统将发送KeepAlive消息并重新启动其KeepAlive计时器。
Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero.
每次本地系统发送KEEPALIVE或UPDATE消息时，它都会重新启动KEEPALIVE计时器，除非协商的保持时间值为零。
In response to the Stop event (initiated by either system or operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle.
为响应停止事件（由系统或操作员启动），本地系统发送带有错误代码Stop的通知消息，并将其状态更改为Idle。
The Start event is ignored in the Established state.
在已建立状态下忽略启动事件。
In response to any other event, the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle.
为了响应任何其他事件，本地系统发送错误代码为有限状态机错误的通知消息，并将其状态更改为空闲。
Whenever BGMP changes its state from Established to Idle, it closes the BGMP (and transport-level) connection, releases all resources associated with that connection, and deletes all routes derived from that connection.
每当BGMP将其状态从已建立更改为空闲时，它都会关闭BGMP（和传输级别）连接，释放与该连接关联的所有资源，并删除从该连接派生的所有路由。
If a BGMP speaker accepts unauthorized or altered BGMP messages, denial of service due to excess bandwidth consumption or lack of multicast connectivity can result. Authentication of BGMP messages can protect against this behavior.
如果BGMP扬声器接受未经授权或更改的BGMP消息，则可能会由于过度带宽消耗或缺少多播连接而导致拒绝服务。BGMP消息的身份验证可以防止这种行为。
A BGMP implementation MUST implement Keyed MD5 [RFC2385] to secure control messages, and MUST be capable of interoperating with peers that do not support it. However, if one side of the connection is configured with Keyed MD5 and the other side is not, the connection SHOULD NOT be established.
BGMP实现必须实现密钥MD5[RFC2385]以保护控制消息，并且必须能够与不支持它的对等方进行互操作。但是，如果连接的一侧配置了键控MD5，而另一侧未配置，则不应建立连接。
This provides a weak security mechanism, as it is still possible for denial of service to occur as a result of messages relayed through a trusted peer. However, this model is the same as the currently practiced security mechanism for BGP. It is anticipated that future work will provide different stronger mechanisms for dealing with these issues in routing protocols.
这提供了一个薄弱的安全机制，因为通过受信任的对等方转发的消息仍然可能导致拒绝服务。但是，该模型与当前BGP的安全机制相同。预计未来的工作将提供不同的、更强的机制来处理路由协议中的这些问题。
In addition to the editor, the following individuals have contributed to the design of BGMP: Cengiz Alaettinoglu, Tony Ballardie, Steve Casner, Steve Deering, Deborah Estrin, Dino Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave Meyer, and Satish Kumar.
除编辑外，以下个人也参与了BGMP的设计：森吉兹·阿莱蒂诺格鲁、托尼·巴拉迪、史蒂夫·卡斯纳、史蒂夫·迪林、黛博拉·埃斯特林、迪诺·法里纳奇、比尔·芬纳、马克·汉德利、艾哈迈德·赫尔米、范·雅各布森、戴夫·迈耶和萨蒂什·库马尔。
This document is the product of the IETF BGMP Working Group with Dave Thaler as editor.
本文件是IETF BGMP工作组的产品，由Dave Thaler担任编辑。
Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also provided valuable feedback on this document.
Rusty Eddy、Isidor Kouvelas和Pavlin Radoslavov也对该文件提供了宝贵的反馈。
[INTEROP] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[INTEROP]Thaler，D.，“多播路由协议的互操作性规则”，RFC 2715，1999年10月。
[RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[V6PREFIX] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[V6PREFIX]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[MBGP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[MBGP]Bates，T.，Rekhter，Y.，Chandra，R.，和D.Katz，“BGP-4的多协议扩展”，RFC 2858，2000年6月。
[CBT] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification", RFC 2189, September 1997.
[CBT]Ballardie，A.，“基于核心的树（CBT版本2）多播路由——协议规范”，RFC2189，1997年9月。
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, October 2003.
[DVMRP]Pusateri，T.，“距离向量多播路由协议”，正在进行的工作，2003年10月。
[IPv6AA] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6AA]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[MOSPF]Moy，J.，“OSPF的多播扩展”，RFC1584，1994年3月。
[PIMDM] Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Work in Progress, September 2003.
[PIMDM]Adams，A.，Nicholas，J.和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，正在进行的工作，2003年9月。
[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[PIMSM]Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.，和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[REFLECT] Bates, T. and R. Chandra, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[REFLECT]Bates，T.和R.Chandra，“BGP路线反射：全网格IBGP的替代品”，RFC 1966，1996年6月。
[V4PREFIX] Thaler, D., "Unicast-Prefix-based IPv4 Multicast Addresses", Work in Progress, August 2004.
[V4PREFIX]Thaler，D.，“基于单播前缀的IPv4多播地址”，正在进行的工作，2004年8月。
Authors' Address
作者地址
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft One Microsoft Way Redmond，WA 98052
EMail: dthaler@microsoft.com
EMail: dthaler@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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/S HE 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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。