Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 8279 Cisco Systems, Inc.
Category: Experimental E. Rosen, Ed.
ISSN: 2070-1721 Juniper Networks, Inc.
A. Dolganow
Nokia
T. Przygienda
Juniper Networks, Inc.
S. Aldrin
Google, Inc.
November 2017
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 8279 Cisco Systems, Inc.
Category: Experimental E. Rosen, Ed.
ISSN: 2070-1721 Juniper Networks, Inc.
A. Dolganow
Nokia
T. Przygienda
Juniper Networks, Inc.
S. Aldrin
Google, Inc.
November 2017
Multicast Using Bit Index Explicit Replication (BIER)
使用位索引显式复制（BIER）的多播
Abstract
摘要
This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.
本文档为多播数据包的转发指定了一种新的体系结构。它通过“多播域”提供多播数据包的最佳转发。但是，它不需要显式构建多播分发树的协议，也不需要中间节点来维护任何每流状态。这种体系结构称为“位索引显式复制”（BIER）。当多播数据分组进入域时，入口路由器确定分组需要发送到的出口路由器的集合。然后，入口路由器将数据包封装在BIER报头中。BIER报头包含一个位字符串，其中每个位恰好代表域中的一个出口路由器；为了将分组转发到给定的一组出口路由器，在BIER报头中设置与这些路由器对应的比特。本文件规定了基于BIER报头转发数据包的程序。消除每流状态和显式树构建协议可以大大简化。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8279.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8279.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. The BFR Identifier and BFR-Prefix ...............................7
3. Encoding BFR Identifiers in BitStrings ..........................8
4. Layering .......................................................11
4.1. The Routing Underlay ......................................11
4.2. The BIER Layer ............................................12
4.3. The Multicast Flow Overlay ................................13
5. Advertising BFR-ids and BFR-Prefixes ...........................13
6. BIER Intra-Domain Forwarding Procedures ........................15
6.1. Overview ..................................................15
6.2. BFR Neighbors .............................................17
6.3. The Bit Index Routing Table ...............................18
6.4. The Bit Index Forwarding Table ............................19
6.5. The BIER Forwarding Procedure .............................20
6.6. Examples of BIER Forwarding ...............................23
6.6.1. Example 1 ..........................................23
6.6.2. Example 2 ..........................................24
6.7. Equal-Cost Multipath Forwarding ...........................26
6.7.1. Non-deterministic ECMP .............................27
6.7.2. Deterministic ECMP .................................28
6.8. Prevention of Loops and Duplicates ........................29
6.9. When Some Nodes Do Not Support BIER .......................30
6.10. Use of Different BitStringLengths within a Domain ........33
6.10.1. BitStringLength Compatibility Check ...............34
6.10.2. Handling BitStringLength Mismatches ...............36
6.10.3. Transitioning from One BitStringLength to
Another ...........................................36
7. Operational Considerations .....................................37
7.1. Configuration .............................................37
8. IANA Considerations ............................................37
9. Security Considerations ........................................38
10. References ....................................................39
10.1. Normative References .....................................39
10.2. Informative References ...................................39
Acknowledgements ..................................................40
Contributors ......................................................41
Authors' Addresses ................................................43
1. Introduction ....................................................4
2. The BFR Identifier and BFR-Prefix ...............................7
3. Encoding BFR Identifiers in BitStrings ..........................8
4. Layering .......................................................11
4.1. The Routing Underlay ......................................11
4.2. The BIER Layer ............................................12
4.3. The Multicast Flow Overlay ................................13
5. Advertising BFR-ids and BFR-Prefixes ...........................13
6. BIER Intra-Domain Forwarding Procedures ........................15
6.1. Overview ..................................................15
6.2. BFR Neighbors .............................................17
6.3. The Bit Index Routing Table ...............................18
6.4. The Bit Index Forwarding Table ............................19
6.5. The BIER Forwarding Procedure .............................20
6.6. Examples of BIER Forwarding ...............................23
6.6.1. Example 1 ..........................................23
6.6.2. Example 2 ..........................................24
6.7. Equal-Cost Multipath Forwarding ...........................26
6.7.1. Non-deterministic ECMP .............................27
6.7.2. Deterministic ECMP .................................28
6.8. Prevention of Loops and Duplicates ........................29
6.9. When Some Nodes Do Not Support BIER .......................30
6.10. Use of Different BitStringLengths within a Domain ........33
6.10.1. BitStringLength Compatibility Check ...............34
6.10.2. Handling BitStringLength Mismatches ...............36
6.10.3. Transitioning from One BitStringLength to
Another ...........................................36
7. Operational Considerations .....................................37
7.1. Configuration .............................................37
8. IANA Considerations ............................................37
9. Security Considerations ........................................38
10. References ....................................................39
10.1. Normative References .....................................39
10.2. Informative References ...................................39
Acknowledgements ..................................................40
Contributors ......................................................41
Authors' Addresses ................................................43
This document specifies a new architecture for the forwarding of multicast data packets. The architecture provides optimal forwarding of multicast data packets through a "multicast domain". However, it does not require the use of a protocol for explicitly building multicast distribution trees, and it does not require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER).
本文档为多播数据包的转发指定了一种新的体系结构。该体系结构通过“多播域”提供多播数据包的最佳转发。但是，它不需要使用协议来显式地构建多播分发树，也不需要中间节点来维护任何每流状态。这种体系结构称为“位索引显式复制”（BIER）。
A router that supports BIER is known as a "Bit-Forwarding Router" (BFR). The BIER control-plane protocols (see Section 4.2) run within a "BIER domain", allowing the BFRs within that domain to exchange the information needed for them to forward packets to each other using BIER.
支持BIER的路由器称为“位转发路由器”（BFR）。BIER控制平面协议（见第4.2节）在“BIER域”内运行，允许该域内的BFR交换使用BIER相互转发数据包所需的信息。
A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). A BFR that receives a multicast data packet from another BFR in the same BIER domain, and forwards the packet to another BFR in the same BIER domain, will be known as a "transit BFR" for that packet. A single BFR may be a BFIR for some multicast traffic while also being a BFER for some multicast traffic and a transit BFR for some multicast traffic. In fact, for a given packet, a BFR may be a BFIR and/or a transit BFR and/or (one of) the BFER(s) for that packet.
多播数据分组在“比特转发入口路由器”（BFIR）处进入BIER域，并在一个或多个“比特转发出口路由器”（BFER）处离开BIER域。从同一BIER域中的另一BFR接收多播数据分组并将该分组转发到同一BIER域中的另一BFR的BFR将被称为该分组的“传输BFR”。单个BFR可以是某些多播流量的BFIR，同时也可以是某些多播流量的BFER，以及某些多播流量的传输BFR。事实上，对于给定分组，BFR可以是该分组的BFIR和/或传输BFR和/或（其中一个）BFER。
A BIER domain may contain one or more sub-domains. Each BIER domain MUST contain at least one sub-domain, the "default sub-domain" (also denoted "sub-domain 0"). If a BIER domain contains more than one sub-domain, each BFR in the domain MUST be provisioned to know the set of sub-domains to which it belongs. Each sub-domain is identified by a sub-domain-id in the range [0,255].
BIER域可以包含一个或多个子域。每个BIER域必须至少包含一个子域，即“默认子域”（也称为“子域0”）。如果BIER域包含多个子域，则必须设置域中的每个BFR以了解其所属的子域集。每个子域由[0255]范围内的子域id标识。
For each sub-domain to which a given BFR belongs, if the BFR is capable of acting as a BFIR or a BFER, it MUST be provisioned with a "BFR-id" that is unique within the sub-domain. A BFR-id is a small unstructured positive integer. For instance, if a particular BIER sub-domain contains 1,374 BFRs, each one could be given a BFR-id in the range [1,1374].
对于给定BFR所属的每个子域，如果BFR能够充当BFIR或BFER，则必须为其提供子域内唯一的“BFR id”。BFR id是一个小的非结构化正整数。例如，如果一个特定的BIER子域包含1374个BFR，则可以为每个子域提供[11374]范围内的BFR id。
If a given BFR belongs to more than one sub-domain, it may (though it need not) have a different BFR-id for each sub-domain.
如果给定的BFR属于多个子域，则它可能（尽管不需要）为每个子域具有不同的BFR id。
When a multicast packet arrives from outside the domain at a BFIR, the BFIR determines the set of BFERs to which the packet will be sent. The BFIR also determines the sub-domain in which the packet will be sent. Determining the sub-domain in which a given packet
当多播数据包从域外到达BFIR时，BFIR确定数据包将发送到的BFER集。BFIR还确定将在其中发送数据包的子域。确定给定数据包所在的子域
will be sent is known as "assigning the packet to a sub-domain". Procedures for choosing the sub-domain to which a particular packet is assigned are outside the scope of this document. However, once a particular packet has been assigned to a particular sub-domain, it remains assigned to that sub-domain until it leaves the BIER domain. That is, the sub-domain to which a packet is assigned MUST NOT be changed while the packet is in flight through the BIER domain.
将要发送的信息称为“将数据包分配到子域”。选择指定特定数据包的子域的步骤不在本文档的范围内。然而，一旦一个特定的数据包被分配到一个特定的子域，它将一直被分配到该子域，直到它离开BIER域。也就是说，当数据包在BIER域中飞行时，不能更改分配给它的子域。
Once the BFIR determines the sub-domain and the set of BFERs for a given packet, the BFIR encapsulates the packet in a "BIER header". The BIER header contains a bit string in which each bit represents a single BFR-id. To indicate that a particular BFER is to receive a given packet, the BFIR sets the bit corresponding to that BFER's BFR-id in the sub-domain to which the packet has been assigned. We will use the term "BitString" to refer to the bit string field in the BIER header. We will use the term "payload" to refer to the packet that has been encapsulated. Thus, a "BIER-encapsulated" packet consists of a "BIER header" followed by a "payload".
一旦BFIR确定给定数据包的子域和BFER集，BFIR将数据包封装在“BIER头”中。BIER报头包含一个位字符串，其中每个位表示一个BFR-id。为了指示特定BFER将接收给定的数据包，BFIR在数据包分配到的子域中设置与该BFER的BFR id对应的位。我们将使用术语“位字符串”来指代BIER标头中的位字符串字段。我们将使用术语“有效负载”来指代已封装的数据包。因此，“BIER封装”数据包由“BIER头”和“有效载荷”组成。
The number of BFERs to which a given packet can be forwarded is limited only by the length of the BitString in the BIER header. Different deployments can use different BitString lengths. We will use the term "BitStringLength" to refer to the number of bits in the BitString. It is possible that some deployments will have more BFERs in a given sub-domain than there are bits in the BitString. To accommodate this case, the BIER encapsulation includes both the BitString and a "Set Identifier" (SI). It is the BitString and the SI together that determine the set of BFERs to which a given packet will be delivered:
给定数据包可转发到的BFER数量仅受BIER报头中位字符串长度的限制。不同的部署可以使用不同的位字符串长度。我们将使用术语“BitStringLength”来表示位字符串中的位数。某些部署在给定子域中的BFER可能多于位字符串中的位。为了适应这种情况，BIER封装包括位字符串和“集合标识符”（SI）。正是位字符串和SI共同决定了给定数据包将被传送到的BFER集合：
o By convention, the least significant (rightmost) bit in the BitString is "bit 1", and the most significant (leftmost) bit is "bit BitStringLength".
o 按照惯例，位字符串中的最低有效位（最右边的）是“位1”，最高有效位（最左边的）是“位BitStringLength”。
o If a BIER-encapsulated packet has an SI of n and a BitString with bit k set, then the packet must be delivered to the BFER whose BFR-id (in the sub-domain to which the packet has been assigned) is n*BitStringLength+k.
o 如果BIER封装的数据包具有n的SI和设置了位k的位字符串，则必须将该数据包交付给BFR id（在该数据包已分配到的子域中）为n*BitStringLength+k的BFER。
For example, suppose the BIER encapsulation uses a BitStringLength of 256 bits. By convention, the least significant (rightmost) bit is bit 1, and the most significant (leftmost) bit is bit 256. Suppose that a given packet has been assigned to sub-domain 0 and needs to be delivered to three BFERs, where those BFERs have BFR-ids in sub-domain 0 of 13, 126, and 235, respectively. The BFIR would create a BIER encapsulation with the SI set to zero and with bits 13, 126, and 235 of the BitString set. (All other bits of the BitString would be clear.) If the packet also needs to be sent to a BFER whose
例如，假设BIER封装使用256位的BitStringLength。按照惯例，最低有效位（最右边）是位1，最高有效位（最左边）是位256。假设给定的数据包已分配给子域0，并且需要传递给三个BFER，其中这些BFER在子域0中的BFR ID分别为13、126和235。BFIR将创建一个BIER封装，SI设置为零，位串设置为13、126和235。（位字符串的所有其他位都将被清除。）如果数据包还需要发送到
BFR-id is 257, the BFIR would have to create a second copy of the packet, and the BIER encapsulation would specify an SI of 1, and a BitString with bit 1 set and all the other bits clear.
BFR id为257，BFIR必须创建数据包的第二个副本，BIER封装将指定SI为1，并指定一个设置了位1且所有其他位都已清除的位字符串。
It is generally advantageous to assign the BFR-ids of a given sub-domain so that as many BFERs as possible can be represented in a single bit string.
通常，分配给定子域的BFR id是有利的，这样就可以在一个位字符串中表示尽可能多的bfer。
Suppose a BFR (call it "BFR-A") receives a packet whose BIER encapsulation specifies an SI of 0 and a BitString with bits 13, 26, and 235 set. Suppose BFR-A has two BFR neighbors, BFR-B and BFR-C, such that the best path to BFERs 13 and 26 is via BFR-B, but the best path to BFER 235 is via BFR-C. BFR-A will then replicate the packet, sending one copy to BFR-B and one copy to BFR-C. However, BFR-A will clear bit 235 in the BitString of the packet copy it sends to BFR-B and will clear bits 13 and 26 in the BitString of the packet copy it sends to BFR-C. As a result, BFR-B will forward the packet only towards BFERs 13 and 26, and BFR-C will forward the packet only towards BFER 235. This ensures that each BFER receives only one copy of the packet.
假设一个BFR（称之为“BFR-a”）接收到一个数据包，其BIER封装指定SI为0，并设置了位13、26和235的位字符串。假设BFR-A有两个BFR邻居BFR-B和BFR-C，这样到BFER 13和26的最佳路径是通过BFR-B，但到BFER 235的最佳路径是通过BFR-C。BFR-A随后将复制数据包，向BFR-B发送一个副本，向BFR-C发送一个副本。然而，BFR-A将清除发送给BFR-B的数据包副本的位字符串中的位235，并将清除发送给BFR-C的数据包副本的位字符串中的位13和26。因此，BFR-B将只向BFER 13和26转发数据包，BFR-C将只向BFER 235转发数据包。这确保每个BFER只接收一个数据包副本。
Detailed procedures for forwarding a BIER-encapsulated packet through a BIER domain can be found in Section 6.
有关通过BIER域转发BIER封装数据包的详细程序，请参见第6节。
With this forwarding procedure, a multicast data packet can follow an optimal path from its BFIR to each of its BFERs. Further, since the set of BFERs for a given packet is explicitly encoded into the BIER header, the packet is not sent to any BFER that does not need to receive it. This allows for optimal forwarding of multicast traffic. This optimal forwarding is achieved without any need for transit BFRs to maintain per-flow state or to run a multicast tree-building protocol.
通过此转发过程，多播数据包可以遵循从其BFIR到其每个BFER的最佳路径。此外，由于给定分组的BFER集合被显式编码到BIER报头中，因此分组不被发送到不需要接收它的任何BFER。这允许多播流量的最佳转发。这种最佳转发是在不需要传输BFR来维持每个流状态或运行多播树构建协议的情况下实现的。
The idea of encoding the set of egress nodes into the header of a multicast packet is not new. For example, [Boivie_Feldman] proposes to encode the set of egress nodes as a set of IP addresses, and proposes mechanisms and procedures that are in some ways similar to those described in the current document. However, since BIER encodes each BFR-id as a single bit in a bit string, it can represent up to 128 BFERs in the same number of bits that it would take to carry the IPv6 address of a single BFER. Thus, BIER scales to a much larger number of egress nodes per packet.
将出口节点集编码到多播分组的报头中的想法并不新鲜。例如，[Boivie_Feldman]建议将出口节点集编码为一组IP地址，并提出在某些方面类似于当前文档中描述的机制和过程。但是，由于BIER将每个BFR id编码为位字符串中的一个位，因此它最多可以表示128个BFER，其位数与承载单个BFER的IPv6地址所需的位数相同。因此，BIER可以扩展到每个数据包中更多的出口节点。
BIER does not require that each transit BFR look up the best path to each BFER that is identified in the BIER header; the number of lookups required in the forwarding path for a single packet can be
BIER不要求每个运输BFR查找BIER标题中标识的每个BFER的最佳路径；单个数据包的转发路径中所需的查找次数可以是
limited to the number of neighboring BFRs; this can be much smaller than the number of BFERs. See Section 6 (especially Section 6.5) for details.
限制相邻BFR的数量；这可能比BFER的数量小得多。详见第6节（特别是第6.5节）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Each BFR MUST be assigned a single "BFR-prefix" for each sub-domain to which it belongs. A BFR's BFR-prefix MUST be an IP address (either IPv4 or IPv6) of the BFR. It is RECOMMENDED that the BFR-prefix be a loopback address of the BFR.
每个BFR必须为其所属的每个子域分配一个“BFR前缀”。BFR的BFR前缀必须是BFR的IP地址（IPv4或IPv6）。建议将BFR前缀作为BFR的环回地址。
If a BFR belongs to more than one sub-domain, it may (though it need not) have a different BFR-prefix in each sub-domain.
如果一个BFR属于多个子域，它可能（尽管不需要）在每个子域中具有不同的BFR前缀。
All BFR-prefixes used within a given sub-domain MUST belong to the same address family (either IPv4 or IPv6).
给定子域中使用的所有BFR前缀必须属于同一地址系列（IPv4或IPv6）。
The BFR-prefix of a given BFR in a given sub-domain MUST be routable in that sub-domain. Whether a particular BFR-prefix is routable in a given sub-domain depends on the "routing underlay" associated with that sub-domain. The notion of "routing underlay" is described in Section 4.1.
给定子域中给定BFR的BFR前缀必须可在该子域中路由。特定BFR前缀是否可在给定子域中路由取决于与该子域关联的“路由参考底图”。第4.1节描述了“布线参考底图”的概念。
A "BFR Identifier" (BFR-id) is a number in the range [1,65535]. Within a given sub-domain, every BFR that may need to function as a BFIR or BFER MUST have a single BFR-id, which identifies it uniquely within that sub-domain. A BFR that does not need to function as a BFIR or BFER in a given sub-domain does not need to have a BFR-id in that sub-domain.
“BFR标识符”（BFR id）是范围[165535]内的数字。在给定的子域内，可能需要用作BFIR或BFER的每个BFR必须具有单个BFR id，该id在该子域内唯一地标识它。不需要在给定子域中充当BFIR或BFER的BFR不需要在该子域中具有BFR id。
The value 0 is not a legal BFR-id.
值0不是合法的BFR-id。
The procedure for assigning a particular BFR-id to a particular BFR is outside the scope of this document. However, it is RECOMMENDED that the BFR-ids for each sub-domain be assigned "densely" from the numbering space, as this will result in a more efficient encoding (see Section 3). That is, if there are 256 or fewer BFERs, it is RECOMMENDED to assign all the BFR-ids from the range [1,256]. If there are more than 256 BFERs but less than 512, it is RECOMMENDED to assign all the BFR-ids from the range [1,512], with as few "holes" as
将特定BFR id分配给特定BFR的过程不在本文档的范围内。但是，建议从编号空间“密集”分配每个子域的BFR ID，因为这将导致更有效的编码（参见第3节）。也就是说，如果有256个或更少的BFR，建议分配范围[1256]中的所有BFR ID。如果BFR超过256个，但小于512个，建议分配范围[1512]中的所有BFR ID，尽可能少的“孔”
possible in the earlier range. However, in some deployments, it may be advantageous to depart from this recommendation; this is discussed further in Section 3.
可能在较早的范围内。然而，在某些部署中，偏离此建议可能是有利的；这将在第3节中进一步讨论。
In some deployments, it may not be possible to support (in a given sub-domain) the full range of 65,535 BFR-ids. For example, if the BFRs in a given sub-domain only support 16 SIs and if they only support BitStringLengths of 256 or less, then only 16*256=4,096 BFR-ids can be supported in that sub-domain.
在某些部署中，可能无法支持（在给定子域中）全部65535个BFR ID。例如，如果给定子域中的BFR仅支持16个SIs，并且仅支持256或更少的BitStringLength，则该子域中只能支持16*256=4096个BFR ID。
To encode a BFR-id in a BIER data packet, one must convert the BFR-id to an SI and a BitString. This conversion depends upon the parameter we are calling "BitStringLength". The conversion is done as follows. If the BFR-id is N, then
要在BIER数据包中编码BFR id，必须将BFR id转换为SI和位字符串。此转换取决于我们称之为“BitStringLength”的参数。转换过程如下所示。如果BFR id为N，则
o SI is the integer part of the quotient (N-1)/BitStringLength.
o SI是商（N-1）/BitStringLength的整数部分。
o The BitString has one bit position set. If the low-order bit is bit 1 and the high-order bit is bit BitStringLength, the bit position that represents BFR-id N is ((N-1) modulo BitStringLength)+1.
o 位字符串设置了一个位位置。如果低阶位为位1，高阶位为位BitStringLength，则表示BFR id N的位位置为（（N-1）模BitStringLength）+1。
If several different BFR-ids all resolve to the same SI, then all of those BFR-ids can be represented in a single BitString. The BitStrings for all of those BFR-ids are combined using a bitwise logical OR operation.
如果几个不同的BFR ID都解析为相同的SI，那么所有这些BFR ID都可以用一个位字符串表示。所有这些BFR ID的位字符串都使用按位逻辑OR操作进行组合。
Within a given BIER domain (or even within a given BIER sub-domain), different values of BitStringLength may be used. Each BFR MUST be provisioned to know the following:
在给定的BIER域内（甚至在给定的BIER子域内），可以使用不同的BitStringLength值。必须为每个BFR提供以下信息：
o The BitStringLength ("Imposition BitStringLength") and sub-domain ("Imposition sub-domain") to use when it imposes (as a BFIR) a BIER encapsulation on a particular set of packets, and
o 在对特定数据包集施加（作为BFIR）BIER封装时使用的BitStringLength（“施加BitStringLength”）和子域（“施加子域”），以及
o The BitStringLengths ("Disposition BitStringLengths") that it will process when (as a BFR or BFER) it receives packets from a particular sub-domain.
o 当（作为BFR或BFER）从特定子域接收数据包时，它将处理的BitStringLength（“Disposition BitStringLength”）。
It is not required that a BFIR use the same Imposition BitStringLength or the same Imposition sub-domain for all packets on which it imposes the BIER encapsulation. However, if a particular BFIR is provisioned to use a particular Imposition BitStringLength and a particular Imposition sub-domain when imposing the encapsulation on a given set of packets, all other BFRs with BFR-ids in that sub-domain SHOULD be provisioned to process received BIER
不要求BFIR对其施加BIER封装的所有数据包使用相同的强制比特串长度或相同的强制子域。然而，如果在对给定分组集施加封装时，将特定BFIR设置为使用特定施加位串长度和特定施加子域，则应将该子域中具有BFR ID的所有其他BFR设置为处理接收到的BIER
packets with that BitStringLength (i.e., all other BFRs with BFR-ids in that sub-domain SHOULD be provisioned with that BitStringLength as a Disposition BitStringLength for that sub-domain). Exceptions to this rule MAY be made under certain conditions; this is discussed in Section 6.10.
具有该BitStringLength的数据包（即，该子域中具有BFR ID的所有其他BFR应使用该BitStringLength作为该子域的处置BitStringLength进行配置）。本条规则的例外情况可在某些条件下作出；第6.10节对此进行了讨论。
When a BIER encapsulation is specified, the specification MUST define a default BitStringLength for the encapsulation. Every BFIR supporting that encapsulation MUST be capable of being provisioned with that default BitStringLength as its Imposition BitStringLength. Every BFR and BFER supporting that encapsulation MUST be capable of being provisioned with that default BitStringLength as a Disposition BitStringLength.
当指定BIER封装时，规范必须为封装定义默认的BitStringLength。支持该封装的每个BFIR必须能够以该默认BitStringLength作为其强制BitStringLength进行配置。支持该封装的每个BFR和BFER必须能够以默认的BitStringLength作为处置BitStringLength进行配置。
The specification of a BIER encapsulation MAY also allow the use of other BitStringLengths.
BIER封装的规范也允许使用其他BitStringLength。
If a BFR is capable of being provisioned with a given value of BitStringLength as an Imposition BitStringLength, it MUST also be capable of being provisioned with that same value as one of its Disposition BitStringLengths. It SHOULD be capable of being provisioned with each legal smaller value of BitStringLength as (a) its Imposition BitStringLength, and (b) one of its Disposition BitStringLengths.
如果BFR能够以给定的BitStringLength值作为施加BitStringLength进行设置，则它还必须能够以与其处置BitStringLength之一相同的值进行设置。它应该能够配置每个合法较小的BitStringLength值，如（a）其强制设置的BitStringLength，和（b）其处置的BitStringLength之一。
In order to support transition from one BitStringLength to another, every BFR MUST be capable of being provisioned to simultaneously use two different Disposition BitStringLengths.
为了支持从一个BitStringLength到另一个BitStringLength的转换，每个BFR必须能够被配置为同时使用两个不同的配置BitStringLength。
A BFR MUST support SI values in the range [0,15] and MAY support SI values in the range [0,255]. ("Supporting the values in a given range" means, in this context, that any value in the given range is legal and will be properly interpreted.) Note that for a given BitStringLength, the total number of BFR-ids that can be represented is the product of the BitStringLength and the number of supported SIs. For example, if a deployment uses (in a given sub-domain) a BitStringLength of 64 and supports 256 SIs, that deployment can only support 16384 BFR-ids in that sub-domain. Even a deployment that supports 256 SIs will not be able to support 65,535 BFR-ids unless it uses a BitStringLength of at least 256.
BFR必须支持[0,15]范围内的SI值，并且可以支持[0255]范围内的SI值。（“支持给定范围内的值”在此上下文中意味着给定范围内的任何值都是合法的，并将被正确解释。）请注意，对于给定的BitStringLength，可以表示的BFR ID总数是BitStringLength和支持的SIs数的乘积。例如，如果部署（在给定子域中）使用64位字符串长度并支持256个SIs，则该部署只能支持该子域中的16384个BFR ID。即使支持256 SIs的部署也无法支持65535 BFR ID，除非它使用的BitStringLength至少为256。
When a BFIR determines that a multicast data packet, assigned to a given sub-domain, needs to be forwarded to a particular set of destination BFERs, the BFIR partitions that set of BFERs into subsets, where each subset contains the target BFERs whose BFR-ids in the given sub-domain all resolve to the same SI. Call these the "SI-subsets" for the packet. Each SI-subset can be represented by a single BitString. The BFIR creates a copy of the packet for each
当BFIR确定分配给给定子域的多播数据包需要转发到一组特定的目标BFER时，BFIR将该组BFER划分为子集，其中每个子集包含目标BFER，其在给定子域中的BFR ID都解析为同一SI。将这些称为数据包的“SI子集”。每个SI子集可以由单个位字符串表示。BFIR为每个用户创建数据包的副本
SI-subset. The BIER encapsulation is then applied to each packet. The encapsulation specifies a single SI for each packet and contains the BitString that represents all the BFR-ids in the corresponding SI-subset. Of course, in order to properly interpret the BitString, it must be possible to infer the sub-domain-id from the encapsulation as well.
SI子集。然后将BIER封装应用于每个数据包。封装为每个数据包指定一个SI，并包含表示相应SI子集中所有BFR ID的位字符串。当然，为了正确解释位字符串，还必须能够从封装中推断子域id。
Suppose, for example, that a BFIR determines that a given packet needs to be forwarded to three BFERs, whose BFR-ids (in the appropriate sub-domain) are 27, 235, and 497. The BFIR will have to forward two copies of the packet. One copy, associated with SI=0, will have a BitString with bits 27 and 235 set. The other copy, associated with SI=1, will have a BitString with bit 241 set.
例如，假设BFIR确定给定分组需要转发到三个bfer，其BFR id（在适当的子域中）为27、235和497。BFIR必须转发两份数据包副本。一个与SI=0关联的副本将具有设置了位27和235的位字符串。与SI=1关联的另一个副本将具有设置了位241的位字符串。
In order to minimize the number of copies that must be made of a given multicast packet, it is RECOMMENDED that the BFR-ids used in a given sub-domain be assigned "densely" (see Section 2) from the numbering space. This will minimize the number of SIs that have to be used in that sub-domain. However, depending upon the details of a particular deployment, other assignment methods may be more advantageous. Suppose, for example, that in a certain deployment, every multicast flow is intended either for the "east coast" or for the "west coast", but not for both coasts. In such a deployment, it would be advantageous to assign BFR-ids so that all the "west coast" BFR-ids fall into the same SI-subset and so that all the "east coast" BFR-ids fall into the same SI-subset.
为了最大限度地减少给定多播数据包的副本数量，建议从编号空间“密集”地分配给定子域中使用的BFR ID（见第2节）。这将最大限度地减少该子域中必须使用的SIs数量。然而，根据特定部署的细节，其他分配方法可能更有利。例如，假设在某个部署中，每个多播流都针对“东海岸”或“西海岸”，但不针对两个海岸。在这种部署中，分配BFR ID将是有利的，以便所有“西海岸”BFR ID落入相同的SI子集，并且所有“东海岸”BFR ID落入相同的SI子集。
When a BFR receives a BIER data packet, it will infer the SI from the encapsulation. The set of BFERs to which the packet needs to be forwarded can then be inferred from the SI and the BitString.
当BFR接收到BIER数据包时，它将根据封装推断SI。然后，可以从SI和位字符串推断数据包需要转发到的BFER集。
In some of the examples given later in this document, we will use a BitStringLength of 4 and will represent a BFR-id in the form "SI:xyzw", where SI is the Set Identifier of the BFR-id (assuming a BitStringLength of 4) and xyzw is a string of 4 bits. A BitStringLength of 4 is used only in the examples; we would not expect actual deployments to have such a small BitStringLength.
在本文后面给出的一些示例中，我们将使用BitStringLength 4，并将以“SI:xyzw”的形式表示BFR id，其中SI是BFR id的集合标识符（假设BitStringLength为4），xyzw是4位的字符串。仅在示例中使用4的BitStringLength；我们不希望实际部署具有如此小的BitStringLength。
It is possible that several different forms of BIER encapsulation will be developed. If so, the particular encapsulation that is used in a given deployment will depend on the type of network infrastructure that is used to realize the BIER domain. Details of the BIER encapsulation(s) will be given in companion documents. An encapsulation for use in MPLS networks is described in [MPLS_BIER_ENCAPS]; that document also describes a very similar encapsulation that can be used in non-MPLS networks.
可能会开发几种不同形式的BIER封装。如果是这样，在给定部署中使用的特定封装将取决于用于实现BIER域的网络基础设施的类型。BIER封装的详细信息将在配套文件中给出。在[MPLS_BIER_ENCAPS]中描述了用于MPLS网络的封装；该文档还描述了一种非常类似的封装，可用于非MPLS网络。
It is helpful to think of the BIER architecture as consisting of three layers: the "routing underlay", the "BIER layer", and the "multicast flow overlay".
将BIER体系结构视为由三层组成是有帮助的：“路由底层”、“BIER层”和“多播流覆盖”。
The "routing underlay" establishes "adjacencies" between pairs of BFRs and determines one or more "best paths" from a given BFR to a given set of BFRs. Each such path is a sequence of BFRs <BFR(k), BFR(k+1), ..., BFR(k+n)> such that BFR(k+j) is "adjacent" to BFR(k+j+1) (for 0<=j<n).
“布线参考底图”在成对BFR之间建立“邻接”，并确定从给定BFR到给定BFR集的一条或多条“最佳路径”。每个这样的路径是BFR<BFR（k），BFR（k+1），…，BFR（k+n）>的序列，使得BFR（k+j）与BFR（k+j+1）“相邻”（对于0<=j<n）。
At a given BFR, say BFR-A, for every IP address that is the address of a BFR in the BIER domain, the routing underlay will map that IP address into a set of one or more "equal-cost" adjacencies. If a BIER data packet has to be forwarded by BFR-A to a given BFER, say BFER-B, the packet will follow the path from BFR-A to BFER-B that is determined by the routing underlay.
在给定的BFR（例如BFR-a），对于BIER域中BFR的每个IP地址，路由参考底图将该IP地址映射到一组一个或多个“同等成本”邻接中。如果BIER数据包必须由BFR-a转发到给定的BFER，例如BFER-B，则该数据包将遵循路由参考底图确定的从BFR-a到BFER-B的路径。
It is expected that in a typical deployment, the routing underlay will be the default topology that the Interior Gateway Protocol (IGP), e.g., OSPF, uses for unicast routing. In that case, the underlay adjacencies are just the OSPF adjacencies. A BIER data packet traveling from BFR-A to BFER-B will follow the path that OSPF has selected for unicast traffic from BFR-A to BFER-B.
预计在典型部署中，路由参考底图将是内部网关协议（IGP）（例如OSPF）用于单播路由的默认拓扑。在这种情况下，参考底图邻接就是OSPF邻接。从BFR-A到BFER-B的BIER数据包将遵循OSPF为从BFR-A到BFER-B的单播业务选择的路径。
If one wants to have multicast traffic from BFR-A to BFER-B travel a path that is different from the path used by the unicast traffic from BFR-A to BFER-B, one can use a different underlay. For example, if multi-topology OSPF is being used, one OSPF topology could be used for unicast traffic and the other for multicast traffic. (Each topology would be considered to be a different underlay.) Alternatively, one could deploy a routing underlay that creates a multicast-specific tree of some sort. BIER could then be used to forward multicast data packets along the multicast-specific tree, while unicast packets follow the "ordinary" OSPF best path. (In a case like this, many multicast flows could be traveling along a single tree, and the BitString carried by a particular packet would identify those nodes of the tree that need to receive that packet.) It is even possible to have multiple routing underlays used by BIER, as long as one can infer from a data packet's BIER encapsulation which underlay is being used for that packet.
如果希望让从BFR-A到BFER-B的多播流量通过与从BFR-A到BFER-B的单播流量使用的路径不同的路径，可以使用不同的参考底图。例如，如果使用多拓扑OSPF，则一个OSPF拓扑可用于单播流量，另一个用于多播流量。（每个拓扑将被视为不同的参考底图。）或者，可以部署一个路由参考底图，创建某种特定于多播的树。然后可以使用BIER沿着多播特定树转发多播数据包，而单播数据包遵循“普通”OSPF最佳路径。（在这种情况下，许多多播流可能沿着一棵树传播，特定数据包携带的位字符串将识别需要接收该数据包的树节点。）BIER甚至可以使用多个路由基线，只要能从数据包的BIER封装中推断出该数据包使用的是哪个底层。
If multiple routing underlays are used in a single BIER domain, each BIER sub-domain MUST be associated with a single routing underlay (though multiple sub-domains may be associated with the same routing underlay). A BFR that belongs to multiple sub-domains MUST be provisioned to know which routing underlay is used by each sub-domain. By default (i.e., in the absence of any provisioning to the contrary), each sub-domain uses the default topology of the unicast IGP as the routing underlay.
如果在单个BIER域中使用多个布线参考底图，则每个BIER子域必须与单个布线参考底图关联（尽管多个子域可能与同一布线参考底图关联）。必须设置属于多个子域的BFR，以了解每个子域使用哪个路由参考底图。默认情况下（即，在没有任何相反设置的情况下），每个子域使用单播IGP的默认拓扑作为路由参考底图。
In scenarios where External BGP (EBGP) is used as the IGP, the underlay adjacencies, by default, are the BGP adjacencies.
在使用外部BGP（EBGP）作为IGP的场景中，参考底图邻接默认为BGP邻接。
Specification of the protocols and procedures of the routing underlay is outside the scope of this document.
路由参考底图的协议和程序规范不在本文件范围内。
The BIER layer consists of the protocols and procedures that are used in order to transmit a multicast data packet across a BIER domain, from its BFIR to its BFERs. This includes the following components:
BIER层由协议和过程组成，这些协议和过程用于跨BIER域将多播数据包从其BFIR传输到其BFER。这包括以下组件：
o Protocols and procedures that a given BFR uses to advertise, to all other BFRs in the same BIER domain:
o 给定BFR用于向同一BIER域中的所有其他BFR发布的协议和程序：
* its BFR-prefix;
* 其BFR前缀；
* its BFR-id in each sub-domain for which it has been provisioned with a BFR-id;
* 为其提供BFR id的每个子域中的BFR id；
* the set of Disposition BitStringLengths it has been provisioned to use for each sub-domain;
* 为每个子域提供的一组处置位字符串长度；
* optionally, information about the routing underlay associated with each sub-domain.
* （可选）提供有关与每个子域关联的布线参考底图的信息。
o The procedures used by a BFIR to impose a BIER header on a multicast data packet.
o BFIR用于将BIER报头强加于多播数据包的过程。
o The procedures for forwarding BIER-encapsulated packets and for modifying the BIER header during transit.
o 转发BIER封装数据包和在传输过程中修改BIER报头的过程。
o The procedures used by a BFER to decapsulate a BIER packet and properly dispatch it.
o BFER用来拆封BIER数据包并正确分发它的过程。
The "multicast flow overlay" consists of the set of protocols and procedures that enable the following set of functions.
“多播流覆盖”由一组协议和过程组成，这些协议和过程支持以下一组功能。
o When a BFIR receives a multicast data packet from outside the BIER domain, the BFIR must determine the set of BFERs for that packet. This information is provided by the multicast flow overlay.
o 当BFIR从BIER域外部接收多播数据包时，BFIR必须确定该数据包的BFER集。此信息由多播流覆盖提供。
o When a BFER receives a BIER-encapsulated packet from inside the BIER domain, the BFER must determine how to further forward the packet. This information is provided by the multicast flow overlay.
o 当BFER从BIER域内部接收到BIER封装的数据包时，BFER必须确定如何进一步转发该数据包。此信息由多播流覆盖提供。
For example, suppose the BFIR and BFERs are Provider Edge (PE) routers providing Multicast Virtual Private Network (MVPN) service. The multicast flow overlay consists of the protocols and procedures described in [RFC6513] and [RFC6514]. The MVPN signaling described in those RFCs enables an ingress PE to determine the set of egress PEs for a given multicast flow (or set of flows); it also enables an egress PE to determine the "Virtual Routing and Forwarding Tables" (VRFs) to which multicast packets from the backbone network should be sent. MVPN signaling also has several components that depend on the type of "tunneling technology" used to carry multicast data through the network. Since BIER is, in effect, a new type of "tunneling technology", some extensions to the MVPN signaling are needed in order to properly interface the multicast flow overlay with the BIER layer. These are specified in [BIER_MVPN].
例如，假设BFIR和BFER是提供多播虚拟专用网（MVPN）服务的提供商边缘（PE）路由器。多播流覆盖由[RFC6513]和[RFC6514]中描述的协议和过程组成。这些rfc中描述的MVPN信令使得入口PE能够确定给定多播流（或一组流）的出口PE的集合；它还使出口PE能够确定“虚拟路由和转发表”（VRF），从骨干网络向其发送多播数据包。MVPN信令还有几个组件，它们取决于用于通过网络传输多播数据的“隧道技术”的类型。由于BIER实际上是一种新型的“隧道技术”，因此需要对MVPN信令进行一些扩展，以便正确地将多播流覆盖与BIER层连接起来。这些在[BIER_MVPN]中规定。
MVPN is just one example of a multicast flow overlay. Protocols and procedures for other overlays will be provided in companion documents. It is also possible to implement the multicast flow overlay by means of a "Software-Defined Network" (SDN) controller. Specification of the protocols and procedures of the multicast flow overlay is outside the scope of this document.
MVPN只是多播流覆盖的一个示例。其他覆盖的协议和程序将在配套文件中提供。还可以通过“软件定义网络”（SDN）控制器实现多播流覆盖。多播流覆盖协议和程序的规范不在本文档范围内。
As stated in Section 2, each BFER is assigned (by provisioning) a BFR-id (for a given BIER sub-domain). Each BFER must advertise these assignments to all the other BFRs in the domain. Similarly, each BFR is assigned (by provisioning) a BFR-prefix (for a given BIER domain) and must advertise this assignment to all the other BFRs in the domain. Finally, each BFR has been provisioned to use a certain set of Disposition BitStringLengths for each sub-domain and must advertise these to all other BFRs in the domain.
如第2节所述，每个BFER（通过提供）分配一个BFR id（用于给定的BIER子域）。每个BFER必须向域中的所有其他BFR公布这些分配。类似地，每个BFR都被分配（通过配置）一个BFR前缀（对于给定的BIER域），并且必须将此分配公布给域中的所有其他BFR。最后，每个BFR已设置为对每个子域使用一组特定的处置BitStringLength，并且必须向域中的所有其他BFR公布这些处置BitStringLength。
If the BIER domain is also a link-state routing IGP domain (i.e., an OSPF or IS-IS domain), the advertisement of the BFR-prefix, <sub-domain-id, BFR-id>, and BitStringLength can be done using the advertisement capabilities of the IGP. For example, if a BIER domain is also an OSPF domain, these advertisements can be done using the OSPF "Opaque Link State Advertisement" (Opaque LSA) mechanism. Details of the necessary extensions to OSPF and IS-IS will be provided in companion documents. (See [OSPF_BIER_EXTENSIONS] and [ISIS_BIER_EXTENSIONS].)
如果BIER域也是链路状态路由IGP域（即，OSPF或is-is域），则可以使用IGP的播发功能来播发BFR前缀、<sub-domain id，BFR id>和BitStringLength。例如，如果BIER域也是OSPF域，则可以使用OSPF“不透明链路状态播发”（不透明LSA）机制来完成这些播发。OSPF和IS-IS的必要扩展细节将在配套文件中提供。（请参见[OSPF-BIER-U扩展]和[ISIS-BIER-U扩展]）
If, in a particular deployment, the BIER domain is not an OSPF or IS-IS domain, procedures suitable to the deployment must be used to advertise this information. Details of the necessary procedures will be provided in companion documents. For example, if BGP is the only routing algorithm used in the BIER domain, the procedures of [BGP_BIER_EXTENSIONS] may be used.
如果在特定部署中，BIER域不是OSPF或is-is域，则必须使用适合该部署的程序来公布该信息。配套文件中将提供必要程序的详细信息。例如，如果BGP是BIER域中使用的唯一路由算法，则可以使用[BGP_BIER_EXTENSIONS]的过程。
These advertisements enable each BFR to associate a given <sub-domain-id, BFR-id> with a given BFR-prefix. As will be seen in subsequent sections of this document, knowledge of this association is an important part of the forwarding process.
这些播发使每个BFR能够将给定的<sub-domain id，BFR id>与给定的BFR前缀相关联。如本文件后续章节所示，了解这种关联是转发过程的重要组成部分。
Since each BFR needs to have a unique (in each sub-domain) BFR-id, two different BFRs will not advertise ownership of the same <sub-domain-id, BFR-id> unless there has been a provisioning error.
由于每个BFR需要有一个唯一的（在每个子域中）BFR id，因此两个不同的BFR不会公布相同<sub-domain id，BFR id>的所有权，除非出现设置错误。
o If BFR-A determines that BFR-B and BFR-C have both advertised the same BFR-id for the same sub-domain, BFR-A MUST log an error. Suppose that the duplicate BFR-id is "N". When BFR-A is functioning as a BFIR, it MUST NOT encode the BFR-id value N in the BIER encapsulation of any packet that has been assigned to the given sub-domain, even if it has determined that the packet needs to be received by BFR-B and/or BFR-C.
o 如果BFR-A确定BFR-B和BFR-C都为同一子域播发了相同的BFR id，则BFR-A必须记录错误。假设重复的BFR id为“N”。当BFR-A作为BFIR运行时，它不得在已分配给给定子域的任何数据包的BIER封装中编码BFR id值N，即使它已确定该数据包需要由BFR-B和/或BFR-C接收。
This will mean that BFR-B and BFR-C cannot receive multicast traffic at all in the given sub-domain until the provisioning error is fixed. However, that is preferable to having them receive each other's traffic.
这将意味着BFR-B和BFR-C在给定子域中根本无法接收多播流量，直到设置错误得到修复。然而，这比让它们接收彼此的通信量要好。
o Suppose that BFR-A has been provisioned with BFR-id N for a particular sub-domain but that it has not yet advertised its ownership of BFR-id N for that sub-domain. Suppose also that it has received an advertisement from a different BFR (say BFR-B) that is advertising ownership of BFR-id N for the same sub-domain. In such a case, BFR-A SHOULD log an error and MUST NOT advertise its own ownership of BFR-id N for that sub-domain as long as the advertisement from BFR-B is extant.
o 假设BFR-A已经为特定子域提供了BFR id N，但是它还没有公布其对该子域的BFR id N的所有权。还假设它从不同的BFR（比如BFR-B）接收到广告，该BFR是同一子域的BFR id N的广告所有权。在这种情况下，只要来自BFR-B的公告存在，BFR-a就应该记录一个错误，并且不得为该子域公告其自己的BFR id N的所有权。
This procedure may prevent the accidental misconfiguration of a new BFR from impacting an existing BFR.
该程序可防止新BFR的意外错误配置影响现有BFR。
If a BFR advertises that it has a BFR-id of 0 in a particular sub-domain, other BFRs receiving the advertisement MUST interpret that advertisement as meaning that the advertising BFR does not have a BFR-id in that sub-domain.
如果某个BFR播发其在特定子域中的BFR id为0，则接收该播发的其他BFR必须将该播发解释为该播发BFR在该子域中没有BFR id。
This section specifies the rules for forwarding a BIER-encapsulated data packet within a BIER domain. These rules are not intended to specify an implementation strategy; to conform to this specification, an implementation need only produce the same results that these rules produce.
本节指定在BIER域内转发BIER封装数据包的规则。这些规则并非旨在规定实施策略；为了符合此规范，实现只需要产生与这些规则产生的结果相同的结果。
This section provides a brief overview of the BIER forwarding procedures. Subsequent subsections specify the procedures in more detail.
本节简要概述BIER转发程序。随后的小节更详细地说明了程序。
To forward a BIER-encapsulated packet:
转发BIER封装的数据包：
1. Determine the packet's sub-domain.
1. 确定数据包的子域。
2. Determine the packet's BitStringLength and BitString.
2. 确定数据包的BitStringLength和BitString。
3. Determine the packet's SI.
3. 确定数据包的SI。
4. From the sub-domain, the SI, and the BitString, determine the set of destination BFERs for the packet.
4. 从子域、SI和位字符串确定数据包的目标BFER集。
5. Using information provided by the routing underlay associated with the packet's sub-domain, determine the next-hop adjacency for each of the destination BFERs.
5. 使用与包的子域相关联的路由参考底图提供的信息，确定每个目的地BFER的下一跳邻接。
6. It is possible that the packet's BitString will have one or more bits that correspond to BFR-ids that are not in use. It is also possible that the packet's BitString will have one or more bits that correspond to BFERs that are unreachable, i.e., that have no next-hop adjacency. In the following, we will consider the "next-hop adjacency" for all such bit positions to be the "null" next hop.
6. 数据包的位字符串可能有一个或多个对应于未使用的BFR ID的位。数据包的比特串也可能具有一个或多个对应于不可到达的bfer的比特，即没有下一跳邻接。在下面，我们将考虑所有这些位位置的“下一跳邻接”为“NULL”下一跳。
7. Partition the set of destination BFERs such that all the BFERs in a single partition have the same next hop. We will say that each partition is associated with a next hop.
7. 对目标BFER集进行分区，使单个分区中的所有BFER具有相同的下一跳。我们将说，每个分区都与下一跳相关联。
8. For each partition:
8. 对于每个分区：
a. Make a copy of the packet.
a. 把包复印一份。
b. Clear any bit in the packet's BitString that identifies a BFER that is not in the partition.
b. 清除数据包位字符串中标识不在分区中的BFER的任何位。
c. Transmit the packet to the associated next hop. (If the next hop is the null next hop, the packet is discarded.)
c. 将数据包发送到相关的下一跳。（如果下一跳是空的下一跳，则丢弃数据包。）
If a BFR receives a BIER-encapsulated packet whose <sub-domain, SI, BitString> triple identifies that BFR itself, then the BFR is also a BFER for that packet. As a BFER, it must pass the payload to the multicast flow overlay. If the BitString has bits set for other BFRs, the packet also needs to be forwarded further within the BIER domain. If the BF(E)R also forwards one or more copies of the packet within the BIER domain, the bit representing the BFR's own BFR-id MUST be clear in all the copies.
如果BFR接收到一个BIER封装的数据包，其<sub-domain，SI，BitString>三元组标识该BFR本身，那么BFR也是该数据包的BFER。作为BFER，它必须将有效负载传递给多播流覆盖。如果位字符串为其他BFR设置了位，则数据包也需要在BIER域内进一步转发。如果BF（E）R还转发BIER域内数据包的一个或多个副本，则表示BFR自己的BFR id的位必须在所有副本中清除。
When BIER on a BFER is to pass a packet to the multicast flow overlay, it of course decapsulates the packet by removing the BIER header. However, it may be necessary to provide the multicast flow overlay with contextual information obtained from the BIER encapsulation. The information that needs to pass between the BIER layer and the multicast flow overlay is specific to the multicast flow overlay. Specification of the interaction between the BIER layer and the multicast flow overlay is outside the scope of this specification.
当BFER上的BIER将数据包传递给多播流覆盖时，它当然会通过移除BIER报头来解除数据包的封装。然而，可能需要为多播流覆盖提供从BIER封装获得的上下文信息。需要在BIER层和多播流覆盖之间传递的信息特定于多播流覆盖。BIER层和多播流覆盖之间的交互规范不在本规范的范围内。
If the BIER encapsulation contains a "Time to Live" (TTL) value, this value is not, by default, inherited by the payload. If a particular multicast flow overlay needs to know the TTL value, this needs to be specified in whatever specification defines the interaction between BIER and that multicast flow overlay.
如果BIER封装包含一个“生存时间”（TTL）值，默认情况下，该值不会被有效负载继承。如果特定的多播流覆盖需要知道TTL值，则需要在定义BIER和该多播流覆盖之间交互的任何规范中指定TTL值。
If the BIER encapsulation contains a Traffic Class field, a Type of Service field, a Differentiated Services field, or any field of that sort, the value of that field is not, by default, passed to the multicast flow overlay. If a particular multicast flow overlay needs to know the values of such fields, this fact needs to be specified in whatever specification defines the interaction between BIER and that multicast flow overlay.
如果BIER封装包含流量类字段、服务类型字段、区分服务字段或任何此类字段，默认情况下，该字段的值不会传递给多播流覆盖。如果特定的多播流覆盖需要知道这些字段的值，则需要在定义BIER和该多播流覆盖之间交互的任何规范中指定这一事实。
When BIER on a BFER passes a packet to the multicast flow overlay, the overlay will determine how to further dispatch the packet. If the packet needs to be forwarded into another BIER domain, then the BFR will act as a BFER in one BIER domain and as a BFIR in another.
当BFER上的BIER将数据包传递给多播流覆盖时，覆盖将决定如何进一步调度数据包。如果数据包需要转发到另一个BIER域，那么BFR将在一个BIER域中充当BFER，在另一个BIER域中充当BFIR。
A BIER-encapsulated packet cannot pass directly from one BIER domain to another; at the boundary between BIER domains, the packet must be decapsulated and passed to the multicast flow overlay.
BIER封装的数据包不能直接从一个BIER域传递到另一个BIER域；在BIER域之间的边界处，数据包必须被解封并传递到多播流覆盖。
Note that when a BFR transmits multiple copies of a packet within a BIER domain, only one copy will be destined to any given BFER. Therefore, it is not possible for any BIER-encapsulated packet to be delivered more than once to any BFER.
请注意，当BFR在BIER域内传输数据包的多个副本时，只有一个副本将发送到任何给定的BFER。因此，不可能将任何BIER封装的数据包多次交付给任何BFER。
The "BFR Neighbors" (BFR-NBRs) of a given BFR, say BFR-A, are those BFRs that, according to the routing underlay, are adjacencies of BFR-A. Each BFR-NBR will have a BFR-prefix.
给定BFR（如BFR-a）的“BFR邻居”（BFR NBR）是指根据布线参考底图，是BFR-a邻接的BFR。每个BFR-NBR都有一个BFR前缀。
Suppose a BIER-encapsulated packet arrives at BFR-A. From the packet's encapsulation, BFR-A learns (a) the sub-domain of the packet and (b) the BFR-ids (in that sub-domain) of the BFERs to which the packet is destined. Then, using the information advertised per Section 5, BFR-A can find the BFR-prefix of each destination BFER. Given the BFR-prefix of a particular destination BFER, say BFER-D, BFR-A learns from the routing underlay (associated with the packet's sub-domain) an IP address of the BFR that is the next hop on the path from BFR-A to BFER-D. Let's call this next hop "BFR-B". BFR-A must then determine the BFR-prefix of BFR-B. (This determination can be made from the information advertised per Section 5.) This BFR-prefix is the BFR-NBR of BFR-A on the path from BFR-A to BFER-D.
假设BIER封装的数据包到达BFR-a。通过数据包的封装，BFR-a学习（a）数据包的子域和（b）数据包目的地BFR的BFR ID（在该子域中）。然后，使用根据第5节公布的信息，BFR-A可以找到每个目的地BFER的BFR前缀。给定特定目的地BFER的BFR前缀，例如BFER-D，BFR-a从路由参考底图（与数据包的子域关联）中学习BFR的IP地址，该地址是从BFR-a到BFER-D的路径上的下一个跃点。我们将该下一个跃点称为“BFR-B”。然后，BFR-A必须确定BFR-B的BFR前缀。（此确定可根据第5节公布的信息进行）。此BFR前缀是BFR-A到BFER-D路径上BFR-A的BFR-NBR。
Note that if the routing underlay provides multiple equal-cost paths from BFR-A to BFER-D, BFR-A may have multiple BFR-NBRs for BFER-D.
请注意，如果布线参考底图提供了从BFR-A到BFER-D的多个等成本路径，则BFR-A可能有多个BFR NBR用于BFER-D。
Under certain circumstances, a BFR may have adjacencies (in a particular routing underlay) that are not BFRs. Please see Section 6.9 for a discussion of how to handle those circumstances.
在某些情况下，BFR可能具有非BFR的邻接（在特定布线参考底图中）。有关如何处理这些情况的讨论，请参见第6.9节。
The "Bit Index Routing Table" (BIRT) is a table that maps from the BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix of that BFER, and to the BFR-NBR on the path to that BFER. As an example, consider the topology shown in Figure 1. In this diagram, we represent the BFR-id of each BFR in the SI:xyzw form discussed in Section 3.
“位索引路由表”（BIRT）是一个表，它从BFER的BFR id（在特定子域中）映射到该BFER的BFR前缀，并映射到该BFER路径上的BFR-NBR。作为一个例子，考虑图1所示的拓扑结构。在此图中，我们以第3节中讨论的SI:xyzw形式表示每个BFR的BFR id。
( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
4 (0:1000) \ \ 1 (0:0001)
\ \
( E ) ( F )
3 (0:0100) 2 (0:0010)
( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
4 (0:1000) \ \ 1 (0:0001)
\ \
( E ) ( F )
3 (0:0100) 2 (0:0010)
Figure 1: BIER Topology 1
图1:BIER拓扑1
This topology will result in the BIRT of Figure 2 at BFR-B. The first column shows the BFR-id as a number and also (in parentheses) in the SI:BitString format that corresponds to a BitStringLength of 4. (The actual minimum BitStringLength is 64, but we use 4 in the examples.)
此拓扑将在BFR-B处生成图2的BIRT。第一列以数字形式显示BFR id，并且（在括号中）为SI:BitString格式，对应于BitStringLength 4。（实际最小BitStringLength为64，但我们在示例中使用了4。）
Note that a BIRT is specific to a particular BIER sub-domain.
请注意，BIRT是特定于特定BIER子域的。
--------------------------------------------
| BFR-id | BFR-Prefix | BFR-NBR |
| (SI:BitString) | of Dest BFER | |
============================================
| 4 (0:1000) | A | A |
--------------------------------------------
| 1 (0:0001) | D | C |
--------------------------------------------
| 3 (0:0100) | E | E |
--------------------------------------------
| 2 (0:0010) | F | C |
--------------------------------------------
--------------------------------------------
| BFR-id | BFR-Prefix | BFR-NBR |
| (SI:BitString) | of Dest BFER | |
============================================
| 4 (0:1000) | A | A |
--------------------------------------------
| 1 (0:0001) | D | C |
--------------------------------------------
| 3 (0:0100) | E | E |
--------------------------------------------
| 2 (0:0010) | F | C |
--------------------------------------------
Figure 2: Bit Index Routing Table at BFR-B
图2:BFR-B的位索引路由表
The "Bit Index Forwarding Table" (BIFT) is derived from the BIRT as follows. (Note that a BIFT is specific to a particular sub-domain.)
“比特索引转发表”（BIFT）由BIRT派生而来，如下所示。（请注意，BIFT特定于特定子域。）
Suppose that several rows in the BIRT have the same SI and the same BFR-NBR. By taking the logical OR of the BitStrings of those rows, we obtain a bit mask that corresponds to that combination of SI and BFR-NBR. We will refer to this bit mask as the "Forwarding Bit Mask" (F-BM) for that <SI, BFR-NBR> combination.
假设BIRT中的几行具有相同的SI和相同的BFR-NBR。通过获取这些行的位字符串的逻辑OR，我们获得了对应于SI和BFR-NBR组合的位掩码。对于<SI，BFR-NBR>组合，我们将此位掩码称为“转发位掩码”（F-BM）。
For example, in Figure 2, we see that two of the rows have the same SI (0) and same BFR-NBR (C). The bit mask that corresponds to <SI=0, BFR-NBR-C> is 0011 ("0001" OR'd with "0010").
例如，在图2中，我们看到其中两行具有相同的SI（0）和相同的BFR-NBR（C）。与<SI=0，BFR-NBR-C>相对应的位掩码为0011（“0001”或“0010”）。
The BIFT is used to map from the BFR-id of a BFER to the corresponding F-BM and BFR-NBR. For example, Figure 3 shows the BIFT that is derived from the BIRT of Figure 2. Note that BFR-ids 1 and 2 have the same SI and the same BFR-NBR; hence, they have the same F-BM.
BIFT用于从BFER的BFR id映射到相应的F-BM和BFR-NBR。例如，图3显示了从图2的BIRT导出的BIFT。请注意，BFR ID 1和2具有相同的SI和BFR-NBR；因此，它们具有相同的F-BM。
-------------------------------------
| BFR-id | F-BM | BFR-NBR |
| (SI:BitString) | | |
=====================================
| 1 (0:0001) | 0011 | C |
-------------------------------------
| 2 (0:0010) | 0011 | C |
-------------------------------------
| 3 (0:0100) | 0100 | E |
-------------------------------------
| 4 (0:1000) | 1000 | A |
-------------------------------------
-------------------------------------
| BFR-id | F-BM | BFR-NBR |
| (SI:BitString) | | |
=====================================
| 1 (0:0001) | 0011 | C |
-------------------------------------
| 2 (0:0010) | 0011 | C |
-------------------------------------
| 3 (0:0100) | 0100 | E |
-------------------------------------
| 4 (0:1000) | 1000 | A |
-------------------------------------
Figure 3: Bit Index Forwarding Table
图3：位索引转发表
This BIFT is programmed into the data plane and used to forward packets, applying the rules specified below in Section 6.5.
该BIFT被编程到数据平面中，并用于转发数据包，应用第6.5节中规定的规则。
Below is the procedure that a BFR uses for forwarding a BIER-encapsulated packet.
以下是BFR用于转发BIER封装数据包的过程。
1. Determine the packet's SI, BitStringLength, and sub-domain.
1. 确定数据包的SI、BitStringLength和子域。
2. If the BitString consists entirely of zeroes, discard the packet; the forwarding process has been completed. Otherwise, proceed to step 3.
2. 如果位字符串完全由零组成，则丢弃该数据包；转发过程已完成。否则，继续执行步骤3。
3. Find the position (call it "k") of the least significant (i.e., of the rightmost) bit that is set in the packet's BitString. (Remember, bits are numbered from 1, starting with the least significant bit.)
3. 查找数据包位字符串中设置的最低有效位（即最右边的）的位置（称为“k”）。（请记住，位从1开始编号，从最低有效位开始。）
4. If bit k identifies the BFR itself, copy the packet, and send the copy to the multicast flow overlay. Then clear bit k in the original packet, and go to step 2. Otherwise, proceed to step 5.
4. 如果位k标识BFR本身，则复制数据包，并将副本发送到多播流覆盖。然后清除原始数据包中的位k，并转至步骤2。否则，转至步骤5。
5. Use the value k, together with the SI, sub-domain, and BitStringLength, as the "index" into the BIFT.
5. 使用值k以及SI、子域和BitStringLength作为BIFT的“索引”。
6. Extract from the BIFT the F-BM and the BFR-NBR.
6. 从BIFT中提取F-BM和BFR-NBR。
7. Copy the packet. Update the copy's BitString by AND'ing it with the F-BM (i.e., PacketCopy->BitString &= F-BM). Then forward the copy to the BFR-NBR. (If the BFR-NBR is null, the copy is just discarded.) Note that when a packet is forwarded to a particular BFR-NBR, its BitString identifies only those BFERs that are to be reached via that BFR-NBR.
7. 复制数据包。通过使用F-BM（即PacketCopy->BitString&=F-BM）和“ing”更新副本的位字符串。然后将副本转发给BFR-NBR。（如果BFR-NBR为空，则仅丢弃副本。）请注意，当数据包转发到特定BFR-NBR时，其位字符串仅标识将通过该BFR-NBR到达的BFER。
8. Now update the original packet's BitString by AND'ing it with the INVERSE of the F-BM (i.e., Packet->BitString &= ~F-BM). (This clears the bits that identify the BFERs to which a copy of the packet has just been forwarded.) Go to step 2.
8. 现在更新原始数据包的位字符串，方法是使用F-BM的倒数（即数据包->位字符串&=~F-BM）对其进行加和运算。（这将清除标识数据包副本刚刚转发到的BFER的位。）转至步骤2。
This procedure causes the packet to be forwarded to a particular BFR-NBR only once. The number of lookups in the BIFT is the same as the number of BFR-NBRs to which the packet must be forwarded; it is not necessary to do a separate lookup for each destination BFER.
此过程导致数据包仅转发到特定BFR-NBR一次。BIFT中的查找数与包必须转发到的BFR NBR数相同；没有必要对每个目标BFER进行单独的查找。
When a packet is sent to a particular BFR-NBR, the BitString is not the only part of the BIER header that needs to be modified. If there is a TTL field in the BIER header, it will need to be decremented. In addition, when either of the encapsulations of [MPLS_BIER_ENCAPS] is used, the BIFT-id field is likely to require modification, based on signaling from the BFR-NBR to which the packet is being sent. The
当数据包被发送到特定的BFR-NBR时，BIER报头中需要修改的不仅仅是位字符串。如果BIER标头中有TTL字段，则需要对其进行递减。此外，当使用[MPLS_BIER_ENCAPS]的任一封装时，基于来自分组正被发送到的BFR-NBR的信令，可能需要修改BIFT id字段。这个
BIFT-id field of an incoming BIER packet implicitly identifies an SI, a sub-domain, and a BitStringLength. If the packet is sent to a particular BFR-NBR, the BIFT-id field must be changed to whatever value that BFR-NBR has advertised for the same SI, sub-domain, and BitStringLength. (If the encapsulation of Section 2.1 of [MPLS_BIER_ENCAPS] is used, this is essentially an MPLS label swap operation.)
传入BIER数据包的BIFT id字段隐式标识SI、子域和BitStringLength。如果数据包被发送到特定的BFR-NBR，则BIFT id字段必须更改为BFR-NBR为相同的SI、子域和BitStringLength播发的任何值。（如果使用[MPLS_BIER_ENCAPS]第2.1节的封装，则这本质上是一个MPLS标签交换操作。）
Suppose it has been decided (by the above rules) to send a packet to a particular BFR-NBR. If that BFR-NBR is connected via multiple parallel interfaces, it may be desirable to apply some form of load balancing. Load-balancing algorithms are outside the scope of this document. However, if the packet's encapsulation contains an entropy field, the entropy field SHOULD be respected; two packets with the same value of the entropy field SHOULD be sent on the same interface (if possible).
假设已决定（根据上述规则）向特定BFR-NBR发送数据包。如果BFR-NBR通过多个并行接口连接，则可能需要应用某种形式的负载平衡。负载平衡算法不在本文档的范围内。然而，如果包的封装包含熵场，则应考虑熵场；应在同一接口上发送熵字段值相同的两个数据包（如果可能）。
In some cases, the routing underlay may provide multiple equal-cost paths (through different BFR-NBRs) to a given BFER. This is known as "Equal-Cost Multipath" (ECMP). The procedures described in this section must be augmented in order to support load balancing over ECMP. The necessary augmentations can be found in Section 6.7.
在某些情况下，布线参考底图可能会向给定BFER提供多条等成本路径（通过不同的BFR NBR）。这被称为“等成本多路径”（ECMP）。为了支持ECMP上的负载平衡，必须扩充本节中描述的过程。第6.7节中提供了必要的补充。
In the event that unicast traffic to the BFR-NBR is being sent via a "bypass tunnel" of some sort, the BIER-encapsulated multicast traffic sent to the BFR-NBR SHOULD also be sent via that tunnel. This allows any existing "fast reroute" schemes to be applied to multicast traffic as well as to unicast traffic.
如果通过某种“旁路隧道”发送到BFR-NBR的单播通信量，则发送到BFR-NBR的BIER封装多播通信量也应通过该隧道发送。这允许将任何现有的“快速重路由”方案应用于多播流量以及单播流量。
Some examples of these forwarding procedures can be found in Section 6.6.
有关这些转发程序的一些示例，请参见第6.6节。
The rules given in this section can be represented by the following pseudocode:
本节中给出的规则可以用以下伪代码表示：
void ForwardBitMaskPacket (Packet)
{
SI=GetPacketSI(Packet);
Offset=SI*BitStringLength;
for (Index = GetFirstBitPosition(Packet->BitString); Index ;
Index = GetNextBitPosition(Packet->BitString, Index)) {
F-BM = BIFT[Index+Offset]->F-BM;
if (!F-BM) continue;
BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
PacketCopy = Copy(Packet);
PacketCopy->BitString &= F-BM;
PacketSend(PacketCopy, BFR-NBR);
Packet->BitString &= ~F-BM;
}
}
void ForwardBitMaskPacket (Packet)
{
SI=GetPacketSI(Packet);
Offset=SI*BitStringLength;
for (Index = GetFirstBitPosition(Packet->BitString); Index ;
Index = GetNextBitPosition(Packet->BitString, Index)) {
F-BM = BIFT[Index+Offset]->F-BM;
if (!F-BM) continue;
BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
PacketCopy = Copy(Packet);
PacketCopy->BitString &= F-BM;
PacketSend(PacketCopy, BFR-NBR);
Packet->BitString &= ~F-BM;
}
}
Figure 4: Pseudocode
图4：伪代码
This pseudocode assumes that, at a given BFER, the BFR-NBR entry corresponding to the BFER's own BFR-id will be the BFER's own BFR-prefix. It also assumes that the corresponding F-BM has only one bit set, the bit representing the BFER itself. In this case, the "PacketSend" function sends the packet to the multicast flow overlay.
此伪代码假定，在给定的BFER中，与BFER自己的BFR id对应的BFR-NBR条目将是BFER自己的BFR前缀。它还假设对应的F-BM只有一个位集，该位表示BFER本身。在这种情况下，“PacketSend”函数将数据包发送到多播流覆盖。
This pseudocode also assumes that the F-BM for the null next hop contains a 1 in a given bit position if and only if that bit position corresponds to either an unused BFR-id or an unreachable BFER. When the BFR-NBR is null, the "PacketSend" function discards the packet.
该伪码还假设空下一跳的F-BM在给定位位置包含1，当且仅当该位位置对应于未使用的BFR id或不可访问的BFER时。当BFR-NBR为空时，“PacketSend”函数丢弃该数据包。
In this section, we give two examples of BIER forwarding, based on the topology in Figure 1. In these examples, all packets have been assigned to the default sub-domain, all packets have SI=0, and the BitStringLength is 4. Figure 5 shows the BIFT entries for SI=0 only. For compactness, we show the first column of the BIFT, the BFR-id, only as an integer.
在本节中，我们将根据图1中的拓扑结构给出两个BIER转发示例。在这些示例中，所有数据包都已分配给默认子域，所有数据包的SI=0，BitStringLength为4。图5仅显示了SI=0的BIFT条目。对于紧凑性，我们只将BIFT的第一列BFR id显示为一个整数。
BFR-A BIFT BFR-B BIFT BFR-C BIFT
------------------- ------------------- -------------------
| Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR |
=================== =================== ===================
| 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D |
------------------- ------------------- -------------------
| 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F |
------------------- ------------------- -------------------
| 3 | 0111 | B | | 3 | 0100 | E | | 3 | 1100 | B |
------------------- ------------------- -------------------
| 4 | 1000 | A | | 4 | 1000 | A | | 4 | 1100 | B |
------------------- ------------------- -------------------
BFR-A BIFT BFR-B BIFT BFR-C BIFT
------------------- ------------------- -------------------
| Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR |
=================== =================== ===================
| 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D |
------------------- ------------------- -------------------
| 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F |
------------------- ------------------- -------------------
| 3 | 0111 | B | | 3 | 0100 | E | | 3 | 1100 | B |
------------------- ------------------- -------------------
| 4 | 1000 | A | | 4 | 1000 | A | | 4 | 1100 | B |
------------------- ------------------- -------------------
Figure 5: BIFTs Used in the Forwarding Examples
图5：转发示例中使用的BIFT
BFR-D, BFR-E, and BFR-F are BFERs. BFR-A is the BFIR. Suppose that BFIR-A has learned from the multicast flow overlay that BFER-D is interested in a given multicast flow. If BFIR-A receives a packet of that flow from outside the BIER domain, BFIR-A applies the BIER encapsulation to the packet. The encapsulation must be such that the SI is zero. The encapsulation also includes a BitString, with just bit 1 set and with all other bits clear (i.e., 0001). This indicates that BFER-D is the only BFER that needs to receive the packet. BFIR-A then follows the procedures of Section 6.5, as follows:
BFR-D、BFR-E和BFR-F是BFER。BFR-A是BFIR。假设BFIR-A从多播流覆盖中得知BFER-D对给定的多播流感兴趣。如果BFIR-A从BIER域外部接收到该流的数据包，则BFIR-A将BIER封装应用于该数据包。封装必须确保SI为零。封装还包括一个位字符串，只设置了位1，所有其他位都清除（即0001）。这表明BFER-D是唯一需要接收数据包的BFER。BFIR-A随后遵循第6.5节的程序，如下所示：
o Since the packet's BitString is 0001, BFIR-A finds that the first bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-A determines that the bit mask F-BM is 0111 and the BFR-NBR is BFR-B.
o 由于数据包的位字符串是0001，BFIR-A发现字符串中的第一位是位1。查看其BIFT中的条目1，BFR-A确定位掩码F-BM为0111，BFR-NBR为BFR-B。
o BFR-A then makes a copy of the packet and applies the F-BM to the copy: Copy->BitString &= 0111. The copy's BitString is now 0001 (0001 & 0111).
o 然后，BFR-A复制数据包并将F-BM应用于副本：copy->BitString&=0111。副本的位字符串现在为0001（0001和0111）。
o The copy is now sent to BFR-B.
o 副本现在发送给BFR-B。
o BFR-A then updates the packet's BitString by applying the inverse of the F-BM: Packet->BitString &= ~F-BM. As a result, the packet's BitString is now 0000 (0001 & 1000).
o 然后，BFR-A通过应用F-BM的倒数来更新数据包的位字符串：packet->BitString&=~F-BM。因此，数据包的位字符串现在是0000（0001&1000）。
o As the packet's BitString is now zero, the forwarding procedure is complete.
o 由于数据包的位字符串现在为零，因此转发过程已完成。
When BFR-B receives the multicast packet from BFR-A, it follows the same procedure. The result is that a copy of the packet, with a BitString of 0001, is sent to BFR-C. BFR-C applies the same procedures and, as a result, sends a copy of the packet, with a BitString of 0001, to BFR-D.
当BFR-B从BFR-A接收多播数据包时，它遵循相同的过程。结果是，比特串为0001的数据包副本被发送到BFR-C。BFR-C应用相同的过程，并因此向BFR-D发送比特串为0001的数据包副本。
At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an F-BM of 0001 and a BFR-NBR of BFR-D itself. This will cause a copy of the packet to be delivered to the multicast flow overlay at BFR-D. The packet's BitString will be set to 0000, and the packet will not be forwarded any further.
在BFR-D，BFR id 1的BIFT条目（未图示）将指定F-BM为0001，BFR-NBR为BFR-D本身。这将导致将数据包的副本发送到BFR-D的多播流覆盖。数据包的位字符串将设置为0000，数据包将不再转发。
This example is similar to example 1, except that BFIR-A has learned from the multicast flow overlay that both BFER-D and BFER-E are interested in a given multicast flow. If BFIR-A receives a packet of that flow from outside the BIER domain, BFIR-A applies the BIER encapsulation to the packet. The encapsulation must be such that the SI is zero. The encapsulation also includes a BitString with two bits set: bit 1 is set (as in example 1) to indicate that BFR-D is a BFER for this packet, and bit 3 is set to indicate that BFR-E is a BFER for this packet. That is, the BitString (assuming again a BitStringLength of 4) is 0101. To forward the packet, BFIR-A follows the procedures of Section 6.5, as follows:
该示例与示例1类似，只是BFIR-A从多播流覆盖中了解到BFER-D和BFER-E都对给定的多播流感兴趣。如果BFIR-A从BIER域外部接收到该流的数据包，则BFIR-A将BIER封装应用于该数据包。封装必须确保SI为零。封装还包括设置了两个位的位字符串：设置位1（如示例1中所示）以指示BFR-D是该分组的BFER，设置位3以指示BFR-E是该分组的BFER。也就是说，位字符串（再次假设BitStringLength为4）为0101。为了转发数据包，BFIR-A遵循第6.5节的程序，如下所示：
o Since the packet's BitString is 0101, BFIR-A finds that the first bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-A determines that the bit mask F-BM is 0111 and the BFR-NBR is BFR-B.
o 由于数据包的位字符串是0101，BFIR-A发现字符串中的第一位是位1。查看其BIFT中的条目1，BFR-A确定位掩码F-BM为0111，BFR-NBR为BFR-B。
o BFR-A then makes a copy of the packet and applies the F-BM to the copy: Copy->BitString &= 0111. The copy's BitString is now 0101 (0101 & 0111).
o 然后，BFR-A复制数据包并将F-BM应用于副本：copy->BitString&=0111。副本的位字符串现在是0101（0101&0111）。
o The copy is now sent to BFR-B.
o 副本现在发送给BFR-B。
o BFR-A then updates the packet's BitString by applying the inverse of the F-BM: Packet->BitString &= ~F-BM. As a result, the packet's BitString is now 0000 (0101 & 1000).
o 然后，BFR-A通过应用F-BM的倒数来更新数据包的位字符串：packet->BitString&=~F-BM。因此，数据包的位字符串现在是0000（0101&1000）。
o As the packet's BitString is now zero, the forwarding procedure is complete.
o 由于数据包的位字符串现在为零，因此转发过程已完成。
When BFR-B receives the multicast packet from BFR-A, it follows the procedure of Section 6.5, as follows:
当BFR-B收到来自BFR-A的多播数据包时，它遵循第6.5节的程序，如下所示：
o Since the packet's BitString is 0101, BFR-B finds that the first bit in the string is bit 1. Looking at entry 1 in its BIFT, BFR-B determines that the bit mask F-BM is 0011 and the BFR-NBR is BFR-C.
o 由于数据包的位字符串是0101，BFR-B发现字符串中的第一位是位1。查看其BIFT中的条目1，BFR-B确定位掩码F-BM为0011，BFR-NBR为BFR-C。
o BFR-B then makes a copy of the packet and applies the F-BM to the copy: Copy->BitString &= 0011. The copy's BitString is now 0001 (0101 & 0011).
o 然后，BFR-B复制数据包并将F-BM应用于副本：copy->BitString&=0011。副本的位字符串现在为0001（0101和0011）。
o The copy is now sent to BFR-C.
o 副本现在发送给BFR-C。
o BFR-B then updates the packet's BitString by applying the inverse of the F-BM: Packet->BitString &= ~F-BM. As a result, the packet's BitString is now 0100 (0101 & 1100).
o 然后，BFR-B通过应用F-BM的倒数来更新数据包的位字符串：packet->BitString&=~F-BM。因此，数据包的位字符串现在是0100（0101&1100）。
o Now BFR-B finds the next bit in the packet's (modified) BitString. This is bit 3. Looking at entry 3 in its BIFT, BFR-B determines that the F-BM is 0100 and the BFR-NBR is BFR-E.
o 现在BFR-B在数据包的（修改的）位字符串中找到下一位。这是第三位。查看其BIFT中的条目3，BFR-B确定F-BM为0100，BFR-NBR为BFR-E。
o BFR-B then makes a copy of the packet and applies the F-BM to the copy: Copy->BitString &= 0100. The copy's BitString is now 0100 (0100 & 0100).
o 然后，BFR-B复制数据包并将F-BM应用于副本：copy->BitString&=0100。副本的位字符串现在是0100（0100&0100）。
o The copy is now sent to BFR-E.
o 副本现在发送给BFR-E。
o BFR-B then updates the packet's BitString by applying the inverse of the F-BM: Packet->BitString &= ~F-BM. As a result, the packet's BitString is now 0000 (0100 & 1011).
o 然后，BFR-B通过应用F-BM的倒数来更新数据包的位字符串：packet->BitString&=~F-BM。因此，数据包的位字符串现在是0000（0100&1011）。
o As the packet's BitString is now zero, the forwarding procedure is complete.
o 由于数据包的位字符串现在为零，因此转发过程已完成。
Thus, BFR-B forwards two copies of the packet. One copy of the packet, with BitString 0001, has now been sent from BFR-B to BFR-C. Following the same procedures, BFR-C will forward the packet to BFER-D.
因此，BFR-B转发包的两个副本。数据包的一个副本（位字符串0001）现在已从BFR-B发送到BFR-C。按照相同的步骤，BFR-C将数据包转发到BFER-D。
At BFER-D, the BIFT entry (not pictured) for BFR-id 1 will specify an F-BM of 0001 and a BFR-NBR of BFR-D itself. This will cause a copy of the packet to be delivered to the multicast flow overlay at BFR-D. The packet's BitString will be set to 0000, and the packet will not be forwarded any further.
在BFR-D，BFR id 1的BIFT条目（未图示）将指定F-BM为0001，BFR-NBR为BFR-D本身。这将导致将数据包的副本发送到BFR-D的多播流覆盖。数据包的位字符串将设置为0000，数据包将不再转发。
The other copy of the packet has been sent from BFR-B to BFER-E, with BitString 0100.
数据包的另一个副本已从BFR-B发送到BFER-E，位字符串为0100。
At BFER-E, the BIFT entry (not pictured) for BFR-id 3 will specify an F-BM of 0100 and a BFR-NBR of BFR-E itself. This will cause a copy of the packet to be delivered to the multicast flow overlay at BFR-E. The packet's BitString will be set to 0000, and the packet will not be forwarded any further.
在BFR-E，BFR id 3的BIFT条目（未显示）将指定0100的F-BM和BFR-E本身的BFR-NBR。这将导致在BFR-E向多播流覆盖层发送数据包副本。数据包的位字符串将设置为0000，数据包将不再转发。
In many networks, the routing underlay will provide multiple equal-cost paths from a given BFR to a given BFER. When forwarding multicast packets through the network, it can be beneficial to take advantage of this by load-balancing among those paths. This feature is known as "Equal-Cost Multipath (ECMP) forwarding".
在许多网络中，路由参考底图将提供从给定BFR到给定BFER的多条等成本路径。当通过网络转发多播数据包时，通过这些路径之间的负载平衡来利用这一点是有益的。此功能称为“等成本多路径（ECMP）转发”。
BIER supports ECMP forwarding, but the procedures of Section 6.5 must be modified slightly. Two ECMP procedures are defined. In the first (described in Section 6.7.1), the choice among equal-cost paths taken by a given packet from a given BFR to a given BFER depends on (a) routing, (b) the packet's entropy, and (c) the other BFERs to which that packet is destined. In the second (described in Section 6.7.2), the choice depends only upon the packet's entropy.
BIER支持ECMP转发，但第6.5节的程序必须稍加修改。定义了两个ECMP程序。在第一种情况下（如第6.7.1节所述），给定数据包从给定BFR到给定BFER的等成本路径的选择取决于（a）路由，（b）数据包的熵，以及（c）该数据包目的地的其他BFER。在第二种情况下（如第6.7.2节所述），选择仅取决于数据包的熵。
There are trade-offs between the two forwarding procedures described here. In the procedure of Section 6.7.1, the number of packet replications is minimized. The procedure in Section 6.7.1 also uses less memory in the BFR. In the procedure of Section 6.7.2, the path traveled by a given packet from a given BFR to a given BFER is independent of the other BFERs to which the packet is destined. While the procedures of Section 6.7.2 may cause more replications, they provide a more predictable behavior.
这里描述的两种转发程序之间存在权衡。在第6.7.1节的程序中，数据包复制的数量最小化。第6.7.1节中的程序在BFR中使用的内存也较少。在第6.7.2节的程序中，给定数据包从给定BFR到给定BFER的路径独立于数据包目的地的其他BFER。虽然第6.7.2节中的程序可能会导致更多的复制，但它们提供了更可预测的行为。
The two procedures described here operate on identical packet formats and will interoperate correctly. However, if deterministic behavior is desired, then all BFRs would need to use the procedure from Section 6.7.2.
这里描述的两个过程在相同的数据包格式上运行，并且可以正确地进行互操作。但是，如果需要确定性行为，则所有BFR都需要使用第6.7.2节中的程序。
Figure 6 shows the operation of non-deterministic ECMP in BIER.
图6显示了BIER中非确定性ECMP的操作。
BFR-A BIFT BFR-B BIFT BFR-C BIFT
------------------- ------------------- -------------------
| Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR |
=================== =================== ===================
| 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D |
------------------- ------------------- -------------------
| 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F |
------------------- | | 0110 | E | -------------------
| 3 | 0111 | B | ------------------- | 3 | 1100 | B |
------------------- | 3 | 0110 | E | -------------------
| 4 | 1000 | A | ------------------| | 4 | 1100 | B |
------------------- | 4 | 1000 | A | -------------------
-------------------
BFR-A BIFT BFR-B BIFT BFR-C BIFT
------------------- ------------------- -------------------
| Id | F-BM | NBR | | Id | F-BM | NBR | | Id | F-BM | NBR |
=================== =================== ===================
| 1 | 0111 | B | | 1 | 0011 | C | | 1 | 0001 | D |
------------------- ------------------- -------------------
| 2 | 0111 | B | | 2 | 0011 | C | | 2 | 0010 | F |
------------------- | | 0110 | E | -------------------
| 3 | 0111 | B | ------------------- | 3 | 1100 | B |
------------------- | 3 | 0110 | E | -------------------
| 4 | 1000 | A | ------------------| | 4 | 1100 | B |
------------------- | 4 | 1000 | A | -------------------
-------------------
( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
4 (0:1000) \ \ 1 (0:0001)
\ \
( E ) ------------ ( F )
3 (0:0100) 2 (0:0010)
( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
4 (0:1000) \ \ 1 (0:0001)
\ \
( E ) ------------ ( F )
3 (0:0100) 2 (0:0010)
Figure 6: Example of Non-deterministic ECMP
图6：非确定性ECMP示例
In this example, BFR-B has two equal-cost paths to reach BFER-F: one via BFR-C and one via BFR-E. Since the BFR-id of BFER-F is 2, this is reflected in entry 2 of BFR-B's BIFT. Entry 2 shows that BFR-B has a choice of two BFR-NBRs for BFER-B and that a different F-BM is associated with each choice. When BFR-B looks up entry 2 in the BIFT, it can choose either BFR-NBR. However, when following the procedures of Section 6.5, it MUST use the F-BM corresponding to the BFR-NBR that it chooses.
在本例中，BFR-B有两条到达BFR-F的相同成本路径：一条通过BFR-C，另一条通过BFR-E。由于BFR-F的BFR id为2，这反映在BFR-B的BIFT的条目2中。条目2显示，BFR-B可为BFR-B选择两个BFR NBR，并且不同的F-BM与每个选择相关联。当BFR-B在BIFT中查找条目2时，它可以选择BFR-NBR。但是，当遵循第6.5节的程序时，必须使用与其选择的BFR-NBR相对应的F-BM。
How the choice is made is an implementation matter. However, the usual rules for ECMP apply: packets of a given flow SHOULD NOT be split among two paths, and any entropy field in the packet's encapsulation SHOULD be respected.
如何作出选择是一个实施问题。然而，ECMP的通常规则适用：给定流的数据包不应在两条路径之间分割，并且应遵守数据包封装中的任何熵字段。
Note, however, that by the rules of Section 6.5, any packet destined for both BFER-D and BFER-F will be sent via BFR-C.
但是，请注意，根据第6.5节的规则，发送给BFER-D和BFER-F的任何数据包都将通过BFR-C发送。
With the procedures of Section 6.7.1, where ECMP paths exist, the path a packet takes to reach any particular BFER depends not only on routing and on the packet's entropy but also on the set of other BFERs to which the packet is destined.
根据第6.7.1节的程序，如果存在ECMP路径，则数据包到达任何特定BFER的路径不仅取决于路由和数据包的熵，还取决于数据包目的地的其他BFER集。
For example, consider the following scenario in the network of Figure 6.
例如，在图6的网络中考虑下面的场景。
o There is a sequence of packets being transmitted by BFR-A, some of which are destined for both D and F and some of which are destined only for F.
o BFR-a正在传输一系列数据包，其中一些数据包的目的地为D和F，另一些数据包的目的地仅为F。
o All the packets in this sequence have the same entropy value (call it "Q").
o 这个序列中的所有数据包都具有相同的熵值（称之为“Q”）。
o At BFR-B, when a packet with entropy value Q is forwarded via entry 2 in the BIFT, the packet is sent to E.
o 在BFR-B，当通过BIFT中的条目2转发具有熵值Q的分组时，该分组被发送到E。
Using the forwarding procedure of Section 6.7.1, packets of this sequence that are destined for both D and F are forwarded according to entry 1 in the BIFT and thus will reach F via the path A-B-C-F. However, packets of this sequence that are destined only for F are forwarded according to entry 2 in the BIFT and thus will reach F via the path A-B-E-F.
使用第6.7.1节中的转发程序，根据BIFT中的条目1转发发送给D和F的该序列数据包，从而通过路径A-B-C-F到达F。但是，根据BIFT中的条目2转发仅目的地为F的该序列的分组，因此将经由路径A-B-E-F到达F。
That procedure minimizes the number of packets transmitted by BFR-B. However, consider the following scenario:
该过程最小化BFR-B发送的数据包的数目。然而，考虑下面的场景：
o Beginning at time t0, the multicast flow in question needs to be received ONLY by BFER-F.
o 从时间t0开始，所讨论的多播流需要仅由BFER-F接收。
o Beginning at a later time, t1, the flow needs to be received by both BFER-D and BFER-F.
o 从稍后的时间t1开始，BFER-D和BFER-F都需要接收流。
o Beginning at a later time, t2, the flow no longer needs to be received by D, but still needs to be received by F.
o 从稍后的时间t2开始，流不再需要由D接收，但仍然需要由F接收。
Then, from t0 until t1, the flow will travel to F via the path A-B-E-F. From t1 until t2, the flow will travel to F via the path A-B-C-F. And from t2, the flow will again travel to F via the path A-B-E-F.
然后，从t0到t1，流量将通过路径A-B-E-F流向F。从t1到t2，流量将通过路径A-B-C-F流向F。从t2，流量将再次通过路径A-B-E-F流向F。
The problem is that if D repeatedly joins and leaves the flow, the flow's path from B to F will keep switching. This could cause F to receive packets out of order. It also makes troubleshooting difficult. For example, if there is some problem on the E-F link,
问题是，如果D重复加入并离开流，流从B到F的路径将继续切换。这可能会导致F接收到无序的数据包。这也使得故障排除变得困难。例如，如果E-F链路出现问题，
receivers at F will get good service when the flow is also going to D (avoiding the E-F link) but bad service when the flow is not going to D. Since it is hard to know which path is being used at any given time, this may be hard to troubleshoot. Also, it is very difficult to perform a traceroute that is known to follow the path taken by the flow at any given time.
F处的接收器在流也将进入D（避免E-F链路）时将获得良好服务，但在流不进入D时将获得不良服务。由于在任何给定时间都很难知道正在使用哪条路径，因此可能很难进行故障排除。此外，执行已知在任何给定时间跟随流所走路径的跟踪路由也是非常困难的。
The source of this difficulty is that, in the procedures of Section 6.7.1, the path taken by a particular flow to a particular BFER depends upon whether there are lower-numbered BFERs that are also receiving the flow. Thus, the choice among the ECMP paths is fundamentally non-deterministic.
这种困难的根源在于，在第6.7.1节的程序中，特定流量到特定BFER的路径取决于是否有编号较低的BFER也在接收流量。因此，ECMP路径之间的选择基本上是不确定的。
Deterministic forwarding can be achieved by using multiple BIFTs, such that each row in a BIFT has only one path to each destination but the multiple ECMP paths to any particular destination are spread across the multiple tables. When a BIER-encapsulated packet arrives to be forwarded, the BFR uses a hash of the BIER entropy field to determine which BIFT to use, and then the normal BIER forwarding algorithm (as described in Sections 6.5 and 6.6) is used with the selected BIFT.
通过使用多个BIFT可以实现确定性转发，使得BIFT中的每一行只有一条到每个目的地的路径，但是到任何特定目的地的多条ECMP路径分布在多个表中。当BIER封装的数据包到达要转发时，BFR使用BIER熵字段的散列来确定要使用哪个BIFT，然后将正常BIER转发算法（如第6.5节和第6.6节所述）用于所选BIFT。
As an example, suppose there are two paths to destination X (call them "X1" and "X2") and four paths to destination Y (call them "Y1", "Y2", "Y3", and "Y4"). If there are, say, four BIFTs, one BIFT would have paths X1 and Y1, one would have X1 and Y2, one would have X2 and Y3, and one would have X2 and Y4. If traffic to X is split evenly among these four BIFTs, the traffic will be split evenly between the two paths to X; if traffic to Y is split evenly among these four BIFTs, the traffic will be split evenly between the four paths to Y.
例如，假设有两条到目的地X的路径（称为“X1”和“X2”）和四条到目的地Y的路径（称为“Y1”、“Y2”、“Y3”和“Y4”）。例如，如果有四个BIFT，一个BIFT将有路径X1和Y1，一个BIFT将有路径X1和Y2，一个BIFT将有路径X2和Y3，一个BIFT将有路径X2和Y4。如果到X的流量在这四个BIFT之间平均分配，则该流量将在到X的两条路径之间平均分配；如果到Y的流量在这四个BIFT之间平均分配，则该流量将在到Y的四条路径之间平均分配。
Note that if there are three paths to one destination and four paths to another, 12 BIFTs would be required in order to get even splitting of the load to each of those two destinations. Of course, each BIFT uses some memory, and one might be willing to have less optimal splitting in order to have fewer BIFTs. How that trade-off is made is an implementation or deployment decision.
请注意，如果有三条路径到一个目的地，四条路径到另一个目的地，则需要12个BIFT，以便将负载均匀地分配到这两个目的地中的每一个。当然，每一个BIFT都会使用一些内存，为了获得更少的BIFT，人们可能愿意使用更少的最优分割。如何权衡是一个实现或部署决策。
The BitString in a BIER-encapsulated packet specifies the set of BFERs to which that packet is to be forwarded. When a BIER-encapsulated packet is replicated, no two copies of the packet will ever have a BFER in common. If one of the packet's BFERs forwards the packet further, that BFER will first clear the bit that identifies itself. As a result, duplicate delivery of packets is not possible with BIER.
BIER封装数据包中的位字符串指定该数据包要转发到的BFER集。当BIER封装的数据包被复制时，数据包的任何两个副本都不会有一个相同的BFER。如果数据包的某个BFER进一步转发数据包，该BFER将首先清除标识自身的位。因此，BIER不可能重复交付数据包。
As long as the routing underlay provides a loop-free path between each pair of BFRs, BIER-encapsulated packets will not loop. Since the BIER layer does not create any paths of its own, there is no need for any BIER-specific loop-prevention techniques beyond the forwarding procedures specified in Section 6.5.
只要路由参考底图在每对BFR之间提供无环路路径，BIER封装的数据包就不会环路。由于BIER层不创建自己的任何路径，因此除了第6.5节规定的转发程序外，不需要任何BIER特定的环路预防技术。
If, at some time, the routing underlay is not providing a loop-free path between BFIR-A and BFER-B, then BIER-encapsulated packets may loop while traveling from BFIR-A to BFER-B. However, such loops will never result in delivery of duplicate packets to BFER-B.
如果在某个时间，路由参考底图未提供BFIR-a和BFER-B之间的无环路路径，则BIER封装的数据包可能在从BFIR-a到BFER-B之间循环。但是，此类循环将永远不会导致向BFER-B发送重复数据包。
These properties of BIER eliminate the need for the "Reverse Path Forwarding" (RPF) check that is used in conventional IP multicast forwarding.
BIER的这些特性消除了传统IP多播转发中使用的“反向路径转发”（RPF）检查的需要。
The procedures of Section 6.2 presuppose that, within a given BIER domain, all the nodes adjacent to a given BFR in a given routing underlay are also BFRs. However, it is possible to use BIER even when this is not the case, as long as the ingress and egress nodes are BFRs. In this section, we describe procedures that can be used if the routing underlay is an SPF-based IGP that computes a shortest-path tree from each node to all other nodes in the domain.
第6.2节的程序假定，在给定的BIER域内，在给定的布线参考底图中与给定BFR相邻的所有节点也是BFR。然而，即使情况并非如此，只要入口和出口节点是BFR，也可以使用BIER。在本节中，我们将介绍当路由参考底图是基于SPF的IGP时可以使用的步骤，该IGP计算从每个节点到域中所有其他节点的最短路径树。
At a given BFR, say "BFR-B", start with a copy of the IGP-computed shortest-path tree from BFR-B to each router in the domain. (This tree is computed by the SPF algorithm of the IGP.) Let's call this copy the "BIER-SPF tree rooted at BFR-B". BFR-B then modifies this BIER-SPF tree as follows.
在给定的BFR，比如“BFR-B”，从IGP计算出的从BFR-B到域中每个路由器的最短路径树的副本开始。（此树由IGP的SPF算法计算）让我们将此副本称为“以BFR-B为根的BIER-SPF树”。BFR-B然后修改BIER-SPF树，如下所示。
1. BFR-B looks in turn at each of its child nodes on the BIER-SPF tree.
1. BFR-B依次查看BIER-SPF树上的每个子节点。
2. If one of the child nodes does not support BIER, BFR-B removes that node from the tree. The child nodes of the node that has just been removed are then re-parented on the tree, so that BFR-B now becomes their parent.
2. 如果其中一个子节点不支持BIER，BFR-B将从树中删除该节点。然后，刚删除的节点的子节点将在树上重新设置为父节点，以便BFR-B现在成为它们的父节点。
3. BFR-B then continues to look at each of its child nodes, including any nodes that have been re-parented to BFR-B as a result of the previous step.
3. 然后，BFR-B继续查看其每个子节点，包括由于上一步而重新成为BFR-B父节点的任何节点。
When all of the child nodes (the original child nodes plus any new ones) have been examined, BFR-B's children on the BIER-SPF tree will all be BFRs.
检查所有子节点（原始子节点加上任何新节点）后，BIER-SPF树上的BFR-B子节点都将是BFR。
When the BIFT is constructed, BFR-B's child nodes on the BIER-SPF tree are considered to be the BFR-NBRs. The F-BMs must be computed appropriately, based on the BFR-NBRs.
构造BIFT时，BIER-SPF树上的BFR-B子节点被视为BFR NBR。必须根据BFR NBR适当计算F-BMs。
BFR-B may now have BFR-NBRs that are not "directly connected" to BFR-B via Layer 2. To send a packet to one of these BFR-NBRs, BFR-B will have to send the packet through a unicast tunnel. In an MPLS network, this may be as simple as finding the IGP unicast next hop to the child node and pushing on (above the BIER encapsulation header) an MPLS label that the IGP next hop has bound to an address of the child node. (This assumes that the packet is using an MPLS-based BIER encapsulation, such as the one specified in Section 2.1 of [MPLS_BIER_ENCAPS].) Of course, the BIFT-id in the BIER encapsulation header must be the BIFT-id advertised by the child node for the packet's SI, sub-domain, and BitStringLength.
BFR-B现在可能有未通过第2层“直接连接”到BFR-B的BFR NBR。要向这些BFR NBR之一发送数据包，BFR-B必须通过单播隧道发送数据包。在MPLS网络中，这可能与查找到子节点的IGP单播下一跳并推送（在BIER封装报头上方）IGP下一跳已绑定到子节点地址的MPLS标签一样简单。（这假设数据包使用基于MPLS的BIER封装，如[MPLS_BIER_ENCAPS]第2.1节中规定的封装）。当然，BIER封装头中的BIFT id必须是子节点针对数据包的SI、子域和BitStringLength发布的BIFT id。
If for some reason the unicast tunnel cannot be an MPLS tunnel, any other kind of tunnel can be used, as long as the encapsulation for that tunnel type has a way of indicating that the payload is a BIER-encapsulated packet.
如果由于某种原因单播隧道不能是MPLS隧道，则可以使用任何其他类型的隧道，只要该隧道类型的封装具有指示有效负载是更大封装分组的方式。
Note that if a BIER-encapsulated packet is not using an MPLS-based BIER encapsulation, it will not be possible to send it through an MPLS tunnel unless it is known that the tunnel only carries BIER packets; this is because MPLS has no "next protocol type" field. This is not a problem if an MPLS-based BIER encapsulation is used, because in that case the BIER encapsulation begins with an MPLS label that identifies the packet as a BIER-encapsulated packet.
注意，如果BIER封装的分组未使用基于MPLS的BIER封装，则将不可能通过MPLS隧道发送它，除非知道隧道仅承载BIER分组；这是因为MPLS没有“下一个协议类型”字段。如果使用基于MPLS的BIER封装，则这不是问题，因为在这种情况下，BIER封装从MPLS标签开始，该标签将数据包标识为BIER封装的数据包。
Of course, the above is not meant as an implementation technique, just as a functional description.
当然，以上并不是一种实现技术，只是一种功能描述。
While the above description assumes that the routing underlay provides an SPF tree, it may also be applicable to other types of routing underlays.
虽然上述说明假定布线参考底图提供SPF树，但也可能适用于其他类型的布线参考底图。
The technique above can also be used to provide "node protection" (i.e., to provide fast reroute around nodes that are believed to have failed). If BFR-B has a failed BFR-NBR, BFR-B can remove the failed BFR-NBR from the BIER-SPF tree and can then re-parent the child BFR-NBRs of the failed BFR-NBR so that they appear to be BFR-B's own child nodes on the tree (i.e., so that they appear to be BFR-B's BFR-NBRs). The usual BIER forwarding procedures then apply. However, getting the packet from BFR-B to the child nodes of the failed BFR-NBR is a bit more complicated, as it may require using a unicast bypass tunnel to get around the failed node.
上述技术还可用于提供“节点保护”（即，在被认为发生故障的节点周围提供快速重新路由）。如果BFR-B有一个失败的BFR-NBR，BFR-B可以从BIER-SPF树中删除失败的BFR-NBR，然后可以重新设置失败的BFR-NBR的子BFR NBR的父级，以便它们在树上看起来是BFR-B自己的子节点（即，使它们看起来是BFR-B的BFR NBR）。通常的BIER转发程序适用。然而，将数据包从BFR-B传送到故障BFR-NBR的子节点要复杂一些，因为可能需要使用单播旁路隧道绕过故障节点。
A simpler variant of step 2 above would be the following:
上述步骤2的一个简单变体如下：
If one of the child nodes does not support BIER, BFR-B removes that node from the tree. All BFERs that are reached through that child node are then re-parented on the tree, so that BFR-B now becomes their parent.
如果其中一个子节点不支持BIER，BFR-B将从树中删除该节点。然后，通过该子节点到达的所有bfer在树上重新成为父节点，因此BFR-B现在成为它们的父节点。
This variant is simpler because the set of BFERs that are reached through a particular child node of BFR-B can be determined from the F-BM in the BIFT. However, if this variant is used, the results are less optimal, because packets will be unicast directly from BFR-B to the BFERs that are reachable through the non-BIER child node.
此变体更简单，因为通过BFR-B的特定子节点到达的BFER集可以从BIFT中的F-BM确定。但是，如果使用这种变体，结果就不太理想，因为数据包将直接从BFR-B单播到可通过非BIER子节点到达的BFER。
When using a unicast MPLS tunnel to get a packet to a BFR-NBR:
使用单播MPLS隧道将数据包传送到BFR-NBR时：
o The TTL of the MPLS label entry representing the tunnel SHOULD be set to a large value, rather than being copied from the TTL value from the BIER encapsulation header, and
o 表示隧道的MPLS标签项的TTL应设置为大值，而不是从BIER封装头的TTL值复制，以及
o When the tunnel labels are popped off, the TTL from the tunnel labels SHOULD NOT be copied to the BIER encapsulation header.
o 当隧道标签弹出时，隧道标签中的TTL不应复制到BIER封装头。
In other words, the TTL processing for the tunnel SHOULD be as specified in [RFC3443] for "Pipe Model" and "Short Pipe Model" Label Switched Paths (LSPs). The same principle applies if the tunnels are not MPLS tunnels; the BIER packet SHOULD NOT inherit the TTL from the tunnel encapsulation. That way, the TTL of the BIER encapsulation header constrains only the number of BFRs that the packet may traverse, not the total number of hops.
换句话说，隧道的TTL处理应符合[RFC3443]中关于“管道模型”和“短管模型”标签交换路径（LSP）的规定。如果隧道不是MPLS隧道，同样的原则也适用；BIER数据包不应从隧道封装继承TTL。这样，BIER封装报头的TTL仅限制数据包可能穿越的BFR数量，而不是总跳数。
If two BIER packets have the same value in the entropy field of their respective BIER headers and if both are transmitted through a given tunnel, it is desirable for the tunnel encapsulation to preserve the fact that the two packets have the same entropy.
如果两个BIER分组在其各自的BIER报头的熵字段中具有相同的值，并且如果两者都通过给定的隧道传输，则隧道封装希望保持两个分组具有相同熵的事实。
The material in this section presupposes that if a given router is a BFR, then it supports BIER on all its interfaces. It is, however, possible that a router will have some line cards that support BIER and some that do not. In such a case, one can think of the router as a "partial BFR" that supports BIER only on some of its interfaces. If it is desired to deploy such partial BFRs, one can use the multi-topology features of the IGP to set up a BIER-specific topology. This topology would exclude all the non-BIER-capable interfaces that attach to BFRs. BIER would then have to be run in a sub-domain that is bound to this topology. If unicast tunnels are used to bypass non-BFRs, either (a) the tunnels have to be restricted to this topology or (b) the tunnel endpoints have to be BFRs that do not have any non-BIER-capable interfaces.
本节中的材料假设，如果给定路由器是BFR，那么它在所有接口上都支持BIER。然而，路由器可能会有一些线路卡支持BIER，而有些线路卡不支持BIER。在这种情况下，可以将路由器视为“部分BFR”，仅在其某些接口上支持BIER。如果需要部署此类局部BFR，可以使用IGP的多拓扑功能来建立BIER特定拓扑。此拓扑将排除连接到BFR的所有非BIER功能接口。然后，BIER必须在绑定到此拓扑的子域中运行。如果使用单播隧道绕过非BFR，则（a）隧道必须限于此拓扑，或者（b）隧道端点必须是没有任何非BIER功能接口的BFR。
The procedures of this section apply only when the same encapsulation is used throughout the BIER domain. Consideration of the scenario where both multiple encapsulations and multiple BitStringLengths are used in a given BIER domain is outside the scope of this document.
本节中的程序仅适用于BIER域中使用相同封装的情况。考虑在给定BIER域中同时使用多个封装和多个BitStringLength的场景超出了本文档的范围。
It is possible for different BFRs within a BIER domain to be using different Imposition and/or Disposition BitStringLengths. As stated in Section 3:
BIER域内的不同BFR可能使用不同的强制和/或处置比特长度。如第3节所述：
"if a particular BFIR is provisioned to use a particular Imposition BitStringLength and a particular Imposition sub-domain when imposing the encapsulation on a given set of packets, all other BFRs with BFR-ids in that sub-domain SHOULD be provisioned to process received BIER packets with that BitStringLength (i.e., all other BFRs with BFR-ids in that sub-domain SHOULD be provisioned with that BitStringLength as a Disposition BitStringLength for that sub-domain)."
“如果将特定BFIR设置为在对给定数据包集进行封装时使用特定的强制比特串长度和特定强制子域，则应将该子域中具有BFR ID的所有其他BFR设置为处理接收到的具有该比特串长度的BIER数据包（即，在该子域中具有BFR ID的所有其他BFR应设置该BitStringLength作为该子域的处置BitStringLength）。”
Note that mis-provisioning can result in "black holes". If a BFIR creates a BIER packet with a particular BitStringLength and if that packet needs to travel through a BFR that cannot process received BIER packets with that BitStringLength, then it may be impossible to forward the packet to all of the BFERs identified in its BIER header. Section 6.10.1 defines a procedure, the "BitStringLength Compatibility Check", that can be used to detect the possibility of such black holes.
请注意，错误配置可能会导致“黑洞”。如果BFIR创建具有特定BitStringLength的BIER数据包，并且如果该数据包需要经过无法处理具有该BitStringLength的接收BIER数据包的BFR，则可能无法将该数据包转发到其BIER报头中标识的所有BFER。第6.10.1节定义了“BitStringLength兼容性检查”程序，可用于检测此类黑洞的可能性。
However, failure of the BitStringLength Compatibility Check does not necessarily result in the creation of black holes; Section 6.10.2 specifies OPTIONAL procedures that allow BIER forwarding to proceed without black holes, even if the BitStringLength Compatibility Check fails.
然而，BitStringLength兼容性检查的失败并不一定会导致黑洞的产生；第6.10.2节规定了允许BIER转发在没有黑洞的情况下继续进行的可选程序，即使BitStringLength兼容性检查失败。
If the procedures of Section 6.10.2 are not deployed but the BitStringLength Compatibility Check fails at some BFIR, the BFIR has two choices:
如果未部署第6.10.2节中的程序，但某些BFIR的BitStringLength兼容性检查失败，则BFIR有两种选择：
o Create BIER packets with the provisioned Imposition BitStringLength, even though the packets may not be able to reach all the BFERs identified in their BitStrings.
o 创建具有设置的BitStringLength的BIER数据包，即使数据包可能无法到达其位字符串中标识的所有BFER。
o Use an Imposition BitStringLength that passes the Compatibility Check (assuming that there is one), even if this is not the provisioned Imposition BitStringLength.
o 使用通过兼容性检查的拼版BitStringLength（假设有），即使这不是已设置的拼版BitStringLength。
Section 6.10.1 discusses the implications of making one or the other of these choices.
第6.10.1节讨论了做出其中一种选择的含义。
There will be times when an operator wishes to change the BitStringLengths used in a particular BIER domain. Section 6.10.3 specifies a simple procedure that can be used to transition a BIER domain from one BitStringLength to another.
有时操作员希望更改特定BIER域中使用的BitStringLength。第6.10.3节规定了一个简单的程序，可用于将BIER域从一个BitStringLength转换为另一个BitStringLength。
When a BFIR needs to encapsulate a packet, the BFIR first assigns the packet to a sub-domain. The BFIR then chooses an Imposition BitStringLength L for the packet. The choice of Imposition BitStringLength is determined by provisioning. However, the BFIR should also perform the BitStringLength Compatibility Check defined below.
当BFIR需要封装数据包时，BFIR首先将数据包分配给子域。然后，BFIR为数据包选择一个比特串长度L。设置BitStringLength的选择由设置决定。但是，BFIR还应执行下面定义的BitStringLength兼容性检查。
The combination of sub-domain S and Imposition BitStringLength L passes the BitStringLength Compatibility Check if and only if the following condition holds:
当且仅当以下条件成立时，子域S和BitStringLength L的组合通过BitStringLength兼容性检查：
Every BFR that has advertised its membership in sub-domain S has also advertised that it is using Disposition BitStringLength L (and possibly other BitStringLengths as well) in that sub-domain. (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is being used, this means that every BFR that is advertising a label for sub-domain S is advertising a label for the combination of sub-domain S and Disposition BitStringLength L.)
每个在子域S中公布其成员资格的BFR也公布了它正在该子域中使用处置BitStringLength L（可能还有其他BitStringLength）。（如果使用MPLS封装（第2.1节[MPLS_BIER_ENCAPS]），这意味着为子域S发布标签的每个BFR都在为子域S和处置BitStringLength L的组合发布标签。）
If a BFIR has been provisioned to use a particular Imposition BitStringLength and a particular sub-domain for some set of packets, and if that combination of Imposition BitStringLength and sub-domain does not pass the BitStringLength Compatibility Check, the BFIR SHOULD log this fact as an error. It then has the following two choices about what to do with the packets:
如果已将BFIR设置为对某些数据包集使用特定的强制设置BitStringLength和特定子域，并且如果强制设置BitStringLength和子域的组合未通过BitStringLength兼容性检查，则BFIR应将此事实记录为错误。然后，对于如何处理数据包，它有以下两个选择：
1. The BFIR MAY use the provisioned Imposition BitStringLength anyway. If the procedure of either option 2 or option 3 of Section 6.10.2 is deployed, this will not cause black holes and may actually be the optimal result. It should be understood, though, that the BFIR cannot determine by signaling whether those procedures have been deployed.
1. 无论如何，BFIR都可以使用已设置的位字符串长度。如果采用第6.10.2节选项2或选项3中的程序，这不会导致黑洞，实际上可能是最佳结果。不过，应该理解的是，BFIR无法通过发出信号来确定这些程序是否已部署。
2. If the BFIR is capable of using an Imposition BitStringLength that does pass the BitStringLength Compatibility Check for the particular sub-domain, the BFIR MAY use that Imposition BitStringLength instead.
2. 如果BFIR能够使用通过特定子域的BitStringLength兼容性检查的强制BitStringLength，则BFIR可以使用该强制BitStringLength。
Which of these two choices to make is itself determined by provisioning.
这两种选择中的哪一种由资源调配本身决定。
Note that discarding the packets is not one of the allowable choices. Suppose, for example, that all the BFIRs are provisioned to use Imposition BitStringLength L for a particular sub-domain S but one BFR has not been provisioned to use Disposition BitStringLength L for sub-domain S. This will cause the BitStringLength Compatibility Check to fail. If the BFIR sends packets with BitStringLength L and sub-domain S, the mis-provisioned BFR will not be able to forward those packets, and thus the packets may only be able to reach a subset of the BFERs to which they are destined. However, this is still better than having the BFIRs drop the packets; if the BFIRs discard the packets, the packets won't reach any of the BFERs to which they are destined at all.
请注意，丢弃数据包不是允许的选择之一。例如，假设所有BFR已设置为对特定子域S使用强制设置BitStringLength L，但一个BFR尚未设置为对子域S使用处置BitStringLength L。这将导致BitStringLength兼容性检查失败。如果BFIR发送具有BitStringLength L和子域S的数据包，则错误配置的BFR将无法转发这些数据包，因此数据包可能只能到达其目的地BFER的子集。然而，这仍然比让BFIR丢弃数据包要好；如果BFIR丢弃数据包，数据包将根本无法到达其目的地的任何BFER。
If the procedures of Section 6.10.2 have not been deployed, choice 2 above might seem like a better option. However, there might not be any Imposition BitStringLength that a given BFIR can use that also passes the BitStringLength Compatibility Check. If it is desired to use choice 2 in a particular deployment, then there should be a "Fallback Disposition BitStringLength" (call it "F") such that:
如果未采用第6.10.2节中的程序，则上述选择2可能是更好的选择。但是，给定的BFIR可能无法使用任何也通过BitStringLength兼容性检查的BitStringLength。如果希望在特定部署中使用选项2，则应该有一个“后备处置BitStringLength”（称为“F”），以便：
o Every BFR advertises that it uses BitStringLength F as a Disposition BitStringLength for every sub-domain, and
o 每个BFR都声明它使用BitStringLength F作为每个子域的处置BitStringLength，并且
o If a BFIR is provisioned to use Imposition BitStringLength X and Imposition sub-domain S for a certain class of packets but the BitStringLength Compatibility Check fails for the combination of BitStringLength X and sub-domain S, then the BFIR will fall back to using BitStringLength F as the Imposition BitStringLength whenever the Imposition sub-domain is S.
o 如果将BFIR设置为对特定类别的数据包使用强制执行BitStringLength X和强制执行子域S，但BitStringLength X和子域S组合的BitStringLength兼容性检查失败，然后，每当拼版子域为S时，BFIR将返回使用BitStringLength F作为拼版BitStringLength。
It is RECOMMENDED that the value of F be the default BitStringLength for the encapsulation being used.
建议将F的值作为所使用封装的默认BitStringLength。
Suppose that a packet has been BIER-encapsulated with a BitStringLength value of X and that the packet has arrived at BFR-A. Now suppose that according to the routing underlay the next hop is BFR-B, but BFR-B is not using X as one of its Disposition BitStringLengths. What should BFR-A do with the packet? BFR-A has three options. It MUST do one of the three, but the choice of which procedure to follow is a local matter. The three options are:
假设一个数据包已经用BitStringLength值X进行了BIER封装，并且该数据包已经到达BFR-a。现在假设根据路由基线，下一跳是BFR-B，但BFR-B没有使用X作为其配置BitStringLength之一。BFR-A应该如何处理数据包？BFR-A有三种选择。它必须执行这三种程序中的一种，但选择遵循哪种程序是一个局部问题。这三种选择是：
1. BFR-A MAY discard the packet.
1. BFR-A可以丢弃该数据包。
2. BFR-A MAY re-encapsulate the packet, using a BIER header whose BitStringLength value is supported by BFR-B.
2. BFR-A可以使用其BitStringLength值受BFR-B支持的BIER报头重新封装数据包。
Note that if BFR-B only uses Disposition BitStringLength values that are smaller than the BitStringLength value of the packet, this may require creating additional copies of the packet. Whether additional copies actually have to be created depends upon the bits that are actually set in the original packet's BitString.
请注意，如果BFR-B仅使用小于数据包的BitStringLength值的Disposition BitStringLength值，则可能需要创建数据包的其他副本。是否必须创建其他副本取决于原始数据包位字符串中实际设置的位。
3. BFR-A MAY treat BFR-B as if BFR-B did not support BIER at all, in which case BFR-A applies the rules of Section 6.9.
3. BFR-A可将BFR-B视为BFR-B根本不支持BIER，在这种情况下，BFR-A适用第6.9节的规则。
Note that there is no signaling that enables a BFR to advertise which of the three options it will use.
请注意，没有任何信号使BFR能够公布它将使用的三个选项中的哪一个。
Option 2 can be useful if there is a region of the BIER domain where the BFRs are capable of using a long BitStringLength as well as a region where the BFRs are only capable of using a shorter BitStringLength.
如果BIER域中存在BFR能够使用长BitStringLength的区域以及BFR只能使用较短BitStringLength的区域，则选项2可能有用。
Suppose one wants to migrate the BitStringLength used in a particular BIER domain from one value (X) to another value (Y). The following migration procedure can be used. This procedure allows the BFRs to be reprovisioned one at a time and does not require a "flag day".
假设要将特定BIER域中使用的BitStringLength从一个值（X）迁移到另一个值（Y）。可以使用以下迁移过程。此程序允许一次重新设置一个BFR，无需“卖旗日”。
1. Upgrade all the BFRs in the domain so that they use both value X and value Y as their Disposition BitStringLengths.
1. 升级域中的所有BFR，以便它们使用值X和值Y作为其处置位字符串长度。
2. Reprovision the BFIRs so that they use BitStringLength value Y as the Imposition BitStringLength.
2. 重新设置BFIR，使其使用BitStringLength值Y作为施加BitStringLength。
3. One may then optionally reprovision all the BFRs so that they no longer use Disposition BitStringLength X.
3. 然后，可以选择重新设置所有BFR，使其不再使用配置BitStringLength X。
BIER offers a radical simplification over current IP multicast operations: no tree-building control plane, no per-flow forwarding state, no Reverse Path Forwarding (RPF), no Rendezvous Point (RP), etc. BIER packet forwarding/replication is along the unicast paths to each bit position set in the packet, ensuring that the encapsulated multicast packets follow the same path as unicast to each set bit in the header. The BIER FIB can be derived from the SPF-calculated unicast FIB or from any other forwarding-path calculation in or out of band. Each bit will follow this unicast path from the entry point of the BIER domain to the edge device with that assigned bit.
BIER提供了对当前IP多播操作的彻底简化：无树构建控制平面、无每流转发状态、无反向路径转发（RPF）、无集合点（RP）等。BIER数据包转发/复制沿单播路径到数据包中设置的每个位位置，确保封装的多播数据包遵循与单播到报头中每个设置位相同的路径。BIER FIB可以从SPF计算的单播FIB或任何其他带内或带外转发路径计算中导出。从BIER域的入口点到具有该指定位的边缘设备，每个位都将遵循该单播路径。
Due to these differences, operational expectations from traditional multicast solutions do not apply to a BIER domain. There is no granular per-flow state at each node defining a tree. Monitoring flows at the forwarding-plane level ((S,G) entries) is not provided in a BIER node. BIER FIB packet counters may be maintained for BFR-ids or next-hop neighbors. Any flow-based metrics will require deeper packet inspection; this topic is outside the scope of this document. In this way, BIER is again more like unicast.
由于这些差异，传统多播解决方案的操作期望不适用于BIER域。在定义树的每个节点上，没有粒度每流状态。BIER节点中不提供转发平面级别的监控流（（S，G）条目）。可以为BFR ID或下一跳邻居维护BIER FIB数据包计数器。任何基于流的度量都需要更深入的数据包检查；本主题不在本文档的范围内。通过这种方式，BIER再次更像是单播。
It is this reduction in state that allows for one of the key operational benefits of BIER: deterministic convergence. The BIER FIB can converge immediately after the unicast FIB regardless of how many multicast flows are transiting the links. Careful monitoring of (S,G) utilization is not required within a BIER domain.
正是这种状态的减少使得BIER的一个关键操作优势得以实现：确定性收敛。BIER FIB可以在单播FIB之后立即收敛，而不管有多少多播流通过链路。在BIER域内不需要仔细监控（S，G）利用率。
A BIER domain requires that each edge node (BFER) be given a unique bit position in the BIER mask (BFR-id). The BFR-id must be configured on each BFER and associated with a unique IP address of that BFER. Any existing manual or automated configuration tools must provide access to BIER-specific configuration. The association of the BFR-id with a unique address of the BFER to which it is assigned must also be advertised into the IGP of the BIER domain. This may be implied from the BIER configuration or require IGP-specific configuration. This document does not dictate any specific configuration methodology.
BIER域要求每个边缘节点（BFER）在BIER掩码（BFR id）中具有唯一的位位置。必须在每个BFER上配置BFR id，并与该BFER的唯一IP地址关联。任何现有的手动或自动配置工具必须提供对BIER特定配置的访问。BFR id与分配给它的BFER的唯一地址的关联也必须发布到BIER域的IGP中。这可能来自BIER配置或需要IGP特定配置。本文件不规定任何特定的配置方法。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
When BIER is paired with a particular multicast flow overlay, it inherits the security considerations of that layer. Similarly, when BIER is paired with a particular routing underlay, it inherits the security considerations of that layer.
当BIER与特定的多播流覆盖配对时，它继承了该层的安全考虑。类似地，当BIER与特定布线参考底图配对时，它将继承该层的安全考虑。
If the BIER encapsulation of a particular packet specifies an SI or a BitString other than the one intended by the BFIR, the packet is likely to be misdelivered. If the BIER encapsulation of a packet is modified (through error or malfeasance) in a way other than that specified in this document, the packet may be misdelivered. Some modifications of the BIER encapsulation, e.g., setting every bit in the BitString, may result in (intentional or unintentional) denial-of-service (DoS) attacks.
如果特定数据包的BIER封装指定了一个SI或比特串，而不是BFIR想要的，则该数据包很可能被误发。如果数据包的BIER封装被修改（由于错误或渎职）的方式不同于本文件中规定的方式，则数据包可能被误发。BIER封装的某些修改（例如，设置位字符串中的每一位）可能导致（有意或无意）拒绝服务（DoS）攻击。
If a BFIR is compromised, it may impose a BIER encapsulation with all the bits in the BitString set; this would also result in a DoS attack.
如果BFIR被破坏，它可能会对位字符串集中的所有位进行BIER封装；这也会导致拒绝服务攻击。
Every BFR MUST be provisioned to know which of its interfaces lead to a BIER domain and which do not. BIER-encapsulated packets MUST NOT be accepted from outside the BIER domain. (Reception of BIER-encapsulated packets from outside the BIER domain would create an attack vector for DoS attacks, as an attacker might set all the bits in the BitString.)
必须对每个BFR进行配置，以了解其接口中哪些通向BIER域，哪些不通向BIER域。BIER封装的数据包不得从BIER域外部接受。（从BiER域外部接收BIER封装的包将创建DoS攻击的攻击向量，因为攻击者可能会设置位串中的所有位）。
If two interfaces lead to different BIER domains, the BFR MUST be provisioned to know that those two interfaces lead to different BIER domains. If the provisioning is not correct, BIER-encapsulated packets from one BIER domain may "leak" into another; this is likely to result in misdelivery of packets.
如果两个接口指向不同的BIER域，则必须设置BFR，以了解这两个接口指向不同的BIER域。如果配置不正确，来自一个BIER域的BIER封装数据包可能“泄漏”到另一个BIER域；这可能会导致数据包的错误传递。
DoS attacks may also result from incorrect provisioning (through error or malfeasance) of the BFRs.
DoS攻击也可能由BFRs的错误配置（通过错误或渎职）造成。
If the procedures used for advertising BFR-ids and BFR-prefixes are not secure, an attack on those procedures may result in incorrect delivery of BIER-encapsulated packets.
如果用于公布BFR ID和BFR前缀的过程不安全，则对这些过程的攻击可能会导致BIER封装数据包的错误传递。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，DOI 10.17487/RFC3443，2003年1月<https://www.rfc-editor.org/info/rfc3443>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[BGP_BIER_EXTENSIONS] Xu, X., Ed., Chen, M., Patel, K., Wijnands, IJ., and A. Przygienda, "BGP Extensions for BIER", Work in Progress, draft-ietf-bier-idr-extensions-03, August 2017.
[BGP-BIER-U扩展]Xu，X.，Ed.，Chen，M.，Patel，K.，Wijnands，IJ.，和A.Przygienda，“BIER的BGP扩展”，正在进行的工作，草案-ietf-BIER-idr-EXTENSIONS-032017年8月。
[BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Przygienda, "Multicast VPN Using BIER", Work in Progress, draft-ietf-bier-mvpn-09, November 2017.
[BIER_MVPN]Rosen，E.，Ed.，Sivakumar，M.，Aldrin，S.，Dolganow，A.，和T.Przygienda，“使用BIER的多播VPN”，正在进行的工作，草稿-ietf-BIER-MVPN-092017年11月。
[Boivie_Feldman] Boivie, R. and N. Feldman, "Small Group Multicast", Work in Progress, draft-boivie-sgm-02, February 2001.
[Boivie_Feldman]Boivie，R.和N.Feldman，“小群体多播”，正在进行的工作，草稿-Boivie-sgm-022001年2月。
[ISIS_BIER_EXTENSIONS] Ginsberg, L., Ed., Przygienda, A., Aldrin, S., and J. Zhang, "BIER Support via ISIS", Work in Progress, draft-ietf-bier-isis-extensions-06, October 2017.
[ISIS_-BIER_EXTENSIONS]金斯伯格，L.，Ed.，Przygienda，A.，奥尔德林，S.，和J.张，“通过ISIS提供的BIER支持”，正在进行的工作，草案-ietf-BIER-ISIS-EXTENSIONS-062017年10月。
[MPLS_BIER_ENCAPS] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS Networks", Work in Progress, draft-ietf-bier-mpls-encapsulation-12, October 2017.
[MPLS_BIER_ENCAPS]Wijnands，IJ.，Ed.，Rosen，E.，Ed.，Dolganow，A.，Tantsura，J.，Aldrin，S.，和I.Meilik，“MPLS和非MPLS网络中位索引显式复制的封装”，正在进行中，草稿-ietf-BIER-MPLS-Encapsulation-12，2017年10月。
[OSPF_BIER_EXTENSIONS] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions for BIER", Work in Progress, draft-ietf-bier-ospf-bier-extensions-09, October 2017.
[OSPF-BIER_扩展]Psenak，P.，Ed.，Kumar，N.，Wijnands，IJ.，Dolganow，A.，Przygienda，T.，Zhang，J.，和S.Aldrin，“用于BIER的OSPF扩展”，正在进行中，草案-ietf-BIER-OSPF-BIER-EXTENSIONS-09，2017年10月。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6513]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，DOI 10.17487/RFC6513，2012年2月<https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，DOI 10.17487/RFC6514，2012年2月<https://www.rfc-editor.org/info/rfc6514>.
Acknowledgements
致谢
The authors wish to thank Rajiv Asati, Alia Atlas, John Bettink, Ross Callon (who contributed much of the text on deterministic ECMP), Nagendra Kumar, Christian Martin, Neale Ranns, Albert Tian, Ramji Vaithianathan, Xiaohu Xu, and Jeffrey Zhang for their ideas and contributions to this work.
作者希望感谢Rajiv Asati、Alia Atlas、John Bettink、Ross Callon（他对确定性ECMP的大部分文本做出了贡献）、Nagendra Kumar、Christian Martin、Neale Ranns、Albert Tian、Ramji Vaithianathan、Xiaohu和Jeffrey Zhang，感谢他们对这项工作的想法和贡献。
The authors also wish to thank Sue Hares, Victor Kuarsingh, and Dan Romascanu for their reviews of this document.
作者还要感谢Sue Hares、Victor Kuarsingh和Dan Romascanu对本文件的评论。
Contributors
贡献者
The following people contributed significantly to the content of this document and should be considered co-authors:
以下人员对本文件的内容做出了重大贡献，应被视为共同作者：
Gregory Cauchie Bouygues Telecom Email: gcauchie@bouyguestelecom.fr
Gregory Cauchie Bouygues电信电子邮件：gcauchie@bouyguestelecom.fr
Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com
马赫（郭毅）陈华为电子邮件：马赫。chen@huawei.com
Arkadiy Gulko Thomson Reuters 195 Broadway New York, NY 10007 United States of America Email: arkadiy.gulko@thomsonreuters.com
Arkadiy Gulko Thomson路透社195纽约州纽约百老汇10007美利坚合众国电子邮件：Arkadiy。gulko@thomsonreuters.com
Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 Belgium Email: wim.henderickx@nokia.com
Wim Henderickx诺基亚哥白尼50安特卫普2018比利时电子邮件：Wim。henderickx@nokia.com
Martin Horneffer Deutsche Telekom Hammer Str. 216-226 Muenster 48153 Germany Email: Martin.Horneffer@telekom.de
Martin Horneffer Deutsche Telekom Hammer Str.216-226 Muenster 48153德国电子邮件：Martin。Horneffer@telekom.de
Luay Jalil Verizon 1201 East Arapaho Rd. Richardson, TX 75081 United States of America Email: luay.jalil@verizon.com
Luay Jalil Verizon德克萨斯州理查森市东阿拉帕霍路1201号，邮编75081美利坚合众国电子邮件：Luay。jalil@verizon.com
Uwe Joorde Deutsche Telekom Hammer Str. 216-226 Muenster D-48153 Germany Email: Uwe.Joorde@telekom.de
Uwe Joorde Deutsche Telekom Hammer Str.216-226 Muenster D-48153德国电子邮件：Uwe。Joorde@telekom.de
Greg Shepherd Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States of America Email: shep@cisco.com
Greg Shepherd Cisco Systems 170西塔斯曼大道圣何塞，加利福尼亚州95134美利坚合众国电子邮件：shep@cisco.com
Jeff Tantsura Email: jefftant.ietf@gmail.com
Jeff Tantsura电子邮件：jefftant。ietf@gmail.com
Authors' Addresses
作者地址
IJsbrand Wijnands (editor) Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands（编辑）思科系统公司De Kleetlaan 6a Diegem 1831比利时
Email: ice@cisco.com
Email: ice@cisco.com
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
Eric C.Rosen（编辑）Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: erosen@juniper.net
Email: erosen@juniper.net
Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark Singapore 119968 Singapore
Andrew Dolganow诺基亚438B Alexandra路#08-07/10 Alexandra Technopark Singapore 119968新加坡
Email: andrew.dolganow@nokia.com
Email: andrew.dolganow@nokia.com
Tony Przygienda Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, California 94089 United States of America
Tony Przygienda Juniper Networks，Inc.美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
Email: prz@juniper.net
Email: prz@juniper.net
Sam K. Aldrin Google, Inc. 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America
Sam K.Aldrin Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场94043
Email: aldrin.ietf@gmail.com
Email: aldrin.ietf@gmail.com