Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 8296 Cisco Systems, Inc.
Category: Experimental E. Rosen, Ed.
ISSN: 2070-1721 Juniper Networks, Inc.
A. Dolganow
Nokia
J. Tantsura
Individual
S. Aldrin
Google, Inc.
I. Meilik
Broadcom
January 2018
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 8296 Cisco Systems, Inc.
Category: Experimental E. Rosen, Ed.
ISSN: 2070-1721 Juniper Networks, Inc.
A. Dolganow
Nokia
J. Tantsura
Individual
S. Aldrin
Google, Inc.
I. Meilik
Broadcom
January 2018
Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks
MPLS和非MPLS网络中位索引显式复制（BIER）的封装
Abstract
摘要
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. 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 details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.
比特索引显式复制（BIER）是一种通过“多播域”提供最佳多播转发的体系结构，无需中间路由器维持任何每流状态或参与显式树构建协议。当多播数据分组进入域时，入口路由器确定分组需要发送到的出口路由器的集合。然后，入口路由器将数据包封装在BIER报头中。BIER报头包含一个位字符串，其中每个位恰好代表域中的一个出口路由器；为了将分组转发到给定的一组出口路由器，在BIER报头中设置与这些路由器对应的比特。封装的细节取决于用于实现多播域的网络类型。本文档指定了一种BIER封装，该封装可用于MPLS网络，也可用于非MPLS网络（略有不同）。
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/rfc8296.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8296.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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 ....................................................3
2. BIER Header .....................................................5
2.1. In MPLS Networks ...........................................5
2.1.1. Encapsulation Initial Four Octets ...................5
2.1.1.1. The BIER-MPLS Label ........................5
2.1.1.2. Other Fields of the Initial Four Octets ....8
2.1.2. Remainder of Encapsulation ..........................9
2.1.3. Further Encapsulating a BIER Packet ................12
2.2. In Non-MPLS Networks ......................................13
2.2.1. Encapsulation Initial Four Octets ..................13
2.2.1.1. The BIFT-id ...............................13
2.2.1.2. Other Fields of the Initial Four Octets ...13
2.2.2. Remainder of Encapsulation .........................14
2.2.3. Further Encapsulating a BIER Packet ................15
3. Imposing and Processing the BIER Encapsulation .................16
4. IANA Considerations ............................................18
5. IEEE Considerations ............................................18
6. Security Considerations ........................................19
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................21
Acknowledgements ..................................................22
Contributors ......................................................22
Authors' Addresses ................................................24
1. Introduction ....................................................3
2. BIER Header .....................................................5
2.1. In MPLS Networks ...........................................5
2.1.1. Encapsulation Initial Four Octets ...................5
2.1.1.1. The BIER-MPLS Label ........................5
2.1.1.2. Other Fields of the Initial Four Octets ....8
2.1.2. Remainder of Encapsulation ..........................9
2.1.3. Further Encapsulating a BIER Packet ................12
2.2. In Non-MPLS Networks ......................................13
2.2.1. Encapsulation Initial Four Octets ..................13
2.2.1.1. The BIFT-id ...............................13
2.2.1.2. Other Fields of the Initial Four Octets ...13
2.2.2. Remainder of Encapsulation .........................14
2.2.3. Further Encapsulating a BIER Packet ................15
3. Imposing and Processing the BIER Encapsulation .................16
4. IANA Considerations ............................................18
5. IEEE Considerations ............................................18
6. Security Considerations ........................................19
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................21
Acknowledgements ..................................................22
Contributors ......................................................22
Authors' Addresses ................................................24
[RFC8279] describes a new architecture for the forwarding of multicast data packets. Known as "Bit Index Explicit Replication" (BIER), that architecture provides optimal forwarding of multicast data packets through a "multicast domain". It does so without requiring any explicit tree-building protocol and without requiring intermediate nodes to maintain any per-flow state.
[RFC8279]描述了一种转发多播数据包的新体系结构。该体系结构称为“位索引显式复制”（BIER），通过“多播域”提供多播数据包的最佳转发。它这样做不需要任何显式的树构建协议，也不需要中间节点来维护任何每流状态。
This document will use terminology defined in [RFC8279].
本文件将使用[RFC8279]中定义的术语。
A router that supports BIER is known as a "Bit-Forwarding Router" (BFR). A "BIER domain" is a connected set of BFRs, each of which has been assigned a BFR-prefix. A BFR-prefix is a routable IP address of a BFR and is used by BIER to identify a BFR. A 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). As specified in [RFC8279], each BFR of a given BIER domain is provisioned to be in one or more "sub-domains" (SDs). In the context
支持BIER的路由器称为“位转发路由器”（BFR）。“BIER域”是一组连接的BFR，每个BFR都被分配了一个BFR前缀。BFR前缀是BFR的可路由IP地址，BIER使用它来标识BFR。数据包在比特转发入口路由器（BFIR）处进入BIER域，并在一个或多个比特转发出口路由器（BFER）处离开BIER域。如[RFC8279]中所述，给定BIER域的每个BFR都设置在一个或多个“子域”（SDs）中。在上下文中
of a given SD, each BFIR and BFER must have a BFR-id that is unique within that SD. A BFR-id is just a number in the range [1,65535] that, relative to a BIER SD, identifies a BFR uniquely.
对于给定的SD，每个BFIR和BFER必须具有在该SD内唯一的BFR id。BFR id只是[165535]范围内的一个数字，相对于BIER SD，它唯一地标识BFR。
As described in [RFC8279], BIER requires that multicast data packets be encapsulated with a header that provides the information needed to support the BIER forwarding procedures. This information includes the SD to which the packet has been assigned, a Set Identifier (SI), a BitString, and a BitStringLength (BSL). Together, these values are used to identify the set of BFERs to which the packet must be delivered.
如[RFC8279]所述，BIER要求多播数据包用一个报头封装，该报头提供支持BIER转发过程所需的信息。该信息包括数据包已分配到的SD、集合标识符（SI）、位字符串和位字符串长度（BSL）。这些值一起用于标识数据包必须发送到的BFER集合。
This document defines an encapsulation that can be used in either MPLS networks or non-MPLS networks. However, the construction and processing of the BIER header are slightly different in MPLS networks than in non-MPLS networks. In particular:
本文档定义了可用于MPLS网络或非MPLS网络的封装。然而，与非MPLS网络相比，MPLS网络中BIER报头的构造和处理略有不同。特别地：
o The handling of certain fields in the encapsulation header (the "BIER header") is different, depending upon whether the underlying network is an MPLS network or not.
o 封装报头（“BIER报头”）中某些字段的处理是不同的，这取决于底层网络是否为MPLS网络。
o In an MPLS network, the first four octets of a BIER header are also the bottom entry (the last four octets) of an MPLS label stack.
o 在MPLS网络中，BIER头的前四个八位字节也是MPLS标签堆栈的底部条目（最后四个八位字节）。
The MPLS-based encapsulation is explained in detail in Section 2.1. The differences between the MPLS-based encapsulation and the non-MPLS encapsulation are explained in Section 2.2.
第2.1节详细解释了基于MPLS的封装。第2.2节解释了基于MPLS的封装和非MPLS封装之间的区别。
Following the BIER header is the "payload". The payload may be an IPv4 packet, an IPv6 packet, an Ethernet frame, an MPLS packet, or an Operations, Administration, and Maintenance (OAM) packet. (The use of BIER with other payload types is also possible but is not further discussed in this document.) The BIER header contains information (the Next Protocol field) identifying the type of the payload.
BIER标题后面是“有效载荷”。有效载荷可以是IPv4分组、IPv6分组、以太网帧、MPLS分组或操作、管理和维护（OAM）分组。（也可以将BIER与其他有效负载类型一起使用，但本文档中不作进一步讨论。）BIER标头包含识别有效负载类型的信息（下一协议字段）。
If the payload is an MPLS packet, then an MPLS label stack immediately follows the BIER header. The top label of this MPLS label stack may be either a downstream-assigned label [RFC3031] or an upstream-assigned label [RFC5331].
如果有效负载是MPLS数据包，则MPLS标签堆栈紧跟在BIER报头之后。此MPLS标签堆栈的顶部标签可以是下游分配的标签[RFC3031]或上游分配的标签[RFC5331]。
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]所述进行解释。
The BIER header is shown in Figure 1.
BIER标题如图1所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nibble | Ver | BSL | Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM|Rsv| DSCP | Proto | BFIR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nibble | Ver | BSL | Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM|Rsv| DSCP | Proto | BFIR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BIER Header
图1：BIER标题
The BIFT-id represents a particular Bit Index Forwarding Table (BIFT); see Section 6.4 of [RFC8279]. As explained in [RFC8279], each BIFT corresponds to a particular combination of SD, BSL, and SI.
BIFT id表示特定比特索引转发表（BIFT）；见[RFC8279]第6.4节。如[RFC8279]所述，每个BIFT对应于SD、BSL和SI的特定组合。
Section 2.1 explains how the fields of the encapsulation header are used in MPLS networks. For those fields that are used differently in non-MPLS networks, Section 2.2 explains the differences.
第2.1节解释了如何在MPLS网络中使用封装头的字段。对于在非MPLS网络中使用不同的字段，第2.2节解释了这些差异。
The default BitStringLength value for the encapsulations defined in this document is 256. See Section 3 of [RFC8279] for a discussion of the default BitStringLength value.
本文档中定义的封装的默认BitStringLength值为256。有关默认BitStringLength值的讨论，请参见[RFC8279]的第3节。
As stated in [RFC8279], when a BIER domain is also an IGP domain, IGP extensions can be used by each BFR to advertise the BFR-id and BFR-prefix. The extensions for OSPF are given in [OSPF_BIER_EXTENSIONS]. The extensions for IS-IS are given in [ISIS_BIER_EXTENSIONS].
如[RFC8279]所述，当BIER域也是IGP域时，每个BFR都可以使用IGP扩展来公布BFR id和BFR前缀。OSPF的扩展在[OSPF_BIER_extensions]中给出。IS-IS的扩展在[ISIS\u BIER\u扩展]中给出。
When a particular BIER domain is both an IGP domain and an MPLS network, we assume that each BFR will also use IGP extensions to advertise a set of one or more "BIER-MPLS" labels. When the domain contains a single SD, a given BFR needs to advertise one such label for each combination of SI and BSL. If the domain contains multiple SDs, a BFR needs to advertise one such label per SI per BSL for each SD.
当特定BIER域既是IGP域又是MPLS网络时，我们假设每个BFR也将使用IGP扩展来宣传一组或多个“BIER-MPLS”标签。当域包含单个SD时，给定的BFR需要为SI和BSL的每个组合发布一个这样的标签。如果域包含多个SDs，BFR需要为每个SDs每SI每BSL发布一个这样的标签。
In some environments, the only routing protocol in a BIER domain might be BGP; in this case, the BGP extensions described in [BGP_BIER_EXTENSIONS] can be used to advertise the necessary set of BIER-MPLS labels.
在某些环境中，BIER域中唯一的路由协议可能是BGP；在这种情况下，[BGP_BIER_extensions]中描述的BGP扩展可用于宣传必要的BIER-MPLS标签集。
The BIER-MPLS labels are locally significant (i.e., unique only to the BFR that advertises them) downstream-assigned MPLS labels. Penultimate hop popping [RFC3031] MUST NOT be applied to a BIER-MPLS label.
BIER-MPLS标签在下游分配的MPLS标签中具有局部重要性（即，仅对播发它们的BFR唯一）。倒数第二跳弹出[RFC3031]不得应用于BIER-MPLS标签。
Suppose, for example, that there is a single SD (the default SD), that the network is using a BSL of 256, and that all BFERs in the SD have BFR-ids in the range [1,512]. Since each BIER BitString is 256 bits long, this requires the use of two SIs: SI=0 and SI=1. So each BFR will advertise, via IGP extensions, two MPLS labels for BIER: one corresponding to SI=0 and one corresponding to SI=1. The advertisements of these labels will also bind each label to the default SD and to BSL 256.
例如，假设存在单个SD（默认SD），网络使用的BSL为256，并且SD中的所有BFER的BFR ID都在范围[1512]内。由于每个BIER位字符串的长度为256位，因此需要使用两个SIs:SI=0和SI=1。因此，每个BFR将通过IGP扩展为BIER发布两个MPLS标签：一个对应于SI=0，另一个对应于SI=1。这些标签的广告还将每个标签绑定到默认SD和BSL 256。
As another example, suppose a particular BIER domain contains two SDs (SD 0 and SD 1), supports two BSLs (256 and 512), and contains 1024 BFRs. A BFR that is provisioned for both SDs, and that supports both BSLs, would have to advertise the following set of BIER-MPLS labels:
作为另一个示例，假设一个特定的BIER域包含两个SDs（SD0和SD1），支持两个BSL（256和512），并包含1024个BFR。为两个SDs提供且支持两个BSL的BFR必须公布以下BIER-MPLS标签集：
L1: corresponding to SD 0, BSL 256, SI 0.
L1：对应于SD 0、BSL 256、SI 0。
L2: corresponding to SD 0, BSL 256, SI 1.
L2：对应于SD 0、BSL 256、SI 1。
L3: corresponding to SD 0, BSL 256, SI 2.
L3：对应于SD 0、BSL 256、SI 2。
L4: corresponding to SD 0, BSL 256, SI 3.
L4：对应于SD 0、BSL 256、SI 3。
L5: corresponding to SD 0, BSL 512, SI 0.
L5：对应于SD 0、BSL 512、SI 0。
L6: corresponding to SD 0, BSL 512, SI 1.
L6：对应于SD 0、BSL 512、SI 1。
L7: corresponding to SD 1, BSL 256, SI 0.
L7：对应于SD 1、BSL 256、SI 0。
L8: corresponding to SD 1, BSL 256, SI 1.
L8：对应于SD 1、BSL 256、SI 1。
L9: corresponding to SD 1, BSL 256, SI 2.
L9：对应于SD 1、BSL 256、SI 2。
L10: corresponding to SD 1, BSL 256, SI 3.
L10：对应于SD 1、BSL 256、SI 3。
L11: corresponding to SD 1, BSL 512, SI 0.
L11：对应于SD 1、BSL 512、SI 0。
L12: corresponding to SD 1, BSL 512, SI 1.
L12：对应于SD 1、BSL 512、SI 1。
The above example should not be taken as implying that the BFRs need to advertise 12 individual labels. For instance, instead of advertising a label for <SD 1, BSL 512, SI 0> and a label for <SD 1, BSL 512, SI 1>, a BFR could advertise a contiguous range of labels (in this case, a range containing exactly two labels) corresponding to <SD 1, BSL 512>. The first label in the range could correspond to SI 0, and the second to SI 1. The precise mechanism for generating and forming the advertisements is outside the scope of this document; see [OSPF_BIER_EXTENSIONS] and [ISIS_BIER_EXTENSIONS].
上述示例不应被视为暗示BFR需要宣传12个单独的标签。例如，BFR不必为<SD 1，BSL 512，SI 0>的标签和<SD 1，BSL 512，SI 1>的标签做广告，而是可以为与<SD 1，BSL 512>相对应的连续标签范围（在这种情况下，正好包含两个标签的范围）做广告。范围中的第一个标签可能对应于SI 0，第二个标签对应于SI 1。生成和形成广告的确切机制不在本文件范围内；请参阅[OSPF_BIER_扩展]和[ISIS_BIER_扩展]。
The BIER-MPLS label corresponding to a particular combination of SD, SI, and BSL is interpreted as representing the BIFT that corresponds to that same combination of SD, SI, and BSL. That is, the BIER-MPLS label performs the function of a BIFT-id. This label value is carried in the BIFT-id field of the BIER encapsulation.
对应于SD、SI和BSL的特定组合的BIER-MPLS标签被解释为表示对应于SD、SI和BSL的相同组合的BIFT。也就是说，BIER-MPLS标签执行BIFT-id的功能。该标签值携带在BIER封装的BIFT id字段中。
It is crucial to understand that in an MPLS network the first four octets of the BIER encapsulation header are also the last four octets of the MPLS header. Therefore, any prior MPLS label stack entries MUST have the S bit (see [RFC3032]) clear (i.e., the S bit must be 0).
必须了解，在MPLS网络中，BIER封装头的前四个八位字节也是MPLS头的最后四个八位字节。因此，任何先前的MPLS标签堆栈项必须清除S位（参见[RFC3032]）（即S位必须为0）。
When a BFR receives an MPLS packet and the next label to be processed is one of its BIER-MPLS labels, it will assume that the remainder of the BIER header (see Section 2.1.2) immediately follows the stack.
当BFR收到MPLS数据包且下一个要处理的标签是其BIER-MPLS标签之一时，它将假定BIER报头的其余部分（见第2.1.2节）紧跟在堆栈之后。
Note that in practice, labels only have to be assigned if they are going to be used. If a particular BIER domain supports BSLs 256 and 512, but some SD, say SD 1, only uses BSL 256, then it is not necessary to assign labels that correspond to the combination of SD 1 and BSL 512.
请注意，在实践中，仅当要使用标签时才需要指定标签。如果特定BIER域支持BSL256和512，但某些SD（如SD1）仅使用BSL256，则无需分配对应于SD1和BSL512组合的标签。
TC:
TC:
The "Traffic Class" field [RFC5462] has its usual meaning in an MPLS label stack entry.
“流量类别”字段[RFC5462]在MPLS标签堆栈条目中有其通常的含义。
S bit:
S位：
When a BIER packet is traveling through an MPLS network, the high-order 20 bits of the initial four octets of the BIER encapsulation contain an MPLS label in the BIFT-id field. These four octets are treated as the final entry in the packet's MPLS label stack. Hence, the S bit (see [RFC3032]) MUST be set to 1. If there are any MPLS label stack entries immediately preceding the BIER encapsulation, the S bit of those label stack entries MUST be set to 0.
当BIER数据包通过MPLS网络时，BIER封装的初始四个八位字节的高阶20位在BIFT id字段中包含MPLS标签。这四个八位字节被视为数据包的MPLS标签堆栈中的最终条目。因此，S位（参见[RFC3032]）必须设置为1。如果BIER封装之前有任何MPLS标签堆栈项，则这些标签堆栈项的S位必须设置为0。
TTL:
TTL：
This is the usual MPLS "Time to Live" field [RFC3032]. When a BIER packet is received, its "incoming TTL" (see below) is taken from this TTL field.
这是通常的MPLS“生存时间”字段[RFC3032]。当收到BIER数据包时，其“传入TTL”（见下文）取自该TTL字段。
When a BIER packet is forwarded to one or more BFR adjacencies, the BIER-MPLS label carried by the forwarded packet MUST have a TTL field whose value is one less than that of the packet's incoming TTL.
当BIER数据包转发到一个或多个BFR邻接处时，转发数据包携带的BIER-MPLS标签必须有一个TTL字段，其值比数据包的传入TTL值小一个。
If a BIER packet's incoming TTL is 1 or greater and one of the bits in its BitString identifies the current BFR, then the current BFR is a BFER for the packet. Therefore, the current BFR MUST process the packet as a BFER, e.g., by removing the BIER encapsulation and processing the payload based on the contents of the Proto (Next Protocol) field.
如果BIER数据包的传入TTL为1或更大，并且其位字符串中的一个位标识当前BFR，则当前BFR是该数据包的BFER。因此，当前BFR必须将数据包作为BFER进行处理，例如，通过移除BIER封装并基于Proto（下一协议）字段的内容处理有效负载。
If the incoming TTL is 0, the packet is considered to be "expired". If the incoming TTL is 1 and the BitString has a bit set that does not identify the current BFR, the packet is also considered to be expired. Expired packets SHOULD be passed to an error-handling procedure. (Optional implementation-specific rate limiting may be applied to control the rate at which packets are passed to the error-handling procedure.) Specification of the error-handling procedure is outside the scope of this document.
如果传入TTL为0，则认为该数据包已“过期”。如果传入的TTL为1，且位字符串的位集不标识当前BFR，则该数据包也被视为已过期。过期的数据包应传递给错误处理过程。（可选的特定于实现的速率限制可用于控制数据包传递到错误处理过程的速率。）错误处理过程的规范不在本文档的范围内。
Note that if a received BIER packet has an incoming TTL of 1 and its BitString has a bit set identifying the current BFR, the payload MUST be processed by the current BFR, but the packet MUST NOT be forwarded further, and the packet SHOULD also be passed to the error-handling procedures for expired packets (subject to any implementation-specific rate limiting).
请注意，如果接收到的BIER数据包的传入TTL为1，且其位字符串具有标识当前BFR的位集，则有效负载必须由当前BFR处理，但该数据包不得进一步转发，并且该数据包还应传递给过期数据包的错误处理过程（根据任何具体实施的费率限制）。
Nibble:
小口咬：
This field is set to the binary value 0101; this ensures that the MPLS ECMP logic will not confuse the remainder of the BIER header with an IP header or with the header of a pseudowire packet. In an MPLS network, if a BFR receives a BIER packet with any other value in the first nibble after the label stack, it SHOULD discard the packet and log an error.
该字段设置为二进制值0101；这确保MPLS ECMP逻辑不会将BIER报头的其余部分与IP报头或伪线数据包的报头混淆。在MPLS网络中，如果BFR在标签堆栈后的第一个半字节中接收到一个BIER数据包，它应该丢弃该数据包并记录一个错误。
Ver:
版本：
This 4-bit field identifies the version of the BIER header. This document specifies version 0 of the BIER header. If a packet is received by a particular BFR and that BFR does not support the specified version of the BIER header, the BFR MUST discard the packet and log an error.
此4位字段标识BIER标头的版本。此文档指定BIER标头的版本0。如果特定BFR接收到数据包，且该BFR不支持BIER报头的指定版本，则BFR必须丢弃该数据包并记录错误。
The value 0xF is reserved for experimental use; that value MUST NOT be assigned by any future IETF document or by IANA.
0xF值保留供实验使用；该值不得由任何未来的IETF文件或IANA分配。
BSL:
BSL：
This 4-bit field encodes the length in bits of the BitString.
此4位字段以位为单位对位字符串的长度进行编码。
Note: When parsing the BIER header, a BFR MUST infer the length of the BitString from the BIFT-id and MUST NOT infer it from the value of this field. This field is present only to enable offline tools (such as LAN analyzers) to parse the BIER header.
注意：在解析BIER头时，BFR必须从BIFT id推断出位字符串的长度，而不能从该字段的值推断出来。此字段仅用于启用脱机工具（如LAN分析器）来解析BIER标头。
If k is the length of the BitString, the value of this field is log2(k)-5. However, only certain values are supported:
如果k是位字符串的长度，则此字段的值为log2（k）-5。但是，仅支持某些值：
1: 64 bits
1:64位
2: 128 bits
2:128位
3: 256 bits
3:256位
4: 512 bits
4:512位
5: 1024 bits
5:1024位
6: 2048 bits
6:2048位
7: 4096 bits
7:4096位
The value of this field MUST NOT be set to any value other than those listed above. A received packet containing another value in this field SHOULD be discarded and an error logged. If the value in this field is other than what is expected based on the BIER-MPLS label, the packet SHOULD be discarded and an error logged.
此字段的值不得设置为除上述值以外的任何值。应丢弃接收到的包含此字段中另一个值的数据包，并记录错误。如果此字段中的值与基于BIER-MPLS标签的预期值不同，则应丢弃数据包并记录错误。
Entropy:
熵：
This 20-bit field specifies an "entropy" value that can be used for load-balancing purposes. The BIER forwarding process may do equal-cost load balancing, in which case the load-balancing procedure MUST choose the same path for any two packets that have the same entropy value and the same BitString. Please see Section 6.7 ("Equal-Cost Multipath Forwarding") of [RFC8279] for a more detailed discussion of BIER load-balancing procedures.
此20位字段指定可用于负载平衡目的的“熵”值。BIER转发过程可以进行等成本负载平衡，在这种情况下，负载平衡过程必须为具有相同熵值和相同比特串的任何两个数据包选择相同的路径。有关BIER负载平衡程序的更详细讨论，请参见[RFC8279]第6.7节（“等成本多路径转发”）。
If a BFIR is encapsulating (as the payload) MPLS packets that have entropy labels, the BFIR MUST ensure that if two such packets have the same MPLS entropy label they also have the same value of the BIER entropy field.
如果BFIR正在封装（作为有效负载）具有熵标签的MPLS数据包，则BFIR必须确保如果两个这样的数据包具有相同的MPLS熵标签，则它们也具有相同的BIER熵字段值。
OAM:
OAM：
By default, these two bits are set to 0 by the BFIR and are not modified by other BFRs. These two bits have no effect on the path taken by a BIER packet and have no effect on the quality of service applied to a BIER packet.
默认情况下，这两个位由BFIR设置为0，不由其他BFR修改。这两个位对BIER数据包所采用的路径没有影响，并且对应用于BIER数据包的服务质量没有影响。
The use of these bits in other than the default manner is OPTIONAL. Specification of the non-default use or uses of these bits is outside the scope of this document; see [BIER-PMM] for an example of such a specification.
以默认方式以外的方式使用这些位是可选的。这些比特的非默认使用规范不在本文件范围内；有关此类规范的示例，请参见[BIER-PMM]。
Rsv:
Rsv:
These two bits are currently unused. They SHOULD be set to 0 upon transmission and MUST be ignored upon reception.
这两个位当前未使用。它们在传输时应设置为0，在接收时必须忽略。
DSCP:
DSCP：
By default, this 6-bit field is not used in MPLS networks. The default behavior is that all six bits SHOULD be set to 0 upon transmission and MUST be ignored upon reception.
默认情况下，此6位字段不用于MPLS网络。默认情况下，传输时所有六位都应设置为0，接收时必须忽略。
Non-default use of this field in MPLS networks is outside the scope of this document.
此字段在MPLS网络中的非默认使用超出了本文档的范围。
Proto:
原型：
This 6-bit "Next Protocol" field identifies the type of the payload. (The "payload" is the packet or frame immediately following the BIER header.) IANA has created a registry called "BIER Next Protocol Identifiers". This field is to be populated with the appropriate entry from that registry.
此6位“下一个协议”字段标识有效负载的类型。（有效载荷是紧跟在BIER头之后的数据包或帧。）IANA创建了一个名为“BIER下一个协议标识符”的注册表。此字段将由该注册表中的相应条目填充。
If a BFER receives a BIER packet but does not recognize (or does not support) the value of the Next Protocol field, the BFER SHOULD discard the packet and log an error.
如果BFER收到BIER数据包，但不识别（或不支持）下一个协议字段的值，则BFER应丢弃该数据包并记录错误。
BFIR-id:
BFIR id:
By default, this is the BFR-id of the BFIR, in the SD to which the packet has been assigned. The BFR-id is encoded in the 16-bit field as an unsigned integer in the range [1,65535].
默认情况下，这是数据包已分配到的SD中BFIR的BFR id。BFR id在16位字段中编码为[165535]范围内的无符号整数。
Certain applications may require that the BFIR-id field contain the BFR-id of a BFR other than the BFIR. However, that usage of the BFIR-id field is outside the scope of this document.
某些应用程序可能要求BFIR id字段包含除BFIR之外的BFR的BFR id。但是，BFIR id字段的使用超出了本文档的范围。
BitString:
位字符串：
This field holds the BitString that, together with the packet's SI and SD, identifies the destination BFERs for this packet. Note that the SI and SD for the packet are not carried explicitly in the BIER header, as a particular BIFT-id always corresponds to a particular SI and SD.
此字段包含位字符串，该位字符串与数据包的SI和SD一起标识该数据包的目标BFER。请注意，由于特定的BIFT id始终对应于特定的SI和SD，因此数据包的SI和SD没有在BIER报头中明确携带。
Sending a BIER packet from one BFR to another may require the packet to be further encapsulated. For example, in some scenarios it may be necessary to encapsulate a BIER packet in an Ethernet frame; in other scenarios it may be necessary to encapsulate a BIER packet in a UDP packet. In such cases, the BIER packet itself is the payload of an "outer" encapsulation.
从一个BFR向另一个BFR发送BIER数据包可能需要进一步封装该数据包。例如，在一些场景中，可能需要将BIER分组封装在以太网帧中；在其他情况下，可能需要将BIER数据包封装在UDP数据包中。在这种情况下，BIER数据包本身就是“外部”封装的有效负载。
In this document, we assume that the frame or packet carrying a BIER packet as its payload is a unicast frame or packet. That is, although a BIER packet is a multicast packet, we assume that the frame or packet carrying the BIER packet as its payload is unicast from one BFR to the next.
在本文中，我们假设承载BIER分组作为其有效载荷的帧或分组是单播帧或分组。也就是说，尽管BIER分组是多播分组，但我们假设承载BIER分组作为其有效载荷的帧或分组是从一个BFR单播到下一个BFR的。
Generally, the outer encapsulation has a codepoint identifying the "next protocol". The outer encapsulation's "next protocol" codepoint for MPLS MUST be used. If a particular outer encapsulation has a codepoint for "MPLS with downstream-assigned label" and a different codepoint for "MPLS with upstream-assigned label", the codepoint for "MPLS with downstream-assigned label" MUST be used.
通常，外部封装具有标识“下一个协议”的代码点。必须使用外部封装的MPLS“下一个协议”代码点。如果特定的外部封装具有用于“具有下游分配标签的MPLS”的代码点和用于“具有上游分配标签的MPLS”的不同代码点，则必须使用用于“具有下游分配标签的MPLS”的代码点。
For example, if a BIER packet is encapsulated in an Ethernet frame, the Ethertype MUST be 0x8847 [RFC5332], which is the Ethertype for a unicast Ethernet frame that carries an MPLS packet whose label stack begins with a downstream-assigned label.
例如，如果BIER数据包封装在以太网帧中，则Ethertype必须为0x8847[RFC5332]，这是单播以太网帧的Ethertype，该帧承载的MPLS数据包的标签堆栈以下游分配的标签开始。
In the special case where the outer encapsulation is MPLS, the outer encapsulation has no "next protocol" codepoint. All that is needed to encapsulate the BIER packet is to push more MPLS label stack entries (with the S bit clear) on the BIER packet's label stack.
在外部封装为MPLS的特殊情况下，外部封装没有“下一个协议”码点。封装BIER数据包所需的只是在BIER数据包的标签堆栈上推送更多的MPLS标签堆栈条目（S位清除）。
If two BIER packets have the same value in the entropy field of their respective BIER headers and if both are placed in an outer encapsulation, it is desirable for the outer encapsulation to preserve the fact that the two packets have the same entropy. If the outer encapsulation is MPLS and if the MPLS entropy label [RFC6790] is in use in a given deployment, one way to do this is to copy the value of the BIER header entropy field into an MPLS entropy label.
如果两个BIER分组在其各自BIER报头的熵字段中具有相同的值，并且如果两个BIER分组都被放置在外封装中，则期望外封装保持两个分组具有相同熵的事实。如果外部封装是MPLS，并且如果MPLS熵标签[RFC6790]在给定部署中使用，则执行此操作的一种方法是将BIER标头熵字段的值复制到MPLS熵标签中。
In non-MPLS networks, a BIFT-id MUST be assigned for every combination of <SD, SI, BSL> that is to be used in that network. The correspondence between a BIFT-id and a particular <SD, SI, BSL> triple is unique throughout the BIER domain and is known to all the BFRs in the BIER domain.
在非MPLS网络中，必须为要在该网络中使用的<SD，SI，BSL>的每个组合分配BIFT id。BIFT id和特定<SD，SI，BSL>三元组之间的对应关系在整个BIER域中是唯一的，并且BIER域中的所有BFR都知道。
The means by which the BIFT-ids are assigned, and the means by which these assignments are made known to the BFRs, are outside the scope of this document.
BIFT ID的分配方式以及BFR了解这些分配方式不在本文件范围内。
In an MPLS network, since the BIFT-id is an MPLS label, its value may be changed as a BIER packet goes from BFR to BFR. In a non-MPLS network, since the BIFT-id is domain-wide unique, it is not expected to change as a BIER packet travels.
在MPLS网络中，由于BIFT id是MPLS标签，因此当BIER数据包从BFR传输到BFR时，其值可能会发生变化。在非MPLS网络中，由于BIFT id是全域唯一的，因此预计不会随着BIER数据包的移动而改变。
TC:
TC:
By default, the TC field has no significance in a non-MPLS network. The default behavior is that this field SHOULD be set to the binary value 000 upon transmission and MUST be ignored upon reception.
默认情况下，TC字段在非MPLS网络中没有意义。默认行为是，该字段在传输时应设置为二进制值000，在接收时必须忽略。
Non-default use of this field in non-MPLS networks is outside the scope of this document.
在非MPLS网络中非默认使用此字段不在本文档范围内。
S bit:
S位：
The S bit has no significance in a non-MPLS network. It SHOULD be set to 1 upon transmission, but it MUST be ignored upon reception.
S位在非MPLS网络中没有意义。传输时应设置为1，但接收时必须忽略。
TTL:
TTL：
This is the BIER "Time to Live" field. Its purpose is to prevent BIER packets from looping indefinitely in the event of improper operation of the control plane. When a BIER packet is received, its "incoming TTL" (see below) is taken from this TTL field.
这是BIER“生存时间”字段。其目的是防止BIER数据包在控制平面操作不当的情况下无限循环。当收到BIER数据包时，其“传入TTL”（见下文）取自该TTL字段。
The effect of this field on the processing of a BIER packet is described in Section 2.1.1.2.
第2.1.1.2节描述了该字段对BIER数据包处理的影响。
Nibble:
小口咬：
This field SHOULD be set to 0000 upon transmission but MUST be ignored upon reception.
此字段在传输时应设置为0000，但在接收时必须忽略。
Ver:
版本：
See Section 2.1.2.
见第2.1.2节。
BSL:
BSL：
See Section 2.1.2.
见第2.1.2节。
Entropy:
熵：
See Section 2.1.2.
见第2.1.2节。
OAM:
OAM：
See Section 2.1.2.
见第2.1.2节。
Rsv:
Rsv:
See Section 2.1.2.
见第2.1.2节。
DSCP:
DSCP：
This 6-bit field MAY be used to hold a Differentiated Services Codepoint [RFC2474]. The significance of this field is outside the scope of this document.
此6位字段可用于保存区分服务代码点[RFC2474]。此字段的意义不在本文件范围内。
Proto:
原型：
See Section 2.1.2.
见第2.1.2节。
BFIR-id:
BFIR id:
See Section 2.1.2.
见第2.1.2节。
BitString:
位字符串：
See Section 2.1.2.
见第2.1.2节。
Sending a BIER packet from one BFR to another may require the packet to be further encapsulated. For example, in some scenarios it may be necessary to encapsulate a BIER packet in an Ethernet frame; in other scenarios it may be necessary to encapsulate a BIER packet in a UDP packet. In such cases, the BIER packet itself is the payload of an "outer" encapsulation.
从一个BFR向另一个BFR发送BIER数据包可能需要进一步封装该数据包。例如，在一些场景中，可能需要将BIER分组封装在以太网帧中；在其他情况下，可能需要将BIER数据包封装在UDP数据包中。在这种情况下，BIER数据包本身就是“外部”封装的有效负载。
In this document, we assume that the frame or packet carrying a BIER packet as its payload is a unicast frame or packet. That is, although a BIER packet is a multicast packet, we assume that the frame or packet carrying the BIER packet as its payload is unicast from one BFR to the next.
在本文中，我们假设承载BIER分组作为其有效载荷的帧或分组是单播帧或分组。也就是说，尽管BIER分组是多播分组，但我们假设承载BIER分组作为其有效载荷的帧或分组是从一个BFR单播到下一个BFR的。
Generally, the outer encapsulation has a codepoint identifying the "next protocol". This codepoint MUST be set to a value that means "non-MPLS BIER". In particular, a codepoint that means "MPLS" (with either upstream-assigned or downstream-assigned labels) MUST NOT be used.
通常，外部封装具有标识“下一个协议”的代码点。此代码点必须设置为表示“非MPLS BIER”的值。特别是，不得使用表示“MPLS”（具有上游分配或下游分配的标签）的代码点。
By requiring the use of a distinct codepoint for "non-MPLS BIER", we allow for deployment scenarios where non-MPLS BIER can coexist with non-BIER MPLS. The BIFT-id values used by the former will not conflict with MPLS label values used by the latter.
通过要求对“非MPLS BIER”使用不同的代码点，我们允许非MPLS BIER可以与非MPLS共存的部署场景。前者使用的BIFT id值不会与后者使用的MPLS标签值冲突。
Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332]. IEEE has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
因此，如果非MPLS BIER数据包封装在以太网报头中，则以太网类型不得为0x8847或0x8848[RFC5332]。IEEE已为非MPLS BIER数据包分配Ethertype 0xAB37。
In the special case where the outer encapsulation is MPLS, the outer encapsulation has no "next protocol" codepoint. If it is necessary to use MPLS as an outer encapsulation for BIER packets, it is RECOMMENDED to use the MPLS encapsulation for BIER. Procedures for encapsulating a non-MPLS BIER packet in MPLS are outside the scope of this document.
在外部封装为MPLS的特殊情况下，外部封装没有“下一个协议”码点。如果需要使用MPLS作为BIER数据包的外部封装，建议使用MPLS封装BIER。在MPLS中封装非MPLS BIER数据包的过程超出了本文档的范围。
If two BIER packets have the same value in the entropy field of their respective BIER headers and if both are placed in an outer encapsulation, it is desirable for the outer encapsulation to preserve the fact that the two packets have the same entropy.
如果两个BIER分组在其各自BIER报头的熵字段中具有相同的值，并且如果两个BIER分组都被放置在外封装中，则期望外封装保持两个分组具有相同熵的事实。
Each BFIR is expected to know the Maximum Transmission Unit (MTU) of the BIER domain. This may be known by provisioning, or by some other method outside the scope of this document. Each BFIR also knows the size of the BIER encapsulation. Thus, each BFIR can deduce the maximum size of the payload that can be encapsulated in a BIER packet. We will refer to this payload size as the BIER-MTU.
每个BFIR应知道BIER域的最大传输单位（MTU）。这可以通过设置或本文档范围之外的其他方法来了解。每个BFIR还知道BIER封装的大小。因此，每个BFIR可以推断出可以封装在BIER数据包中的有效负载的最大大小。我们将此有效负载大小称为BIER-MTU。
If a BFIR receives a multicast packet from outside the BIER domain and the packet size exceeds the BIER-MTU, the BFIR takes whatever action is appropriate to take when receiving a multicast packet that is too large to be forwarded to all its next hops. If the appropriate action is to drop the packet and advertise an MTU to the source, then the BFIR drops the packet and advertises the BIER-MTU. If the appropriate action is to fragment the packet, then the procedures of this section are applied, in sequence, to each fragment.
如果BFIR从BIER域外部接收到多播数据包，且数据包大小超过BIER-MTU，则BFIR在接收到太大而无法转发到其所有下一跳的多播数据包时，将采取任何适当的措施。如果适当的操作是丢弃数据包并向源播发MTU，则BFIR丢弃数据包并播发BIER-MTU。如果适当的操作是对数据包进行分段，则本节中的过程将按顺序应用于每个分段。
When a BFIR processes a multicast packet (or fragment thereof) from outside the BIER domain, the BFIR carries out the following procedure:
当BFIR处理来自BIER域外部的多播分组（或其片段）时，BFIR执行以下过程：
1. By consulting the "multicast flow overlay" [RFC8279], it determines the value of the Proto field.
1. 通过查阅“多播流覆盖”[RFC8279]，它确定Proto字段的值。
2. By consulting the multicast flow overlay, it determines the set of BFERs that must receive the packet.
2. 通过查询多播流覆盖，它确定必须接收数据包的BFER集。
3. If more than one SD is supported, the BFIR assigns the packet to a particular SD. Procedures for determining the SD to which a particular packet should be assigned are outside the scope of this document.
3. 如果支持多个SD，BFIR将数据包分配给特定SD。确定特定数据包应分配到的SD的程序不在本文件的范围内。
4. The BFIR looks up the BFR-id, in the given SD, of each of the BFERs.
4. BFIR在给定SD中查找每个BFER的BFR id。
5. The BFIR converts each such BFR-id into "SI:BitString" format, as described in [RFC8279].
5. BFIR将每个这样的BFR id转换为“SI:BitString”格式，如[RFC8279]中所述。
6. All such BFR-ids that have the same SI can be encoded into the same BitString. Details of this encoding can be found in [RFC8279]. For each distinct SI that occurs in the list of the packet's destination BFERs:
6. 具有相同SI的所有此类BFR ID都可以编码到相同的位字符串中。此编码的详细信息可在[RFC8279]中找到。对于数据包目的地BFER列表中出现的每个不同SI：
a. The BFIR makes a copy of the multicast data packet and encapsulates the copy in a BIER header (see Section 2). The BIER header contains the BitString that represents all the destination BFERs whose BFR-ids (in the given SD) correspond to the given SI. It also contains the BFIR's BFR-id in the SD to which the packet has been assigned.
a. BFIR制作多播数据包的副本，并将副本封装在BIER报头中（参见第2节）。BIER标头包含表示其BFR ID（在给定SD中）对应于给定SI的所有目标BFER的位字符串。它还包含已分配数据包的SD中的BFIR的BFR id。
Note well that for certain applications it may be necessary for the BFIR-id field to contain the BFR-id of a BFR other than the BFIR that is creating the header. Such uses are outside the scope of this document.
请注意，对于某些应用程序，BFIR id字段可能需要包含BFR的BFR id，而不是创建标头的BFIR。此类用途不在本文件范围内。
b. The BFIR then applies to that copy the forwarding procedure of [RFC8279]. This may result in one or more copies of the packet (possibly with a modified BitString) being transmitted to a neighboring BFR.
b. 然后，BFIR将[RFC8279]的转发过程应用于该副本。这可能导致分组的一个或多个副本（可能具有修改的比特串）被传输到相邻的BFR。
c. If the non-MPLS BIER encapsulation is being used, the BIFT-id field is set to the BIFT-id that corresponds to the packet's <SD, SI, BSL>. The TTL is set according to policy.
c. 如果使用非MPLS BIER封装，则BIFT id字段设置为与数据包的<SD，SI，BSL>相对应的BIFT id。TTL是根据策略设置的。
If the MPLS BIER encapsulation is being used, the BFIR finds the BIER-MPLS label that was advertised by the neighbor as corresponding to the given <SD, SI, BSL>. An MPLS label stack is then prepended to the packet. This label stack [RFC3032] will contain one label -- the aforementioned BIER-MPLS label. The S bit MUST be set, indicating the end of the MPLS label stack. The TTL field of this label stack entry is set according to policy.
如果正在使用MPLS BIER封装，BFIR将查找邻居发布的BIER-MPLS标签，该标签对应于给定的<SD，SI，BSL>。然后将MPLS标签堆栈添加到数据包之前。此标签堆栈[RFC3032]将包含一个标签——前面提到的BIER-MPLS标签。必须设置S位，指示MPLS标签堆栈的结束。此标签堆栈项的TTL字段是根据策略设置的。
d. The packet may then be transmitted to the neighboring BFR. (In an MPLS network, this may result in additional MPLS labels being pushed on the stack. For example, if an RSVP-TE tunnel is used to transmit packets to the neighbor, a label representing that tunnel would be pushed onto the stack.)
d. 然后，该分组可以被发送到相邻的BFR。（在MPLS网络中，这可能会导致额外的MPLS标签被推送到堆栈上。例如，如果使用RSVP-TE隧道将数据包传输到邻居，则表示该隧道的标签将被推送到堆栈上。）
When an intermediate BFR is processing a received MPLS packet and one of the BFR's own BIER-MPLS labels rises to the top of the label stack, the BFR infers the BSL from the label. The SI and SD are also implicitly identified by the label. The BFR then follows the forwarding procedures of [RFC8279]. If it forwards a copy of the packet to a neighboring BFR, it first swaps the label at the top of the label stack with the BIER-MPLS label, advertised by that
当中间BFR正在处理接收到的MPLS数据包，并且BFR自己的BIER-MPLS标签之一上升到标签堆栈的顶部时，BFR从标签推断BSL。SI和SD也由标签隐式标识。然后，BFR遵循[RFC8279]的转发过程。如果它将数据包的副本转发给相邻的BFR，它首先将标签堆栈顶部的标签与BIER-MPLS标签交换，该标签由该BFR播发
neighbor, that corresponds to the same <SD, SI, BSL>. Note that when this swap operation is done, the TTL field of the BIER-MPLS label of the outgoing packet MUST be one less than the "incoming TTL" of the packet, as defined in Section 2.1.1.2.
邻居，对应于相同的<SD，SI，BSL>。注意，当交换操作完成时，输出数据包的BIER-MPLS标签的TTL字段必须比第2.1.1.2节中定义的数据包的“输入TTL”小一个。
When an intermediate BFR is processing a received non-MPLS BIER packet, the BFR infers the BSL from the BIFT-id. The SI and SD are also implicitly identified by the BIFT-id. The BFR then follows the forwarding procedures of [RFC8279].
当中间BFR处理接收到的非MPLS BIER数据包时，BFR根据BIFT-id推断BSL。SI和SD也由BIFT-id隐式标识。然后，BFR遵循[RFC8279]的转发过程。
If the BIER payload is an MPLS packet, the BIER header is followed by an MPLS label stack. This stack is separate from any MPLS stack that may precede the BIER header. For an example of an application where it is useful to carry an MPLS packet as the BIER payload, see [BIER_MVPN]. If the BIER encapsulation's Proto field indicates that the payload is an MPLS packet with an upstream-assigned label at the top of the stack, the upstream-assigned label is interpreted in the context of <BFIR-id, sub-domain-id>. Note that the sub-domain-id must be inferred from the BIFT-id.
如果BIER有效负载是MPLS数据包，BIER报头后面跟着一个MPLS标签堆栈。此堆栈与BIER头之前的任何MPLS堆栈是分开的。有关将MPLS数据包作为BIER有效载荷的应用示例，请参见[BIER_MVPN]。如果BIER封装的Proto字段指示有效负载是一个MPLS数据包，在堆栈顶部有一个上游分配的标签，则在<BFIR id，sub-domain id>的上下文中解释上游分配的标签。请注意，必须从BIFT-id推断子域id。
IANA has set up a registry called "BIER Next Protocol Identifiers". The registration policy for this registry is "IETF Review" [RFC8126] [RFC7120].
IANA已经建立了一个名为“BIER下一个协议标识符”的注册表。此注册表的注册策略为“IETF审查”[RFC8126][RFC7120]。
The initial values in the "BIER Next Protocol Identifiers" registry are:
“BIER下一个协议标识符”注册表中的初始值为：
0: Reserved
0:保留
1: MPLS packet with downstream-assigned label at top of stack
1：在堆栈顶部具有下游分配标签的MPLS数据包
2: MPLS packet with upstream-assigned label at top of stack
2：在堆栈顶部具有上游分配标签的MPLS数据包
3: Ethernet frame
3：以太网帧
4: IPv4 packet
4:IPv4数据包
5: OAM packet (Reference: [BIER_PING])
5:OAM数据包（参考：[比尔平]）
6: IPv6 packet
6:IPv6数据包
63: Reserved
63：保留
IEEE has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
IEEE已为非MPLS BIER数据包分配Ethertype 0xAB37。
Insofar as this document makes use of MPLS, it inherits any security considerations that apply to the use of the MPLS data plane.
就本文档使用MPLS而言，它继承了适用于使用MPLS数据平面的所有安全注意事项。
If a BIER encapsulation header is modified in ways other than those specified in [RFC8279] and in this document, packets may be lost, stolen, or otherwise misdelivered. Such modifications are likely to go undetected, as the BIER encapsulation does not provide cryptographic integrity protection.
如果以[RFC8279]和本文件规定以外的方式修改BIER封装头，则数据包可能丢失、被盗或以其他方式误送。由于BIER封装不提供密码完整性保护，此类修改可能无法被检测到。
Layer 2 encryption can be used to ensure that a BIER-encapsulated packet is not altered while in transit between adjacent BFRs. If a BFR itself is compromised, there is no way to prevent the compromised BFR from making illegitimate modifications to the BIER header or to prevent it from misforwarding or misdelivering the BIER-encapsulated packet.
第2层加密可用于确保BIER封装的数据包在相邻BFR之间传输时不会被更改。如果BFR本身受损，则无法防止受损BFR对BIER报头进行非法修改，或防止其错误转发或误发BIER封装的数据包。
If the routing underlay (see Section 4.1 of [RFC8279]) is based on a unicast routing protocol, BIER assumes that the routers participating in the unicast routing protocol have not been compromised. BIER has no procedures to ensure that the unicast routing adjacencies have not been compromised; that falls within the scope of whatever unicast routing protocols are being used.
如果路由参考底图（见[RFC8279]第4.1节）基于单播路由协议，BIER假设参与单播路由协议的路由器未受到损害。BIER没有确保单播路由邻接未被破坏的程序；这属于正在使用的任何单播路由协议的范围。
BIER-encapsulated packets should generally not be accepted from untrusted interfaces or tunnels. For example, an operator may wish to have a policy of accepting BIER-encapsulated packets only from interfaces to trusted routers, and not from customer-facing interfaces.
BIER封装的数据包通常不应从不受信任的接口或隧道中接受。例如，运营商可能希望有一个策略，只接受来自可信路由器接口的BIER封装数据包，而不接受来自面向客户的接口的BIER封装数据包。
There may be applications that require a BFR to accept a BIER-encapsulated packet from an interface to a system that is not controlled by the network operator. For instance, there may be an application in which a virtual machine in a data center submits BIER-encapsulated packets to a router. In such a case, it is desirable to verify that the packet is from a legitimate source and that its BitString denotes only systems to which that source is allowed to send. However, the BIER encapsulation itself does not provide a way to verify that the source is (1) legitimate, (2) really the system denoted by the BFIR-id, or (3) allowed to set any particular set of bits in the BitString.
可能有一些应用程序需要BFR接受BIER封装的数据包，该数据包从一个接口到一个不受网络运营商控制的系统。例如，可能有一个应用程序，其中数据中心中的虚拟机向路由器提交BIER封装的数据包。在这种情况下，希望验证分组是否来自合法源，并且其位字符串仅表示允许该源向其发送的系统。然而，BIER封装本身并没有提供一种方法来验证源是否（1）合法，（2）是否确实是由BFIR id表示的系统，或（3）是否允许设置位字符串中的任何特定位集。
Insofar as this document relies upon IGP extensions, it inherits any security considerations that apply to the IGP.
只要本文档依赖于IGP扩展，它就继承了适用于IGP的所有安全注意事项。
The security considerations of [RFC8279] also apply.
[RFC8279]中的安全注意事项也适用。
[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>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<https://www.rfc-editor.org/info/rfc2474>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，DOI 10.17487/RFC3032，2001年1月<https://www.rfc-editor.org/info/rfc3032>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 5331，DOI 10.17487/RFC5331，2008年8月<https://www.rfc-editor.org/info/rfc5331>.
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>.
[RFC5332]Eckert，T.，Rosen，E.，Ed.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，DOI 10.17487/RFC5332，2008年8月<https://www.rfc-editor.org/info/rfc5332>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，DOI 10.17487/RFC5462，2009年2月<https://www.rfc-editor.org/info/rfc5462>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，DOI 10.17487/RFC7120，2014年1月<https://www.rfc-editor.org/info/rfc7120>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.
[RFC8279]Wijnands，IJ.，Ed.，Rosen，E.，Ed.，Dolganow，A.，Przygienda，T.，和S.Aldrin，“使用位索引显式复制（BIER）的多播”，RFC 8279，DOI 10.17487/RFC8279，2017年11月<https://www.rfc-editor.org/info/rfc8279>.
[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-04, January 2018.
[BGP-BIER-U扩展]Xu，X.，Ed.，Chen，M.，Patel，K.，Wijnands，IJ.，和A.Przygienda，“BIER的BGP扩展”，在建工程，草案-ietf-BIER-idr-EXTENSIONS-042018年1月。
[BIER-PMM] Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Work in Progress, draft-ietf-bier-pmmm-oam-03, October 2017.
[BIER-PMM]Mirsky，G.，Zheng，L.，Chen，M.，和G.Fioccola，“位索引显式复制（BIER）层中带有标记方法的性能测量（PM）”，正在进行的工作，草稿-ietf-BIER-pmmm-oam-032017年10月。
[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月。
[BIER_PING] Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", Work in Progress, draft-ietf-bier-ping-02, July 2017.
[BIER_PING]Kumar，N.，Pignataro，C.，Akiya，N.，Zheng，L.，Chen，M.，和G.Mirsky，“BIER PING和Trace”，正在进行的工作，草案-ietf-BIER-PING-022017年7月。
[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月。
[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-10, December 2017.
[OSPF-BIER-EXTENSIONS]Psenak，P.，Ed.，Kumar，N.，Wijnands，IJ.，Dolganow，A.，Przygienda，T.，Zhang，J.，和S.Aldrin，“用于BIER的OSPF扩展”，正在进行中，草案-ietf-BIER-OSPF-BIER-EXTENSIONS-10，2017年12月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 6790，DOI 10.17487/RFC6790，2012年11月<https://www.rfc-editor.org/info/rfc6790>.
Acknowledgements
致谢
The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, Xiaohu Xu, and Jeffrey Zhang for their ideas and contributions to this work.
作者希望感谢拉吉夫·阿萨蒂、约翰·贝廷克、纳贡德拉·库马尔、克里斯蒂安·马丁、尼尔·兰斯、格雷格·谢泼德、拉姆吉·瓦蒂亚纳森、徐晓虎和杰弗里·张，感谢他们对本书的想法和贡献。
Contributors
贡献者
The following people (listed in alphabetical order) contributed significantly to the content of this document and should be considered co-authors:
以下人员（按字母顺序列出）对本文件的内容做出了重大贡献，应被视为共同作者：
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
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
Tony Przygienda Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, California 94089 United States of America Email: prz@juniper.net
Tony Przygienda Juniper Networks，Inc.美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号94089电子邮件：prz@juniper.net
Authors' Addresses
作者地址
IJsbrand Wijnands (editor) Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com
IJsbrand Wijnands（编辑）Cisco Systems，Inc.De Kleetlaan 6a Diegem 1831比利时电子邮件：ice@cisco.com
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America Email: erosen@juniper.net
Eric C.Rosen（编辑）Juniper Networks，Inc.马萨诸塞州韦斯特福德科技园大道10号美国电子邮件：erosen@juniper.net
Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark Singapore 119968 Singapore Email: andrew.dolganow@nokia.com
Andrew Dolganow诺基亚438B Alexandra路#08-07/10 Alexandra Technopark Singapore 119968新加坡电子邮件：Andrew。dolganow@nokia.com
Jeff Tantsura Individual Email: jefftant.ietf@gmail.com
Jeff Tantsura个人电子邮件：jefftant。ietf@gmail.com
Sam K. Aldrin Google, Inc. 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America Email: aldrin.ietf@gmail.com
Sam K.Aldrin Google，Inc.加利福尼亚州山景大道1600圆形剧场94043美国电子邮件：Aldrin。ietf@gmail.com
Israel Meilik Broadcom Email: israel@broadcom.com
Israel Meilik Broadcom电子邮件：israel@broadcom.com