[要約] RFC 8279は、Bit Index Explicit Replication（BIER）を使用したマルチキャストに関する規格です。BIERは、パケット転送にビットインデックスを使用することで、効率的なマルチキャストを実現します。このRFCの目的は、BIERの仕様と利点を説明し、実装と展開のためのガイドラインを提供することです。
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ヘッダーにはビット文字列が含まれ、各ビットはドメイン内の1つの出力ルーターを表します。パケットを特定の出力ルーターのセットに転送するには、これらのルーターに対応するビットをBIERヘッダーに設定します。このドキュメントでは、BIERヘッダーに基づいてパケットを転送する手順について説明します。フローごとの状態と明示的なツリー構築プロトコルの排除により、かなり単純化されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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ドメインに入り、1つ以上の「ビット転送出力ルーター」（BFER）でBIERドメインを出ます。同じBIERドメイン内の別のBFRからマルチキャストデータパケットを受信し、同じBIERドメイン内の別のBFRにパケットを転送するBFRは、そのパケットの「中継BFR」と呼ばれます。単一のBFRは、一部のマルチキャストトラフィックのBFIRである場合もあれば、一部のマルチキャストトラフィックのBFERであり、一部のマルチキャストトラフィックの中継BFRである場合もあります。実際、所与のパケットについて、ＢＦＲは、ＢＦＩＲおよび／またはトランジットＢＦＲおよび／またはそのパケットの（１つまたは複数の）ＢＦＥＲであってもよい。
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ドメインには、1つ以上のサブドメインが含まれる場合があります。各BIERドメインには、少なくとも1つのサブドメイン、「デフォルトのサブドメイン」（「サブドメイン0」とも呼ばれます）が含まれている必要があります。 BIERドメインに複数のサブドメインが含まれている場合、ドメイン内の各BFRは、それが属するサブドメインのセットを認識するようにプロビジョニングする必要があります。各サブドメインは、[0,255]の範囲のサブドメイン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サブドメインに1,374のBFRが含まれている場合、それぞれに範囲[1,1374]の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 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.
マルチキャストパケットがドメイン外からBFIRに到着すると、BFIRはパケットの送信先となるBFERのセットを決定します。 BFIRは、パケットが送信されるサブドメインも決定します。特定のパケットが送信されるサブドメインを決定することは、「パケットをサブドメインに割り当てる」と呼ばれます。特定のパケットが割り当てられるサブドメインを選択する手順は、このドキュメントの範囲外です。ただし、特定のパケットが特定のサブドメインに割り当てられると、BIERドメインを離れるまで、そのサブドメインに割り当てられたままになります。つまり、パケットがBIERドメインを通過している間は、パケットが割り当てられているサブドメインを変更してはなりません（MUST NOT）。
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ヘッダーのビット文字列フィールドを指すのに「BitString」という用語を使用します。カプセル化されたパケットを指すのに「ペイロード」という用語を使用します。したがって、「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ヘッダーのBitStringの長さによってのみ制限されます。デプロイメントごとに異なるBitStringの長さを使用できます。 「BitStringLength」という用語を使用して、BitStringのビット数を表します。一部の展開では、BitStringのビット数よりも多くのBFERが特定のサブドメインに存在する可能性があります。このケースに対応するため、BIERカプセル化には、BitStringと「Set Identifier」（SI）の両方が含まれています。特定のパケットが配信されるBFERのセットを決定するのは、BitStringとSIです。
o By convention, the least significant (rightmost) bit in the BitString is "bit 1", and the most significant (leftmost) bit is "bit BitStringLength".
o 慣例により、BitStringの最下位（右端）ビットは「ビット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でカプセル化されたパケットのSIがnで、ビットkが設定されたBitStringである場合、パケットは、BFR-id（パケットが割り当てられているサブドメイン内）がn * BitStringLengthであるBFERに配信される必要があります。 + k。
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 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.
たとえば、BIERカプセル化で256ビットのBitStringLengthを使用するとします。慣例により、最下位（右端）ビットはビット1、最上位（左端）ビットはビット256です。特定のパケットがサブドメイン0に割り当てられ、3つのBFERに配信される必要があるとします。 BFERのサブドメイン0には、それぞれ13、126、235のBFR-idがあります。 BFIRは、SIがゼロに設定され、BitStringセットのビット13、126、および235でBIERカプセル化を作成します。 （BitStringの他のすべてのビットはクリアされます。）パケットもBFR-idが257であるBFERに送信する必要がある場合、BFIRはパケットの2番目のコピーを作成する必要があり、BIERカプセル化はSIが1で、ビット1が設定され、他のすべてのビットがクリアされたBitString。
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.
できるだけ多くのBFERを単一のビット文字列で表すことができるように、特定のサブドメインのBFR-idを割り当てることは一般に有利です。
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カプセル化が0のSIとビット13、26、および235が設定されたBitStringを指定するパケットを受信するとします。 BFR-Aに2つのBFRネイバー、BFR-BとBFR-Cがあり、BFER 13と26への最適パスはBFR-Bを経由するが、BFER 235への最適パスはBFR-Cを経由するとします。次にBFR-Aはパケットを複製し、1つのコピーをBFR-Bに、1つのコピーをBFR-Cに送信します。ただし、BFR-Aは、BFR-Bに送信するパケットコピーのBitStringのビット235をクリアし、BFR-Cに送信するパケットコピーのBitStringのビット13および26をクリアします。その結果、BFR-BはBFER 13および26にのみパケットを転送し、BFR-CはBFER 235にのみパケットを転送します。これにより、各BFERがパケットのコピーを1つだけ受信することが保証されます。
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をビットストリング内の単一ビットとしてエンコードするため、単一のBFERのIPv6アドレスを伝送するのに必要なビット数と同じ数で、最大128のBFERを表すことができます。したがって、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 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.
BIERでは、各トランジットBFRがBIERヘッダーで識別される各BFERへの最適なパスを検索する必要はありません。単一のパケットの転送パスで必要なルックアップの数は、隣接する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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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は（必須ではありませんが）サブドメインごとに異なる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プレフィックスは、そのサブドメインでルーティング可能でなければなりません（MUST）。特定の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 ID」（BFR-id）は、[1,65535]の範囲の番号です。特定のサブドメイン内で、BFIRまたはBFERとして機能する必要があるすべてのBFRは、そのサブドメイン内で一意に識別する単一のBFR-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 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.
特定のBFR-idを特定のBFRに割り当てる手順は、このドキュメントの範囲外です。ただし、各サブドメインのBFR-idを番号付けスペースから「密に」割り当てることをお勧めします。これにより、より効率的なエンコーディングが行われます（セクション3を参照）。つまり、BFERが256以下の場合は、[1,256]の範囲からすべてのBFR-idを割り当てることをお勧めします。 256を超えるが512未満のBFERがある場合は、[1,512]の範囲からすべてのBFR-idを割り当てることをお勧めします。以前の範囲では「穴」をできるだけ少なくします。ただし、一部の展開では、この推奨事項から逸脱することが有利な場合があります。これについては、セクション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.
一部の展開では、（特定のサブドメインで）65,535のBFR-idの全範囲をサポートできない場合があります。たとえば、特定のサブドメインのBFRが16 SIしかサポートしておらず、256以下のBitStringLengthsしかサポートしていない場合、そのサブドメインでサポートできるのは16 * 256 = 4,096 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
BER-idをBIERデータパケットにエンコードするには、BFR-idをSIおよびBitStringに変換する必要があります。この変換は、「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 BitStringには1つのビット位置が設定されています。下位ビットがビット1で、上位ビットがビットBitStringLengthの場合、BFR-id Nを表すビット位置は（（N-1）modulo 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を単一のBitStringで表すことができます。これらすべての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 特定のパケットセットにBIERカプセル化を（BFIRとして）課すときに使用するBitStringLength（ "Imposition BitStringLength"）およびサブドメイン（ "Imposition sub-domain"）、および
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として）受信したときに処理するBitStringLengths（ "Disposition BitStringLengths"）。
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 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.
BFIRが、BIERカプセル化を課すすべてのパケットに対して、同じImposition BitStringLengthまたは同じImpositionサブドメインを使用する必要はありません。ただし、特定のBFIRが特定のImposition BitStringLengthおよび特定のパケットのセットにカプセル化を課すときに特定のImpositionサブドメインを使用するようにプロビジョニングされている場合、そのサブドメイン内のBFR-idを持つ他のすべてのBFRは、受信したプロセスをプロビジョニングする必要があります（SHOULD）。そのBitStringLengthを持つBIERパケット（つまり、そのサブドメイン内のBFR-idを持つ他のすべてのBFRは、そのBitStringLengthをそのサブドメインのDisposition BitStringLengthとしてプロビジョニングする必要があります（SHOULD）。この規則の例外は、特定の条件下で行われる場合があります。これについては、セクション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をDisposition 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としてプロビジョニングできる場合は、その同じ値をそのDisposition BitStringLengthの1つとしてプロビジョニングできる必要があります。これは、（a）そのインポジションBitStringLength、および（b）そのディスポジションBitStringLengthの1つとして、BitStringLengthの正当な小さい値をプロビジョニングできる必要があります（SHOULD）。
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は、2つの異なるDisposition 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値をサポートする必要があり、[0,255]の範囲のSI値をサポートする必要があります。 （このコンテキストでは、「指定された範囲の値をサポートする」とは、指定された範囲の値が正当であり、適切に解釈されることを意味します。）指定されたBitStringLengthについて、表現できるBFR-idの総数に注意してください。 BitStringLengthとサポートされるSIの数の積です。たとえば、展開が（特定のサブドメインで）64のBitStringLengthを使用し、256 SIをサポートする場合、その展開はそのサブドメインで16384のBFR-idのみをサポートできます。 256 SIをサポートする展開でも、少なくとも256のBitStringLengthを使用しない限り、65,535のBFR-idをサポートできません。
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 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.
特定のサブドメインに割り当てられたマルチキャストデータパケットを特定の宛先BFERのセットに転送する必要があるとBFIRが判断した場合、BFIRはそのBFERのセットをサブセットに分割します。各サブセットには、BFR-指定されたサブドメインのIDはすべて同じSIに解決されます。これらをパケットの「SIサブセット」と呼びます。各SIサブセットは、単一のBitStringで表すことができます。 BFIRは、SIサブセットごとにパケットのコピーを作成します。次に、BIERカプセル化が各パケットに適用されます。カプセル化は、各パケットに単一のSIを指定し、対応するSIサブセットのすべてのBFR-idを表すBitStringを含みます。もちろん、BitStringを適切に解釈するために、カプセル化からサブドメイン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が特定のパケットを3つのBFERに転送する必要があると判断したとします。BFERのID（適切なサブドメイン内）は27、235、および497です。BFIRは2つのコピーを転送する必要があります。パケット。 SI = 0に関連付けられた1つのコピーには、ビット27および235が設定されたBitStringが含まれます。 SI = 1に関連付けられている他のコピーには、ビット241が設定されたBitStringがあります。
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を参照）に割り当てることをお勧めします。これにより、そのサブドメインで使用する必要があるSIの数が最小限になります。ただし、特定の展開の詳細によっては、他の割り当て方法の方が有利な場合があります。たとえば、特定の展開で、すべてのマルチキャストフローが「東海岸」または「西海岸」のいずれかを対象としているが、両方の海岸を対象としていると仮定します。そのような展開では、すべての「西海岸」のBFR-idが同じSIサブセットに分類され、すべての「東海岸」のBFR-idが同じSI-分類に分類されるように、BFR-idを割り当てると有利です。サブセット。
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を推測します。パケットの転送先となるBFERのセットは、SIおよびBitStringから推測できます。
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.
このドキュメントの後半で示すいくつかの例では、4のBitStringLengthを使用し、「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ネットワークで使用するカプセル化については、[MPLS_BIER_ENCAPS]で説明されています。このドキュメントでは、非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レイヤー」、および「マルチキャストフローオーバーレイ」の3つのレイヤーで構成されると考えるとわかりやすくなります。
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セットへの1つまたは複数の「最良のパス」を決定します。そのような各パスは、BFR（k + j）がBFR（k + j）に「隣接」するように、BFRのシーケンス<BFR（k）、BFR（k + 1）、...、BFR（k + n）>です。 +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-Aなどの特定のBFRで、BIERドメインのBFRのアドレスであるすべてのIPアドレスについて、ルーティングアンダーレイはそのIPアドレスを1つ以上の「等コスト」隣接のセットにマップします。 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.
典型的な展開では、ルーティングアンダーレイは、OSPFなどのInterior Gateway Protocol（IGP）がユニキャストルーティングに使用するデフォルトのトポロジになると予想されます。その場合、アンダーレイ隣接関係は単なる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が使用されている場合、1つのOSPFトポロジをユニキャストトラフィックに使用し、もう1つのOSPFトポロジをマルチキャストトラフィックに使用できます。 （各トポロジは異なるアンダーレイと見なされます。）または、ある種のマルチキャスト固有のツリーを作成するルーティングアンダーレイを展開することもできます。次に、BIERを使用して、マルチキャスト固有のツリーに沿ってマルチキャストデータパケットを転送し、ユニキャストパケットは「通常の」OSPFの最適なパスをたどります。 （このような場合、多くのマルチキャストフローが単一のツリーに沿って移動する可能性があり、特定のパケットによって運ばれるBitStringは、そのパケットを受信する必要があるツリーのノードを識別します。）複数のルーティングアンダーレイを持つことも可能です。データパケットの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層は、BFIRからBFERまで、BIERドメイン全体にマルチキャストデータパケットを送信するために使用されるプロトコルと手順で構成されます。これには、次のコンポーネントが含まれます。
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;
* 各サブドメインで使用するためにプロビジョニングされたDisposition BitStringLengthのセット。
* 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 マルチキャストデータパケットにBIERヘッダーを課すためにBFIRが使用する手順。
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カプセル化パケットを受信すると、パケットをさらに転送する方法を決定する必要があります。この情報は、マルチキャストフローオーバーレイによって提供されます。
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は事実上、新しいタイプの「トンネリングテクノロジー」であるため、BIERレイヤーとマルチキャストフローオーバーレイを適切にインターフェースするには、MVPNシグナリングにいくつかの拡張が必要です。これらは[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は、各サブドメインに対して特定のDisposition BitStringLengthのセットを使用するようにプロビジョニングされており、これらをドメイン内の他のすべてのBFRに通知する必要があります。
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ドメイン）でもある場合、BFRプレフィックス、<sub-domain-id、BFR-id>、およびBitStringLengthの通知を実行できます。 IGPのアドバタイズメント機能を使用します。たとえば、BIERドメインがOSPFドメインでもある場合、これらの通知は、OSPFの「不透明なリンク状態の通知」（不透明なLSA）メカニズムを使用して実行できます。 OSPFおよびIS-ISに必要な拡張の詳細は、関連ドキュメントで提供されます。 （[OSPF_BIER_EXTENSIONS]および[ISIS_BIER_EXTENSIONS]を参照してください。）
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が必要であるため、プロビジョニングエラーが発生しない限り、2つの異なる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をエンコードしてはなりません（MUST NOT）。 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-id Nの所有権をアドバタイズしている別のBFR（BFR-Bなど）からアドバタイズを受け取ったとします。このような場合、BFR-Aはエラーをログに記録する必要があり（SHOULD）、BFR-Bからのアドバタイズが存在する限り、そのサブドメインの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-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、およびBitStringから、パケットの宛先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. パケットのBitStringに、使用されていないBFR-idに対応する1つ以上のビットが含まれる可能性があります。パケットのBitStringに、到達不能なBFERに対応する1つ以上のビットが含まれている可能性もあります。つまり、ネクストホップ隣接がありません。以下では、そのようなすべてのビット位置の「ネクストホップ隣接」を「ヌル」ネクストホップと見なします。
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を識別するパケットのBitString内のビットをクリアします。
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.
<sub-domain、SI、BitString>トリプルがそのBFR自体を識別するBIERカプセル化パケットをBFRが受信した場合、BFRはそのパケットのBFERでもあります。 BFERとして、ペイロードをマルチキャストフローオーバーレイに渡す必要があります。 BitStringに他のBFRに設定されたビットがある場合、パケットもBIERドメイン内でさらに転送する必要があります。 BF（E）RがBIERドメイン内のパケットの1つ以上のコピーも転送する場合、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とそのマルチキャストフローオーバーレイの間の相互作用を定義する仕様で指定する必要があります。
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カプセル化にトラフィッククラスフィールド、タイプオブサービスフィールド、Differentiated Servicesフィールド、またはそのような任意のフィールドが含まれている場合、そのフィールドの値は、デフォルトではマルチキャストフローオーバーレイに渡されません。特定のマルチキャストフローオーバーレイがそのようなフィールドの値を知る必要がある場合、この事実は、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は1つの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ドメイン間の境界では、パケットのカプセル化を解除し、マルチキャストフローオーバーレイに渡す必要があります。
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ドメイン内でパケットの複数のコピーを送信する場合、1つのコピーのみが任意の特定の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ネイバー」（BFR-NBR）、たとえばBFR-Aは、ルーティングアンダーレイによると、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）パケットの宛先であるBFERの（そのサブドメイン内の）BFR-idを学習します。次に、セクション5でアドバタイズされた情報を使用して、BFR-Aは各宛先BFERのBFRプレフィックスを見つけることができます。特定の宛先BFERのBFRプレフィックス（BFER-Dなど）を指定すると、BFR-Aは（パケットのサブドメインに関連付けられた）ルーティングアンダーレイから、BFR-からのパスの次のホップであるBFRのIPアドレスを学習します。 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はBFER-Dに対して複数のBFR-NBRを持つ場合があることに注意してください。
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プレフィックス、およびパス上のBFR-NBRにマップするテーブルです。そのBFER。例として、図1に示すトポロジを考えます。この図では、各BFRのBFR-idを、セクション3で説明したSI：xyzw形式で表します。
( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
4 (0:1000) \ \ 1 (0:0001)
\ \
( E ) ( F )
3 (0:0100) 2 (0:0010)
Figure 1: BIER Topology 1
図1：ビールのトポロジ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を数値として、また（括弧内に）4のBitStringLengthに対応するSI：BitString形式で示しています（実際の最小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 |
--------------------------------------------
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を持っているとします。これらの行のBitStringの論理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では、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-id1と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 |
-------------------------------------
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. BitStringが完全にゼロで構成されている場合は、パケットを破棄します。転送プロセスが完了しました。それ以外の場合は、手順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. パケットのBitStringに設定されている最下位（つまり、右端）ビットの位置（「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. BIFTへの「インデックス」として、SI、サブドメイン、およびBitStringLengthと一緒に値kを使用します。
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とのANDをとることによってコピーのBitStringを更新します（つまり、PacketCopy-> BitString＆= F-BM）。次に、コピーをBFR-NBRに転送します。 （BFR-NBRがnullの場合、コピーは破棄されます。）パケットが特定のBFR-NBRに転送されるとき、そのBitStringは、その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. 次に、元のパケットのBitStringをF-BMのINVERSEとAND演算して更新します（つまり、Packet-> BitString＆=〜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に1回だけ転送されます。 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 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.)
パケットが特定のBFR-NBRに送信されるとき、BitStringは変更が必要なBIERヘッダーの唯一の部分ではありません。 BIERヘッダーにTTLフィールドがある場合は、デクリメントする必要があります。さらに、[MPLS_BIER_ENCAPS]のいずれかのカプセル化が使用されている場合、BIFT-idフィールドは、パケットの送信先であるBFR-NBRからのシグナリングに基づいて、変更が必要になる可能性があります。着信BIERパケットのBIFT-idフィールドは、SI、サブドメイン、およびBitStringLengthを暗黙的に識別します。パケットが特定のBFR-NBRに送信される場合、BIFT-idフィールドは、同じSI、サブドメイン、およびBitStringLengthに対してBFR-NBRがアドバタイズした値に変更する必要があります。 （[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が複数のパラレルインターフェイスを介して接続されている場合は、何らかの形式のロードバランシングを適用することが望ましい場合があります。負荷分散アルゴリズムは、このドキュメントの範囲外です。ただし、パケットのカプセル化にエントロピーフィールドが含まれている場合は、エントロピーフィールドを尊重する必要があります。エントロピーフィールドの同じ値を持つ2つのパケットは、（可能であれば）同じインターフェースで送信する必要があります（SHOULD）。
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カプセル化マルチキャストトラフィックもそのトンネルを介して送信される必要があります（SHOULD）。これにより、既存の「高速リルート」スキームをユニキャストトラフィックだけでなくマルチキャストトラフィックにも適用できます。
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;
}
}
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自体を表すビットセットが1つしかないことも前提としています。この場合、「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.
また、この疑似コードは、ビット位置が未使用のBFR-idまたは到達不能BFERのいずれかに対応する場合に限り、nullネクストホップのF-BMが特定のビット位置に1を含むと想定しています。 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転送の2つの例を示します。これらの例では、すべてのパケットがデフォルトのサブドメインに割り当てられ、すべてのパケットは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 |
------------------- ------------------- -------------------
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）BitStringも含まれます。これは、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 パケットのBitStringは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。コピーのBitStringは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の逆を適用することにより、パケットのBitStringを更新します：Packet-> BitString＆=〜F-BM。その結果、パケットのBitStringは0000（0001＆1000）になります。
o As the packet's BitString is now zero, the forwarding procedure is complete.
o パケットのBitStringがゼロになったため、転送手順は完了です。
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からマルチキャストパケットを受信すると、同じ手順に従います。その結果、BitStringが0001のパケットのコピーがBFR-Cに送信されます。 BFR-Cは同じ手順を適用し、その結果、BitStringが0001のパケットのコピーをBFR-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.
BFER-Dでは、BFR-id 1のBIFTエントリ（図にはありません）は、0001のF-BMとBFR-D自体のBFR-NBRを指定します。これにより、パケットのコピーがBFR-Dのマルチキャストフローオーバーレイに配信されます。パケットのBitStringは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:
この例は、BFIR-AがBFER-DとBFER-Eの両方が特定のマルチキャストフローに関心を持っていることをマルチキャストフローオーバーレイから学習したことを除いて、例1と同様です。 BFIR-AがBIERドメインの外部からそのフローのパケットを受信した場合、BFIR-AはそのパケットにBIERカプセル化を適用します。カプセル化は、SIがゼロになるようにする必要があります。カプセル化には、2つのビットが設定されたBitStringも含まれます。ビット1は（例1のように）設定され、BFR-DがこのパケットのBFERであることを示し、ビット3は、BFR-EがこれのBFERであることを示しますパケット。つまり、BitString（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 パケットのBitStringは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。コピーのBitStringは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の逆を適用することにより、パケットのBitStringを更新します：Packet-> BitString＆=〜F-BM。その結果、パケットのBitStringは0000（0101＆1000）になります。
o As the packet's BitString is now zero, the forwarding procedure is complete.
o パケットのBitStringがゼロになったため、転送手順は完了です。
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 パケットのBitStringは0101なので、BFR-Bは文字列の最初のビットがビット1であることを検出します。BFTのエントリ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。コピーのBitStringは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の逆を適用してパケットのBitStringを更新します：Packet-> BitString＆=〜F-BM。その結果、パケットのBitStringは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はパケットの（変更された）BitStringで次のビットを見つけます。これはビット3です。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。コピーのBitStringは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の逆を適用してパケットのBitStringを更新します：Packet-> BitString＆=〜F-BM。その結果、パケットのBitStringは0000（0100＆1011）になります。
o As the packet's BitString is now zero, the forwarding procedure is complete.
o パケットのBitStringがゼロになったため、転送手順は完了です。
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はパケットの2つのコピーを転送します。 BitString 0001を含むパケットの1つのコピーが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.
BFER-Dでは、BFR-id 1のBIFTエントリ（図にはありません）は、0001のF-BMとBFR-D自体のBFR-NBRを指定します。これにより、パケットのコピーがBFR-Dのマルチキャストフローオーバーレイに配信されます。パケットのBitStringは0000に設定され、パケットはそれ以上転送されません。
The other copy of the packet has been sent from BFR-B to BFER-E, with BitString 0100.
パケットのもう1つのコピーは、ビットストリング0100でBFR-BからBFER-Eに送信されました。
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.
BFER-Eで、BFR-id 3のBIFTエントリ（図にはありません）は、0-100のF-BMおよびBFR-E自体のBFR-NBRを指定します。これにより、パケットのコピーがBFR-Eのマルチキャストフローオーバーレイに配信されます。パケットのBitStringは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の手順は少し変更する必要があります。 2つのECMP手順が定義されています。最初のセクション（6.7.1で説明）では、特定のBFRから特定のBFERへの特定のパケットが取る等コストパスの選択は、（a）ルーティング、（b）パケットのエントロピー、および（c）に依存します。そのパケットの宛先となる他のBFER。 2番目（セクション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.
ここで説明する2つの転送手順の間にはトレードオフがあります。セクション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.
ここで説明する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 | -------------------
-------------------
( 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にはBFER-Fに到達するための2つの等コストパスがあります。1つはBFR-C経由、もう1つはBFR-E経由です。 BFER-FのBFR-idは2であるため、これはBFR-BのBIFTのエントリ2に反映されます。エントリ2は、BFR-BにBFER-Bの2つの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の通常のルールが適用されます。特定のフローのパケットは2つのパスに分割されるべきではなく（SHOULD NOT）、パケットのカプセル化のエントロピーフィールドは尊重されるべきです（SHOULD）。
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では、エントロピー値QのパケットがBIFTのエントリ2を介して転送されると、パケットが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の転送手順を使用して、DとFの両方を宛先とするこのシーケンスのパケットは、BIFTのエントリ1に従って転送されるため、パスA-B-C-Fを介してFに到達します。ただし、Fのみを宛先とするこのシーケンスのパケットは、BIFTのエントリ2に従って転送されるため、パス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, 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.
問題は、Dがフローに繰り返し参加したり、フローから離脱したりすると、BからFへのフローのパスがスイッチングし続けることです。これにより、Fは順不同でパケットを受信する可能性があります。また、トラブルシューティングも困難になります。たとえば、EFリンクに問題がある場合、Fの受信者は、フローがDにも（EFリンクを回避して）行くときに良好なサービスを提供しますが、フローがDに送信しない場合は不良なサービスを受け取ります。常にどのパスが使用されているかを知るために、これはトラブルシューティングが難しい場合があります。また、いつでもフローがたどるパスをたどることがわかっているtracerouteを実行することは非常に困難です。
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の各行には各宛先へのパスは1つだけですが、特定の宛先への複数のECMPパスは複数のテーブルに分散されます。転送するBIERカプセル化パケットが到着すると、BFRはBIERエントロピーフィールドのハッシュを使用してどのBIFTを使用するかを決定し、選択されたBIFTで通常のBIER転送アルゴリズム（セクション6.5および6.6で説明）が使用されます。
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への2つのパス（「X1」および「X2」と呼ぶ）と宛先Yへの4つのパス（「Y1」、「Y2」、「Y3」、および「Y4」と呼ぶ）があるとします。たとえば、BIFTが4つある場合、1つのBIFTにはパスX1とY1があり、1つにはX1とY2があり、1つにはX2とY3があり、1つにはX2とY4があります。 Xへのトラフィックがこれら4つのBIFT間で均等に分割される場合、トラフィックはXへの2つのパス間で均等に分割されます。 Yへのトラフィックがこれら4つのBIFT間で均等に分割される場合、トラフィックはYへの4つのパス間で均等に分割されます。
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.
1つの宛先へのパスが3つ、別の宛先へのパスが4つある場合、これら2つの宛先のそれぞれに負荷を均等に分割するために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カプセル化パケットのBitStringは、そのパケットの転送先となるBFERのセットを指定します。 BIERカプセル化パケットが複製されると、パケットの2つのコピーがBFERを共有することはありません。パケットのBFERの1つがさらにパケットを転送する場合、その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マルチキャスト転送で使用されている「Reverse Path Forwarding」（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であり、ドメイン内の各ノードから他のすべてのノードへの最短パスツリーを計算する場合に使用できる手順について説明します。
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-B」などの特定のBFRで、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. 子ノードの1つが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と見なされます。 F-BMは、BFR-NBRに基づいて適切に計算する必要があります。
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の1つにパケットを送信するには、BFR-Bがユニキャストトンネルを介してパケットを送信する必要があります。 MPLSネットワークでは、これは、子ノードへのIGPユニキャストネクストホップを見つけ、IGEネクストホップが子ノードのアドレスにバインドしたMPLSラベルを（BIERカプセル化ヘッダーの上に）プッシュするのと同じくらい簡単です。 （これは、パケットが[MPLS_BIER_ENCAPS]のセクション2.1で指定されているようなMPLSベースのBIERカプセル化を使用していることを前提としています。）もちろん、BIERカプセル化ヘッダーのBIFT-idは、パケットのSI、サブドメイン、およびBitStringLengthの子ノード。
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トンネルにできない場合、そのトンネルタイプのカプセル化でペイロードがBIERカプセル化パケットであることを示す方法がある限り、他の種類のトンネルを使用できます。
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カプセル化を使用していない場合、トンネルがBIERパケットのみを伝送することがわかっている場合を除き、MPLSトンネルを介してパケットを送信することはできません。これは、MPLSに「次のプロトコルタイプ」フィールドがないためです。 MPLSベースのBIERカプセル化が使用されている場合、これは問題になりません。その場合、BIERカプセル化は、パケットをBIERカプセル化パケットとして識別するMPLSラベルで始まるためです。
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.
子ノードの1つが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カプセル化ヘッダーにコピーされるべきではありません（SHOULD NOT）。
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）である必要があります（SHOULD）。トンネルが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.
2つのBIERパケットのそれぞれのBIERヘッダーのエントロピーフィールドに同じ値があり、両方が特定のトンネルを介して送信される場合、2つのパケットが同じエントロピーを持つという事実をトンネルカプセル化が保持することが望ましいです。
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」としてルーターを考えることができます。このような部分的な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が異なるImpositionやDisposition BitStringLengthsを使用している可能性があります。セクション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が特定のパケットのセットにカプセル化を課すときに特定のインポジションBitStringLengthおよび特定のインポジションサブドメインを使用するようにプロビジョニングされている場合、そのサブドメイン内のBFR-idを持つ他のすべてのBFRは、受信したBIERを処理するためにプロビジョニングする必要があります（SHOULD）そのBitStringLengthを持つパケット（つまり、そのサブドメイン内のBFR-idを持つ他のすべてのBFRは、そのBitStringLengthをそのサブドメインのDisposition 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は、BitStringLength互換性チェックが失敗した場合でも、ブラックホールなしでBIER転送を続行できるオプションのプロシージャを指定しています。
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には2つの選択肢があります。
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パケットを作成します。ただし、パケットは、BitStringで識別されたすべての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 これがプロビジョニングされたImposition BitStringLengthでなくても、互換性チェックに合格するImposition 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ドメインで使用されるBitStringLengthsを変更したい場合があります。セクション6.10.3は、BIERドメインを1つの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はパケットのインポジションBitStringLength Lを選択します。 Imposition 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は、そのサブドメインでDisposition BitStringLength L（およびおそらく他のBitStringLengths）を使用していることもアドバタイズしました。 （MPLSカプセル化（[MPLS_BIER_ENCAPS]のセクション2.1）が使用されている場合、これは、サブドメインSのラベルをアドバタイズしているすべてのBFRがサブドメインSとDisposition 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はこの事実を次のように記録する必要があります（SHOULD）。エラー。次に、パケットの処理方法について次の2つの選択肢があります。
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はプロビジョニングされたImposition BitStringLengthを使用できます。セクション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.
これら2つの選択肢のどちらを選択するかは、プロビジョニングによって決まります。
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.
パケットの破棄は、許容される選択肢の1つではないことに注意してください。たとえば、すべてのBFIRが特定のサブドメインSに対してImposition BitStringLength Lを使用するようにプロビジョニングされているが、サブドメインSに対してDisposition BitStringLength Lを使用するように1つのBFRがプロビジョニングされていないとします。これにより、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がより良いオプションのように思えるかもしれません。ただし、BitStringLength互換性チェックにも合格する、特定のBFIRが使用できるインポジションBitStringLengthがない場合があります。特定の展開で選択肢2を使用する必要がある場合は、次のような "Fallback Disposition BitStringLength"（ "F"と呼びます）が必要です。
o Every BFR advertises that it uses BitStringLength F as a Disposition BitStringLength for every sub-domain, and
o すべてのBFRは、BitStringLength FをすべてのサブドメインのDisposition 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互換性チェックがBitStringLength XとサブドメインSの組み合わせで失敗した場合、BFIRはBitStringLength Fの使用にフォールバックします。面付けサブドメインがSの場合は常に、面付け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:
パケットがXのBitStringLength値でBIERカプセル化されており、パケットがBFR-Aに到着したとします。ここで、ルーティングアンダーレイによると、ネクストホップはBFR-Bですが、BFR-BはXをそのDisposition BitStringLengthの1つとして使用していないとします。 BFR-Aはパケットをどのように処理する必要がありますか？ BFR-Aには3つのオプションがあります。 3つのうちの1つを実行する必要がありますが、実行する手順の選択はローカルの問題です。次の3つのオプションがあります。
1. BFR-A MAY discard the packet.
1. BFR-Aはパケットを破棄してもよい（MAY）。
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値のみを使用する場合は、パケットの追加のコピーを作成する必要があることに注意してください。追加のコピーを実際に作成する必要があるかどうかは、元のパケットのBitStringに実際に設定されているビットによって異なります。
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がBIERをまったくサポートしなかったかのようにBFR-Bを扱うことができます。その場合、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が3つのオプションのどれを使用するかをアドバタイズできるようにするシグナリングがないことに注意してください。
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.
オプション2は、BFRが長いBitStringLengthを使用できるBIERドメインの領域と、BFRが短いBitStringLengthしか使用できない領域がある場合に役立ちます。
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つずつ再プロビジョニングでき、「フラグ日」は必要ありません。
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の両方をそれらのDisposition BitStringLengthとして使用します。
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を再プロビジョニングして、Disposition 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マルチキャスト操作を大幅に簡素化します。ツリー構築コントロールプレーン、フローごとの転送状態、Reverse Path Forwarding（RPF）、Rendezvous Point（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ドメインには適用されません。ツリーを定義する各ノードには、フローごとの詳細な状態はありません。転送プレーンレベル（（S、G）エントリ）でのフローの監視は、BIERノードでは提供されません。 BER-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の主要な運用上の利点の1つである決定論的収束を可能にするのは、この状態の削減です。 BIER FIBは、リンクを通過するマルチキャストフローの数に関係なく、ユニキャストFIBの直後に収束できます。 （S、G）使用率の注意深い監視は、BIERドメイン内では必要ありません。
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）内の一意のビット位置を指定する必要があります。 BFR-idは各BFERで設定し、その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はそのレイヤーのセキュリティに関する考慮事項を継承します。同様に、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カプセル化が、BFIRが意図したもの以外のSIまたはBitStringを指定している場合、パケットは誤って配信される可能性があります。パケットのBIERカプセル化がこのドキュメントで指定されている以外の方法で（エラーまたは不正行為によって）変更された場合、パケットは誤って配信される可能性があります。 BIERカプセル化の一部の変更、たとえば、BitStringのすべてのビットを設定すると、（意図的または意図的ではない）サービス拒否（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が侵害されると、BitStringセットのすべてのビットでBIERカプセル化が課される場合があります。これにより、DoS攻撃も発生します。
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ドメインの外部から受け入れてはなりません（MUST NOT）。 （攻撃者がBitStringのすべてのビットを設定する可能性があるため、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.
2つのインターフェイスが異なるBIERドメインにつながる場合、BFRをプロビジョニングして、これらの2つのインターフェイスが異なるBIERドメインにつながることを知る必要があります。プロビジョニングが正しくない場合、あるBIERドメインからのBIERカプセル化パケットが別のドメインに「リーク」する可能性があります。これにより、パケットが誤って配信される可能性があります。
DoS attacks may also result from incorrect provisioning (through error or malfeasance) of the BFRs.
DoS攻撃は、BFRの誤ったプロビジョニング（エラーまたは不正行為による）からも発生する可能性があります。
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-prefixのアドバタイズに使用される手順が安全でない場合、これらの手順に対する攻撃により、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_EXTENSIONS] Xu、X.、Ed。、Chen、M.、Patel、K.、Wijnands、IJ。、およびA. Przygienda、「BIERのBGP拡張機能」、Work in Progress、draft-ietf-bier-idr- extensions-03、2017年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」、Work in Progress、draft-ietf-bier-mvpn- 2017年11月9日。
[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、「Small Group Multicast」、Work in Progress、draft-boivie-sgm-02、2001年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] Ginsberg、L.、Ed。、Przygienda、A.、Aldrin、S。、およびJ. Zhang、「ISISによるBIERサポート」、作業中、draft-ietf-bier-isis-extensions-06、10月2017。
[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.、and I. Meilik、 "Encapsulation for Bit Index Explicit Replication in MPLS and non -MPLS Networks」、Work in Progress、draft-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_EXTENSIONS] Psenak、P.、Ed。、Kumar、N.、Wijnands、IJ。、Dolganow、A.、Przygienda、T.、Zhang、J。、およびS. Aldrin、「OSPF Extensions for BIER」、Work in進捗、draft-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]ローゼン、E。、およびR.アガーワル、編集、「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 Xu、および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 Telecomメール：gcauchie@bouyguestelecom.fr
Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com
Mach（GU O一）Chen hu Aは電子メールです：Ma Chao.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 Reuters 195 Broadway New York、NY 10007 United States of Email Email：arkadiy.gulko@thomsonreuters.com
Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 Belgium Email: wim.henderickx@nokia.com
Wim Henderickx Nokia Copernicuslaan 50アントワープ2018ベルギーメール：wim.henderickx@nokia.com
Martin Horneffer Deutsche Telekom Hammer Str. 216-226 Muenster 48153 Germany Email: Martin.Horneffer@telekom.de
マーティンホーネファードイツテレコムハンマーStr。 216-226 Muenster 48153ドイツEメール：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 East Arapaho Rd。リチャードソン、テキサス州75081アメリカ合衆国メール：luay.jalil@verizon.com
Uwe Joorde Deutsche Telekom Hammer Str. 216-226 Muenster D-48153 Germany Email: Uwe.Joorde@telekom.de Greg Shepherd Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States of America Email: shep@cisco.com
Uwe Joorde Deutsche Telekom Hammer Str。 216-226 Muenster D-48153ドイツメール：Uwe.Joorde@telekom.deグレッグシェパードシスコシステムズ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（編集者）Cisco Systems、Inc. De Kleetlaan 6a Diegem 1831ベルギー
Email: ice@cisco.com
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
エリックC.ローゼン（編集者）ジュニパーネットワークス社10テクノロジーパークドライブウェストフォード、マサチューセッツ01886アメリカ合衆国
Email: erosen@juniper.net
Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark Singapore 119968 Singapore
Andrew Dolganow Nokia 438B Alexandra Rd＃08-07 / 10 Alexandra Technopark Singapore 119968 Singapore
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 N. Mathilda Ave.サニーベール、カリフォルニア州94089アメリカ合衆国
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 Amphitheatre Parkway Mountain View、California 94043アメリカ合衆国
Email: aldrin.ietf@gmail.com