[要約] RFC 8556は、Bit Index Explicit Replication（BIER）を使用したマルチキャストVPNに関する規格です。その目的は、効率的なマルチキャストトラフィックの配信と管理を実現することです。
Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 8556 M. Sivakumar
Category: Standards Track T. Przygienda
ISSN: 2070-1721 Juniper Networks, Inc.
S. Aldrin
Google, Inc.
A. Dolganow
Nokia
April 2018
Multicast VPN Using Bit Index Explicit Replication (BIER)
ビットインデックス明示的レプリケーション（BIER）を使用したマルチキャストVPN
Abstract
概要
The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.
マルチキャスト仮想プライベートネットワーク（MVPN）仕様では、サービスプロバイダーのバックボーンネットワークを通過するマルチキャストトンネル（「Pトンネル」）を使用する必要があります。 Pトンネルは、バックボーンを介してマルチキャストトラフィックを伝送するために使用されます。さまざまなPトンネルタイプがサポートされています。ビットインデックス明示的レプリケーション（BIER）は、中間ルーターがフローごとの状態を維持したり、明示的なツリー構築プロトコルに従事したりすることなく、「マルチキャストドメイン」を通じて最適なマルチキャスト転送を提供する新しいアーキテクチャです。このドキュメントでは、MVPNがサービスプロバイダーのバックボーンネットワークを介してマルチキャストトラフィックを伝送する方法としてBIERを使用できるようにするプロトコルと手順を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8556.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8556で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
このドキュメントは、BCP 78およびIETFドキュメントに関連するIETFトラストの法的規定の対象です。
(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.
（https://trustee.ietf.org/license-info）このドキュメントの発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes . . . . 5
2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 10
2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 10
3. Use of the PMSI Tunnel Attribute in Leaf A-D Routes . . . . . 11
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Encapsulation and Transmission . . . . . . . . . . . . . 12
4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. At a BFER That Is an Egress PE . . . . . . . . . . . 14
4.2.2. At a BFER That Is a P-tunnel Segmentation Boundary . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
[RFC6513] and [RFC6514] specify the protocols and procedures that a Service Provider (SP) can use to provide Multicast Virtual Private Network (MVPN) service to its customers. Multicast tunnels are created through an SP's backbone network; these are known as "P-tunnels". The P-tunnels are used for carrying multicast traffic across the backbone. The MVPN specifications allow the use of several different kinds of P-tunnel technology.
[RFC6513]と[RFC6514]は、サービスプロバイダー（SP）が顧客にマルチキャスト仮想プライベートネットワーク（MVPN）サービスを提供するために使用できるプロトコルと手順を指定します。マルチキャストトンネルは、SPのバックボーンネットワークを通じて作成されます。これらは「Pトンネル」として知られています。 Pトンネルは、バックボーンを介してマルチキャストトラフィックを伝送するために使用されます。 MVPN仕様では、いくつかの異なる種類のPトンネルテクノロジーを使用できます。
Bit Index Explicit Replication (BIER) ([RFC8279]) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The purpose of the current document is to specify the protocols and procedures needed in order to provide MVPN service using BIER to transport the multicast traffic over the backbone.
ビットインデックス明示的レプリケーション（BIER）（[RFC8279]）は、中間ルーターがフローごとの状態を維持したり、明示的なツリー構築プロトコルに従事したりすることなく、「マルチキャストドメイン」を通じて最適なマルチキャスト転送を提供するアーキテクチャです。現在のドキュメントの目的は、BIERを使用してMVPNサービスを提供し、バックボーン経由でマルチキャストトラフィックを転送するために必要なプロトコルと手順を指定することです。
Although BIER does not explicitly build and maintain multicast tunnels, one can think of BIER as using a number of implicitly created tunnels through a "BIER domain". In particular, one can think of there as being one Point-to-Multipoint (P2MP) tunnel from each Bit Forwarding Ingress Router (BFIR) to all the Bit Forwarding Egress Routers (BFERs) in the BIER domain, where a BIER domain is generally co-extensive with an IGP network. These "tunnels" are not specific to any particular VPN. However, the MVPN architecture provides protocols and procedures that allow the traffic of multiple MVPNs to be aggregated on a single P-tunnel. In this document, we specify how to use these multi-VPN aggregation procedures to enable BIER to transport traffic from multiple MVPNs.
BIERは明示的にマルチキャストトンネルを構築および維持しませんが、BIERは「BIERドメイン」を介して暗黙的に作成された多数のトンネルを使用していると考えることができます。特に、各ビット転送入口ルーター（BFIR）からBIERドメイン内のすべてのビット転送出口ルーター（BFER）への1つのポイントツーマルチポイント（P2MP）トンネルがあると考えることができます。 IGPネットワークと同じ範囲です。これらの「トンネル」は、特定のVPNに固有のものではありません。ただし、MVPNアーキテクチャは、複数のMVPNのトラフィックを単一のPトンネルに集約できるようにするプロトコルと手順を提供します。このドキュメントでは、これらのマルチVPN集約手順を使用して、BIERが複数のMVPNからトラフィックを転送できるようにする方法を指定します。
MVPN traffic must sometimes traverse more than one IGP domain, whereas BIER only carries multicast traffic within a single IGP domain. However, the MVPN specifications allow P-tunnels to be segmented (the concept of MVPN segmentation is defined in [RFC6513] and [RFC6514]), where the segmentation points may either be Autonomous System Border Routers (ASBRs) as described in [RFC6514], or Area Border Routers (ABRs) as described in [RFC7524]. As long as the segmentation points are capable of acting as BFIRs and BFERs, BIER can be used to provide some or all of the segments of a P-tunnel.
MVPNトラフィックは複数のIGPドメインを通過する必要がある場合がありますが、BIERは単一のIGPドメイン内でのみマルチキャストトラフィックを伝送します。ただし、MVPN仕様では、Pトンネルをセグメント化できます（MVPNセグメンテーションの概念は[RFC6513]および[RFC6514]で定義されています）。セグメンテーションポイントは、[RFC6514]で説明されている自律システム境界ルーター（ASBR）のいずれかです。 、または[RFC7524]で説明されているエリア境界ルーター（ABR）。セグメンテーションポイントがBFIRおよびBFERとして機能できる限り、BIERを使用してPトンネルのセグメントの一部またはすべてを提供できます。
Procedures to support MVPN customers who are using Bidirectional PIM (BIDIR-PIM) are outside the scope of this document.
双方向PIM（BIDIR-PIM）を使用しているMVPNカスタマーをサポートする手順は、このドキュメントの範囲外です。
This document uses the following terminology from [RFC8279]:
このドキュメントでは、[RFC8279]の次の用語を使用しています。
o BFR: Bit-Forwarding Router.
o BFR：ビット転送ルーター。
o BFIR: Bit-Forwarding Ingress Router.
o BFIR：ビット転送入力ルーター。
o BFER: Bit-Forwarding Egress Router.
o BFER：ビット転送出力ルーター。
This document uses the following terminology from [RFC6513]:
このドキュメントでは、[RFC6513]の次の用語を使用しています。
o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in which multicast service is offered.
o MVPN：マルチキャスト仮想プライベートネットワーク-マルチキャストサービスが提供されるVPN [RFC4364]。
o P-tunnel: A multicast tunnel through the network of one or more SPs. P-tunnels are used to transport MVPN multicast data
o Pトンネル：1つ以上のSPのネットワークを通るマルチキャストトンネル。 Pトンネルは、MVPNマルチキャストデータの転送に使用されます
o PMSI: Provider Multicast Service Interface. PMSI is an abstraction that represents a multicast service for carrying packets. A PMSI is instantiated via one or more P-tunnels.
o PMSI：プロバイダーマルチキャストサービスインターフェイス。 PMSIは、パケットを運ぶためのマルチキャストサービスを表す抽象概念です。 PMSIは、1つ以上のPトンネルを介してインスタンス化されます。
o C-S: A multicast source address, identifying a multicast source located at a VPN customer site.
o C-S：VPNカスタマーサイトにあるマルチキャストソースを識別するマルチキャストソースアドレス。
o C-G: A multicast group address used by a VPN customer.
o C-G：VPNカスタマーが使用するマルチキャストグループアドレス。
o C-flow: A customer multicast flow. Each C-flow is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of a particular C-flow is usually written as (C-S,C-G).
o C-flow：カスタマーマルチキャストフロー。各Cフローは、順序付けられたペア（送信元アドレス、グループアドレス）によって識別されます。各アドレスは顧客のアドレス空間にあります。特定のCフローの識別子は、通常（C-S、C-G）と記述されます。
Sets of C-flows can be identified by the use of the "C-*" wildcard (see [RFC6625]), e.g., (C-*,C-G).
Cフローのセットは、「C- *」ワイルドカード（[RFC6625]を参照）を使用して識別できます（例：（C-*、C-G））。
o I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the default P-tunnel for a particular MVPN.
o I-PMSI A-Dルート：包括的なPMSI自動検出ルート。これらのルートは、BGPアップデートメッセージで伝送され、特定のMVPNのデフォルトのPトンネルをアドバタイズするために使用されます。
o S-PMSI A-D route: Selective PMSI Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the fact that particular C-flows are bound to (i.e., are traveling through) particular P-tunnels.
o S-PMSI A-Dルート：選択的PMSI自動検出ルート。これらのルートは、BGPアップデートメッセージで伝送され、特定のCフローが特定のPトンネルにバインドされている（つまり、通過している）ことを通知するために使用されます。
o x-PMSI A-D route: A route that is either an I-PMSI A-D route or an S-PMSI A-D route.
o x-PMSI A-Dルート：I-PMSI A-DルートまたはS-PMSI A-Dルートのいずれかであるルート。
o Leaf A-D route: A route that a multicast egress node sends in order to join a particular P-tunnel.
o リーフA-Dルート：特定のPトンネルに参加するためにマルチキャスト出力ノードが送信するルート。
o PMSI Tunnel attribute (PTA): In an x-PMSI A-D route, the Network Layer Reachability Information (NLRI) of the route identifies a PMSI. The BGP attribute known as the PMSI Tunnel attribute is attached to such a route in order to identify a particular P-tunnel that is associated with the PMSI. When C-flows of multiple VPNs are carried in a single P-tunnel, this attribute also carries the information needed to multiplex and demultiplex the C-flows. A PTA can also be carried by a Leaf A-D root. In this case, it contains information that is needed in order for the originator of the route to join the specified P-tunnel.
o PMSIトンネル属性（PTA）：x-PMSI A-Dルートでは、ルートのネットワーク層到達可能性情報（NLRI）がPMSIを識別します。 PMSIに関連付けられている特定のPトンネルを識別するために、PMSIトンネル属性と呼ばれるBGP属性がこのようなルートに付加されます。複数のVPNのCフローが単一のPトンネルで伝送される場合、この属性はCフローの多重化と逆多重化に必要な情報も伝送します。 PTAはLeaf A-Dルートによっても運ばれます。この場合、ルートの発信者が指定されたPトンネルに参加するために必要な情報が含まれています。
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]で説明されているように解釈されます。
As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by an x-PMSI A-D route identifies the P-tunnel that is used to instantiate a particular PMSI. If a PMSI is to be instantiated by BIER, the PTA is constructed by a BFIR.
[RFC6514]で定義されているように、x-PMSI A-Dルートによって伝送されるPMSIトンネル属性（PTA）は、特定のPMSIをインスタンス化するために使用されるPトンネルを識別します。 PMSIがBIERによってインスタンス化される場合、PTAはBFIRによって構築されます。
If segmented P-tunnels are not being used, the PTA attached to a given x-PMSI A-D route is constructed by the router that originated the route (typically by the ingress Provider Edge (PE) router), and the PTA is not changed as the route is propagated.
セグメント化されたPトンネルが使用されていない場合、特定のx-PMSI ADルートに接続されたPTAは、ルートを発信したルーター（通常は入力プロバイダーエッジ（PE）ルーター）によって構築され、PTAは次のように変更されません。ルートが伝播されます。
If segmented P-tunnels are being used, the PTA attached to a given x-PMSI A-D route by the route's originator may be replaced at a segmentation point (a BFER) by a PTA identifying the next segment of the P-tunnel. If the next segment of the P-tunnel is instantiated by BIER, the segmentation point serves as the BFIR for that next segment.
セグメント化されたPトンネルが使用されている場合、ルートのオリジネーターによって特定のx-PMSI A-Dルートに接続されたPTAは、Pトンネルの次のセグメントを識別するPTAによってセグメンテーションポイント（BFER）で置き換えられます。 Pトンネルの次のセグメントがBIERによってインスタンス化される場合、セグメンテーションポイントはその次のセグメントのBFIRとして機能します。
In either case, a PTA is constructed by a BFIR as follows (see Figure 1):
どちらの場合も、PTAはBFIRによって次のように構築されます（図1を参照）。
The PTA contains the following fields:
PTAには次のフィールドがあります。
o Tunnel Type: IANA has assigned 0x0B as the tunnel type codepoint for "BIER" in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. This codepoint is used to indicate that the PMSI is instantiated by BIER.
o トンネルタイプ：IANAは、「P-Multicast Service Interface Tunnel（PMSI Tunnel）Tunnel Types」レジストリで「BIER」のトンネルタイプコードポイントとして0x0Bを割り当てました。このコードポイントは、PMSIがBIERによってインスタンス化されていることを示すために使用されます。
Although BIER does not actually create tunnels, the MVPN procedures treat BIER as if it were a type of tunnel.
BIERは実際にはトンネルを作成しませんが、MVPN手順では、BIERをトンネルの一種であるかのように扱います。
o Tunnel Identifier: When the tunnel type is BIER, this field contains three subfields:
o トンネル識別子：トンネルタイプがBIERの場合、このフィールドには3つのサブフィールドが含まれます。
1. The first subfield is a single octet, containing a BIER sub-domain-id (see [RFC8279]). This indicates that packets sent on the PMSI will be sent on the specified BIER sub-domain. How that sub-domain is chosen is outside the scope of this document.
1. 最初のサブフィールドは、BIERサブドメインIDを含む単一のオクテットです（[RFC8279]を参照）。これは、PMSIで送信されるパケットが、指定されたBIERサブドメインで送信されることを示しています。そのサブドメインの選択方法は、このドキュメントの範囲外です。
2. The second subfield is a two-octet field containing the BFR-id in the sub-domain identified in the first subfield of the router that is constructing the PTA.
2. 2番目のサブフィールドは、PTAを構築しているルーターの最初のサブフィールドで識別されたサブドメインのBFR-idを含む2オクテットのフィールドです。
3. The third subfield is the BFR-prefix (see [RFC8279]) of the router (a BFIR) that is constructing the PTA. The BFR-prefix will either be a /32 IPv4 address or a /128 IPv6 address. Whether the address is IPv4 or IPv6 can be inferred from the total length of the PTA.
3. 3番目のサブフィールドは、PTAを構築しているルーター（BFIR）のBFRプレフィックス（[RFC8279]を参照）です。 BFRプレフィックスは、/ 32 IPv4アドレスまたは/ 128 IPv6アドレスのいずれかになります。アドレスがIPv4であるかIPv6であるかは、PTAの全長から推測できます。
The BFR-prefix need not be the same IP address that is carried in any other field of the x-PMSI A-D route, even if the BFIR is the originating router of the x-PMSI A-D route.
BFRプレフィックスは、BFIRがx-PMSI A-Dルートの発信元ルーターであっても、x-PMSI A-Dルートの他のフィールドで伝送されるIPアドレスと同じである必要はありません。
Failure to properly set the Tunnel Identifier field cannot be detected by the protocol and will result in improper delivery of the data packets sent on the PMSI.
Tunnel Identifierフィールドを正しく設定しないと、プロトコルで検出できず、PMSIで送信されるデータパケットの配信が不適切になります。
o MPLS Label: This field MUST contain an upstream-assigned non-zero MPLS label. It is assigned by the router (a BFIR) that constructs the PTA. Constraints on the way in which a BFIR selects this label are discussed in Section 2.1.
o MPLSラベル：このフィールドには、アップストリームに割り当てられたゼロ以外のMPLSラベルを含める必要があります。これは、PTAを構成するルーター（BFIR）によって割り当てられます。 BFIRがこのラベルを選択する方法の制約については、セクション2.1で説明します。
Failure to follow the constraints on label assignment cannot be detected by the protocol and may result in improper handling of data packets by the egress PE routers.
ラベル割り当ての制約に従わないと、プロトコルで検出できず、出力PEルータによるデータパケットの処理が不適切になる可能性があります。
o Flags: When the tunnel type is BIER, two of the flags in the PTA Flags field are meaningful. Details about the use of these flags can be found in Section 2.2.
o フラグ：トンネルタイプがBIERの場合、PTAフラグフィールドの2つのフラグは意味があります。これらのフラグの使用の詳細については、セクション2.2を参照してください。
* Leaf Information Required per Flow (LIR-pF): This flag is introduced in [RFC8534]. A BFIR SHOULD NOT set this flag UNLESS it knows that all the BFERs in the BIER domain (or at least all the BFERs to which it needs to transmit) support this flag. (How this is known is outside the scope of this document.) Procedures for the use of this flag are given in Section 2.2.2. Support for this flag is OPTIONAL.
* フローごとに必要なリーフ情報（LIR-pF）：このフラグは[RFC8534]で導入されました。 BFIRは、BIERドメイン内のすべてのBFER（または少なくとも送信先のすべてのBFER）がこのフラグをサポートしていることを認識していない限り、このフラグを設定してはなりません（SHOULD NOT）。 （これがどのように知られているかは、このドキュメントの範囲外です。）このフラグの使用手順は、セクション2.2.2に記載されています。このフラグのサポートはオプションです。
* Leaf Information Required (LIR): see Section 2.2.1.
* 葉情報が必要（LIR）：セクション2.2.1を参照してください。
+---------------------------------+
| Flags (1 octet) |
+---------------------------------+
| Tunnel Type = 0x0B (1 octet) |
+---------------------------------+
| MPLS Label (3 octets) |
+---------------------------------+
| Sub-domain-id (1 octet) | <---
+---------------------------------+ |
| BFR-id (2 octets) | |-- Tunnel
+---------------------------------+ | Identifier
| BFR-prefix (4 or 16 octets) | <---
+---------------------------------+
Figure 1: PMSI Tunnel Attribute for BIER
図1：BIERのPMSIトンネル属性
If a PTA specifying tunnel type BIER is attached to an x-PMSI A-D route, the route MUST NOT be distributed beyond the boundaries of a BIER domain. That is, any routers that receive the route must be in the same BIER domain as the originator of the route. If the originator is in more than one BIER domain, the route must be distributed only within the BIER domain in which the BFR-prefix in the PTA uniquely identifies the originator. As with all MVPN routes, distribution of these routes is controlled by the provisioning of Route Targets (RTs). Thus, the requirement expressed in this paragraph is really a requirement on the way the Route Targets are provisioned.
トンネルタイプBIERを指定するPTAがx-PMSI A-Dルートに接続されている場合、ルートはBIERドメインの境界を越えて配布してはなりません（MUST NOT）。つまり、ルートを受信するルーターは、ルートの発信元と同じBIERドメインに属している必要があります。発信者が複数のBIERドメインにある場合、ルートは、PTAのBFRプレフィックスが発信者を一意に識別するBIERドメイン内でのみ配布する必要があります。すべてのMVPNルートと同様に、これらのルートの配布はルートターゲット（RT）のプロビジョニングによって制御されます。したがって、この段落で表されている要件は、ルートターゲットのプロビジョニング方法に関する要件です。
The MPLS Label carried in the PTA is an upstream-assigned label.
PTAで伝送されるMPLSラベルは、上流に割り当てられたラベルです。
If two PTAs contain the same BFR-prefix in their respective Tunnel Identifier fields, then the labels carried in those PTAs MUST come from the same label space (see Section 7 of [RFC5331]). An implementation may choose to use this fact when setting up the tables it uses to interpret the upstream-assigned labels.
2つのPTAのそれぞれのトンネルIDフィールドに同じBFRプレフィックスが含まれている場合、それらのPTAで運ばれるラベルは同じラベルスペースからのものでなければなりません（[RFC5331]のセクション7を参照）。実装は、上流に割り当てられたラベルを解釈するために使用するテーブルを設定するときに、この事実を使用することを選択できます。
Suppose that a BFIR attaches a PTA to each of two x-PMSI A-D routes, and both PTAs specify a tunnel type of BIER.
BFIRが2つのx-PMSI A-DルートのそれぞれにPTAをアタッチし、両方のPTAがBIERのトンネルタイプを指定するとします。
o If the two routes do not carry the same set of RTs, then their respective PTAs MUST contain different MPLS label values.
o 2つのルートが同じRTのセットを伝送しない場合、それぞれのPTAに異なるMPLSラベル値が含まれている必要があります。
o If the two routes do not have the same Address Family Identifier (AFI) value, then their respective PTAs MUST contain different MPLS label values. This ensures that when an egress PE receives a data packet with the given label, the egress PE can infer from the label whether the payload is an IPv4 packet or an IPv6 packet.
o 2つのルートに同じアドレスファミリ識別子（AFI）値がない場合、それぞれのPTAに異なるMPLSラベル値が含まれている必要があります。これにより、出力PEが特定のラベルの付いたデータパケットを受信したときに、ペイロードがIPv4パケットであるかIPv6パケットであるかを出力PEがラベルから推測できるようになります。
o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) functionality, and if the two routes originate from different VPN Routing and Forwarding tables (VRFs) on this ingress PE, then the respective PTAs of the two routes MUST contain different MPLS label values.
o BFIRがMVPNエクストラネット（[RFC7900]）機能をサポートする入力PEであり、2つのルートがこの入力PEの異なるVPNルーティングおよび転送テーブル（VRF）から発信されている場合、2つのルートのそれぞれのPTAに異なるMPLSが含まれている必要があります。ラベル値。
o If the BFIR is an ingress PE supporting the "Extranet Separation" feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if one of the routes carries the "Extranet Separation" extended community but the other does not, then the respective PTAs of the two routes MUST contain different MPLS label values.
o BFIRがMVPNエクストラネットの[エクストラネット分離]機能をサポートする入力PE（[RFC7900]のセクション7.3を参照）であり、一方のルートが「エクストラネット分離」拡張コミュニティを持ち、もう一方がそうでない場合、それぞれ2つのルートのPTAには、異なるMPLSラベル値が含まれている必要があります。
o If segmented P-tunnels are being used, then the respective PTAs of the two routes MUST contain different MPLS label values whenever the respective NLRIs of the two routes are not identical. The MPLS label can then be used at the next segmentation point to switch packets from one P-tunnel segment directly to the next, without requiring the segmentation points to contain any other multicast forwarding state. This is explained further below; see also Section 4.
o セグメント化されたPトンネルが使用されている場合、2つのルートのそれぞれのNLRIが同一でない場合は常に、2つのルートのそれぞれのPTAに異なるMPLSラベル値が含まれている必要があります。次に、MPLSラベルを次のセグメンテーションポイントで使用して、パケットを1つのPトンネルセグメントから次のセグメントに直接切り替えることができます。セグメンテーションポイントに他のマルチキャスト転送状態を含める必要はありません。これについては以下でさらに説明します。セクション4も参照してください。
When segmented P-tunnels are being used, a segmentation point, call it "B1", may receive an x-PMSI A-D route whose PTA specifies BIER from within a given BIER domain. This means that BIER is being used for the previous segment of a segmented P-tunnel. If the next segment is also of type BIER, B1 will be the BFIR for the next segment. That is, B1 is a BFER of one BIER domain (corresponding to the previous segment) and a BFIR of another BIER domain (corresponding to the next segment). B1 needs to replace the PTA of the x-PMSI A-D route with a new PTA, specifying its own BFR-prefix and specifying an upstream-assigned label assigned by B1 itself.
セグメント化されたPトンネルが使用されている場合、セグメンテーションポイントは「B1」と呼ばれ、PTAが特定のBIERドメイン内からBIERを指定するx-PMSI A-Dルートを受信することがあります。これは、セグメント化されたPトンネルの前のセグメントにBIERが使用されていることを意味します。次のセグメントもBIERタイプの場合、B1は次のセグメントのBFIRになります。つまり、B1は1つのBIERドメイン（前のセグメントに対応）のBFERであり、別のBIERドメイン（次のセグメントに対応）のBFIRです。 B1は、x-PMSI A-DルートのPTAを新しいPTAに置き換える必要があります。独自のBFRプレフィックスを指定し、B1自体によって割り当てられたアップストリーム割り当てラベルを指定します。
Suppose that B1 has received two x-PMSI A-D routes, R1 and R2, where:
B1が2つのx-PMSI A-Dルート、R1とR2を受信したとします。
o R1 and R2 each have a PTA specifying BIER.
o R1とR2にはそれぞれ、BIERを指定するPTAがあります。
o R1's PTA specifies BFR-prefix B2 and Label L2.
o R1のPTAは、BFRプレフィックスB2およびラベルL2を指定します。
o R2's PTA specifies BFR-prefix B3 and Label L3.
o R2のPTAは、BFRプレフィックスB3およびラベルL3を指定します。
Suppose B1 decides to propagate both R1 and R2, replacing each PTA with a new PTA specifying BIER. Suppose these new PTAs specify labels L4 and L5,respectively. Then L4 and L5 MUST be different (upstream-assigned) label values, UNLESS both of the following conditions hold:
B1がR1とR2の両方を伝搬することを決定し、各PTAをBIERを指定する新しいPTAに置き換えるとします。これらの新しいPTAがラベルL4とL5をそれぞれ指定するとします。次に、L4とL5は異なる（上流に割り当てられた）ラベル値である必要があります。
o R1 and R2 have the same value in the Originating Router field of their respective NLRIs, and
o R1とR2のそれぞれのNLRIのOriginating Routerフィールドに同じ値があり、
o B2 is equal to B3, and
o B2はB3と等しく、かつ
o L2 is equal to L3.
o L2はL3と同じです。
The segmentation point (B1, in this example) MUST also program its data plane appropriately. For example, when:
セグメンテーションポイント（この例ではB1）も、そのデータプレーンを適切にプログラムする必要があります。たとえば、次の場合：
o B1 receives a BIER packet for which it is a BFER, and
o B1は、BFERであるBIERパケットを受信します。
o the BIER header specifies the BFIR-id that corresponds to B2, and
o BIERヘッダーは、B2に対応するBFIR-idを指定します。
o the BIER payload is an MPLS packet with upstream-assigned label, and
o BIERペイロードは、上流に割り当てられたラベルを持つMPLSパケットであり、
o the top label value is L2,
o トップラベルの値はL2です。
then the data plane must be programmed to replace L2 with L4 and to re-encapsulate the packet in a BIER header with B1's BFR-id in the BFIR-id field. The BitString of the new BIER header is determined by applying the procedures for MVPN explicit tracking (see Section 2.2) in the BIER domain of the next segment, i.e., in the BIER domain for which B1 is the BFIR).
次に、データプレーンは、L2をL4に置き換え、パケットをBIERヘッダーに再カプセル化し、BFIR-idフィールドにB1のBFR-idを含めるようにプログラムする必要があります。新しいBIERヘッダーのBitStringは、次のセグメントのBIERドメイン（つまり、B1がBFIRであるBIERドメイン）でMVPN明示的追跡（セクション2.2を参照）の手順を適用することによって決定されます。
When using BIER to transport an MVPN data packet through a BIER domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR must determine the set of BFERs to which the packet needs to be delivered. This can be done in either of two ways:
BIERを使用してMVPNデータパケットをBIERドメイン経由で転送する場合、入力PEはBFIRとして機能します（[RFC8279]を参照）。 BFIRは、パケットを配信する必要があるBFERのセットを決定する必要があります。これは、次の2つの方法のいずれかで実行できます。
1. Using the explicit tracking mechanism based on the "Leaf Information Required" flag specified in [RFC6513] and [RFC6514]. This method is further described in Section 2.2.1.
1. [RFC6513]と[RFC6514]で指定されている「Leaf Information Required」フラグに基づく明示的な追跡メカニズムの使用。この方法については、セクション2.2.1で詳しく説明します。
2. Using the OPTIONAL explicit tracking mechanism based on the LIR-pF flag specified in [RFC8534]. This method, further described in Section 2.2.2, may be used if (and only if) segmented P-tunnels are not being used.
2. [RFC8534]で指定されたLIR-pFフラグに基づくオプションの明示的な追跡メカニズムの使用。この方法は、セクション2.2.2で詳しく説明されていますが、セグメント化されたPトンネルが使用されていない場合にのみ使用できます。
To determine the set of BFERs to which the packets of a given C-flow must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for the given C-flow. It MUST attach a PTA to that route and MUST set the Leaf Information Required (LIR) flag in the PTA. Per [RFC6514], the BFERs that need to receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By matching the received Leaf A-D routes to the originated S-PMSI A-D routes, the originator of the S-PMSI A-D route determines the set of BFERs that need to receive the multicast data flow that is identified in the NLRI of S-PMSI A-D route.
特定のCフローのパケットの送信先となるBFERのセットを決定するには、BFIRは特定のCフローの（C-S、C-G）S-PMSI A-Dルートを作成する必要があります。そのルートにPTAをアタッチしなければならず、PTAにLeaf Information Required（LIR）フラグを設定しなければなりません（MUST）。 [RFC6514]によると、Cフローを受信する必要があるBFERは、（C-S、C-G）リーフA-Dルートで応答します。受信したリーフADルートを発信S-PMSI ADルートと照合することにより、S-PMSI ADルートの発信者は、S-PMSI ADルートのNLRIで識別されるマルチキャストデータフローを受信する必要があるBFERのセットを決定します。
Suppose that an ingress PE has originated an I-PMSI A-D route or a wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel type of BIER. Now suppose that the ingress PE originates an S-PMSI A-D route specifying (C-S,C-G), where (C-S,C-G) "matches" (according to the rules of [RFC6625]) the wildcard S-PMSI A-D route or the I-PMSI A-D route. Instead of attaching a PTA specifying BIER to the (C-S,C-G) route, the ingress PE MAY attach a PTA specifying a tunnel type of "no tunnel information". This is equivalent to attaching the same PTA attached to the matching "less specific" route.
入力PEが、トンネルタイプBIERを指定するPTAを使用してI-PMSI A-DルートまたはワイルドカードS-PMSI A-Dルート[RFC6625]を発信したとします。次に、入力PEが（CS、CG）を指定するS-PMSI ADルートを発信するとします。ここで、（CS、CG）は（[RFC6625]のルールに従って）ワイルドカードS-PMSI ADルートまたはI- PMSI ADルート。 （C-S、C-G）ルートにBIERを指定するPTAをアタッチする代わりに、入力PEは「トンネル情報なし」のトンネルタイプを指定するPTAをアタッチできます。これは、一致する「あまり具体的でない」ルートに添付された同じPTAを添付することと同じです。
If segmented P-tunnels are not being used, the BFIR can determine the set of BFERs that need to receive the packets of a given (C-S,C-G) C-flow as follows. The BFIR MUST originate a wildcard S-PMSI A-D route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G)), and the PTA of that route MUST use the following settings:
セグメント化されたPトンネルが使用されていない場合、BFIRは、次のように特定の（C-S、C-G）Cフローのパケットを受信する必要があるBFERのセットを決定できます。 BFIRはワイルドカードS-PMSI ADルート（（C-*、C-*）、（C-*、CG）、または（CS、CG）のいずれか）を発信する必要があり、そのルートのPTAは次の設定を使用する必要があります：
o The LIR-pF flag MUST be set.
o LIR-pFフラグを設定する必要があります。
o The tunnel type MUST be set to BIER.
o トンネルタイプはBIERに設定する必要があります。
o A non-zero MPLS label MUST be specified.
o ゼロ以外のMPLSラベルを指定する必要があります。
Per [RFC8534], a BFER that needs to receive (C-S,C-G) traffic from the BFIR will respond with a Leaf A-D route.
[RFC8534]に従い、BFIRから（C-S、C-G）トラフィックを受信する必要があるBFERは、リーフA-Dルートで応答します。
A BFIR MUST NOT use this method of finding the set of BFERs needing to receive a given C-flow unless it knows that all those BFERs support the LIR-pF flag. How this is known is outside the scope of this document.
BFIRは、これらのすべてのBFERがLIR-pFフラグをサポートしていることを知らない限り、特定のCフローを受信する必要があるBFERのセットを見つけるこの方法を使用してはなりません（MUST NOT）。これがどのように知られているかは、このドキュメントの範囲外です。
This method greatly reduces the number of S-PMSI A-D routes that a BFIR needs to originate; it can now originate as few as one such route (a (C-*,C-*) S-PMSI A-D route), rather than one for each C-flow. However, the method does not provide a way for the BFIR to assign a distinct label to each C-flow. Therefore, it cannot be used when segmented P-tunnels are in use (see Section 4 for an explanation).
この方法により、BFIRが発信する必要があるS-PMSI A-Dルートの数が大幅に削減されます。各Cフローではなく、1つのルート（（C-*、C- *）S-PMSI A-Dルート）から発信できるようになりました。ただし、この方法では、BFIRが各Cフローに個別のラベルを割り当てることができません。したがって、セグメント化されたPトンネルが使用されている場合は使用できません（説明については、セクション4を参照してください）。
Note: If a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR-pF flag set but also originates a more specific wildcard route that matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D routes for that (C-S,C-G) unless the LIR-pF flag is also set in the more specific wildcard route. If the BFIR also originates a (C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag is also set in that route.
注：BFIRがLIR-pFフラグが設定された（C-*、C- *）S-PMSI ADルートを発信し、さらに特定の（CS、CG）に一致するより具体的なワイルドカードルートを発信する場合、BFERはより具体的なワイルドカードルートでLIR-pFフラグも設定されていない限り、その（CS、CG）のリーフADルートを開始します。 BFIRがLIRフラグが設定されていない（C-S、C-G）S-PMSI A-Dルートも発信する場合、そのルートでLIRフラグも設定されていない限り、BFERはその（C-S、C-G）のリーフA-Dルートを発信しません。
Before an egress PE can receive a (C-S,C-G) flow from a given ingress PE via BIER, the egress PE must have received one of the following x-PMSI A-D routes from the ingress PE:
出力PEがBIERを介して特定の入力PEから（C-S、C-G）フローを受信する前に、出力PEは入力PEから次のx-PMSI A-Dルートのいずれかを受信している必要があります。
o A (C-S,C-G) S-PMSI A-D route (i.e., an S-PMSI A-D route whose NLRI encodes (C-S,C-G)) and whose PTA specifies a tunnel type of BIER. If such a route is found, we refer to it as the "matching x-PMSI A-D route."
o （C-S、C-G）S-PMSI A-Dルート（つまり、NLRIが（C-S、C-G）をエンコードするS-PMSI A-Dルート）、PTAがBIERのトンネルタイプを指定します。このようなルートが見つかった場合、「一致するx-PMSI A-Dルート」と呼びます。
o A "less specific" x-PMSI A-D route (one specifying (C-*,C-*), (C-*,C-G), or (C-S,C-G)) whose PTA specifies a tunnel type of BIER, and that is the egress PE's "match for reception" of (C-S,C-G).
o 「あまり具体的でない」x-PMSI ADルート（（C-*、C-*）、（C-*、CG）、または（CS、CG）を指定するルート）。そのPTAは、BIERのトンネルタイプを指定します。 （CS、CG）の出力PEの「受信の一致」。
The rules for determining which x-PMSI A-D route is the match for reception are given in [RFC6625]. However, these rules are modified here to exclude any x-PMSI A-D route that does not have a PTA or whose PTA specifies "no tunnel type".
どのx-PMSI A-Dルートが受信に一致するかを決定するためのルールは、[RFC6625]で提供されています。ただし、これらのルールはここで変更され、PTAがないか、PTAが「トンネルタイプなし」を指定しているx-PMSI A-Dルートを除外します。
If such a route is found, we refer to it as the "matching x-PMSI A-D route."
このようなルートが見つかった場合、「一致するx-PMSI A-Dルート」と呼びます。
If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE cannot receive the (C-S,C-G) flow from the ingress PE via BIER until such time as a matching route is received.
（C-S、C-G）に一致するx-PMSI A-Dルートが見つからない場合、一致するルートが受信されるまで、出力PEはBIERを介して入力PEから（C-S、C-G）フローを受信できません。
When an egress PE determines that it needs to receive a (C-S,C-G) flow from a particular ingress PE via BIER, it originates a Leaf A-D route. Construction of the Leaf A-D route generally follows the procedures specified in [RFC6514] or, optionally, the procedures specified in [RFC8534]. However, when BIER is being used, the Leaf A-D route MUST carry a PTA that is constructed as follows:
出力PEは、BIERを介して特定の入力PEから（C-S、C-G）フローを受信する必要があると判断すると、リーフA-Dルートを開始します。リーフA-Dルートの構築は、一般に[RFC6514]で指定された手順、またはオプションで[RFC8534]で指定された手順に従います。ただし、BIERが使用されている場合、リーフA-Dルートは、次のように構築されたPTAを伝送する必要があります。
1. The tunnel type MUST be set to BIER.
1. トンネルタイプはBIERに設定する必要があります。
2. The MPLS Label field SHOULD be set to zero.
2. MPLSラベルフィールドはゼロに設定する必要があります。
3. The sub-domain-id subfield of the Tunnel Identifier field (as defined in Section 2) MUST be set to the corresponding value from the PTA of the matching x-PMSI A-D route.
3. （セクション2で定義されている）トンネルIDフィールドのサブドメインIDサブフィールドは、一致するx-PMSI A-DルートのPTAからの対応する値に設定する必要があります。
4. The BFR-id subfield of the Tunnel Identifier field MUST be set to the BFR-id in the sub-domain identified by the sub-domain-id subfield of the egress PE (BFER).
4. トンネル識別子フィールドのBFR-idサブフィールドは、出力PE（BFER）のサブドメインIDサブフィールドで識別されるサブドメインのBFR-idに設定する必要があります。
5. The BFR-prefix field of the Tunnel Identifier field (as defined in Section 2) MUST be set to the egress PE's (BFER's) BFR-prefix.
5. トンネル識別子フィールドのBFRプレフィックスフィールド（セクション2で定義）は、出力PE（BFER）のBFRプレフィックスに設定する必要があります。
The BFR-prefix need not be the same IP address that is carried in any other field of the Leaf A-D route.
BFRプレフィックスは、リーフA-Dルートの他のフィールドで伝送されるIPアドレスと同じである必要はありません。
When an ingress PE receives such a Leaf A-D route, it learns the BFR-prefix of the egress PE from the PTA. The ingress PE does not make any use the value of the PTA's MPLS label field.
入力PEがこのようなリーフA-Dルートを受信すると、PTAから出力PEのBFRプレフィックスを学習します。入力PEは、PTAのMPLSラベルフィールドの値を使用しません。
Failure to properly construct the PTA cannot always be detected by the protocol and will cause improper delivery of the data packets.
PTAを適切に構築できないと、プロトコルで常に検出できるとは限らず、データパケットの配信が不適切になります。
The MVPN application plays the role of the "multicast flow overlay" as described in [RFC8279].
MVPNアプリケーションは、[RFC8279]で説明されている「マルチキャストフローオーバーレイ」の役割を果たします。
To transmit an MVPN data packet, an ingress PE follows the rules of [RFC6625] to find the x-PMSI A-D route that is a "match for transmission" for that packet. (In applying the rules of [RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel information" is ignored.) If the matching route has a PTA specifying BIER, the (upstream-assigned) MPLS label from that PTA is pushed on the packet's label stack. Then the packet is encapsulated in a BIER header. That is, the ingress PE functions as a BFIR. The BIER sub-domain used for transmitting the packet is specified in the PTA of the above-mentioned x-PMSI A-D route.
MVPNデータパケットを送信するために、入力PEは[RFC6625]のルールに従って、そのパケットの「送信に一致」するx-PMSI A-Dルートを見つけます。 （[RFC6625]のルールを適用する場合、「トンネル情報なし」を指定するPTAを持つS-PMSI ADルートは無視されます。）一致するルートにBIERを指定するPTAがある場合、そのPTAからの（上流に割り当てられた）MPLSラベルパケットのラベルスタックにプッシュされます。次に、パケットはBIERヘッダーにカプセル化されます。つまり、入力PEはBFIRとして機能します。パケットの送信に使用されるBIERサブドメインは、上記のx-PMSI A-DルートのPTAで指定されています。
In order to create the proper BIER header for a given packet, the BFIR must know all the BFERs that need to receive that packet. It determines this by finding all the Leaf A-D routes that correspond to the S-PMSI A-D route that is the packet's match for transmission. There are two different cases to consider:
特定のパケットに適切なBIERヘッダーを作成するために、BFIRはそのパケットを受信する必要があるすべてのBFERを知っている必要があります。これは、送信用のパケットの一致であるS-PMSI A-Dルートに対応するすべてのリーフA-Dルートを見つけることによってこれを決定します。考慮すべき2つの異なるケースがあります。
1. The S-PMSI A-D route that is the match for transmission carries a PTA that has the LIR flag set but does not have the LIR-pF flag set.
1. 送信に一致するS-PMSI A-Dルートは、LIRフラグが設定されているがLIR-pFフラグが設定されていないPTAを伝送します。
In this case, the corresponding Leaf A-D routes are those whose "route key" field is identical to the NLRI of the S-PMSI A-D route.
この場合、対応するリーフA-Dルートは、「ルートキー」フィールドがS-PMSI A-DルートのNLRIと同一であるものです。
2. The S-PMSI A-D route that is the match for transmission carries a PTA that has the LIR-pF flag.
2. 送信に一致するS-PMSI A-Dルートは、LIR-pFフラグを持つPTAを伝送します。
In this case, the corresponding Leaf A-D routes are those whose "route key" field is derived from the NLRI of the S-PMSI A-D route according to the procedures described in Section 5.2 of [RFC8534].
この場合、対応するリーフA-Dルートは、[ルートキー]フィールドが[RFC8534]のセクション5.2で説明されている手順に従ってS-PMSI A-DルートのNLRIから派生したものです。
The Leaf A-D route from a given BFER will contain a PTA that specifies the BFER's BFR-prefix. With this information, the BFIR can construct the BIER BitString.
特定のBFERからのリーフA-Dルートには、BFERのBFRプレフィックスを指定するPTAが含まれます。この情報を使用して、BFIRはBIER BitStringを構築できます。
However, if the PTA of the Leaf A-D route from a given BFER specifies a sub-domain other than the one being used for transmitting the packet, the bit for that BFER cannot be determined and that BFER will not receive the packet.
ただし、特定のBFERからのリーフA-DルートのPTAがパケットの送信に使用されているもの以外のサブドメインを指定している場合、そのBFERのビットを判別できず、そのBFERはパケットを受信しません。
The BIER-encapsulated packet is then forwarded, according to the procedures described in [RFC8279] and [RFC8296]. (See especially Section 3, "Imposing and Processing the BIER Encapsulation" in [RFC8296].)
次に、[RFC8279]および[RFC8296]で説明されている手順に従って、BIERでカプセル化されたパケットが転送されます。 （特に[RFC8296]のセクション3、「BIERカプセル化のインポーズと処理」を参照してください。）
When a BFER receives an MVPN multicast data packet that has been BIER-encapsulated, the BIER layer passes the following information to the multicast flow overlay:
BFERがカプセル化されたMVPNマルチキャストデータパケットをBFERが受信すると、BIERレイヤーは次の情報をマルチキャストフローオーバーレイに渡します。
o The sub-domain-id and the BFIR-id from the BIER header. (As the sub-domain-id is inferred from the BIFT-id field of the BIER header, an implementation might choose to pass the BIFT-id rather than the sub-domain-id; this is an implementation matter.)
o BIERヘッダーのサブドメインIDとBFIR-ID。 （sub-domain-idはBIERヘッダーのBIFT-idフィールドから推測されるため、実装はsub-domain-idではなくBIFT-idを渡すことを選択する場合があります。これは実装の問題です。）
o The "payload", which is an MPLS packet whose top label is an upstream-assigned label. In the data plane, the BFIR-id and the sub-domain-id provide the context in which the upstream-assigned label is interpreted.
o 「ペイロード」は、トップラベルがアップストリームに割り当てられたラベルであるMPLSパケットです。データプレーンでは、BFIR-idとsub-domain-idは、アップストリームに割り当てられたラベルが解釈されるコンテキストを提供します。
By looking up the upstream-assigned label in the appropriate context, the multicast flow overlay determines whether the BFER is an egress PE for the packet.
マルチキャストフローオーバーレイは、適切なコンテキストでアップストリームに割り当てられたラベルを検索することにより、BFERがパケットの出力PEであるかどうかを判断します。
Note that if segmented P-tunnels are in use, a BFER might be a P-tunnel segmentation border router rather than an egress PE, or a BFER might be both an egress PE and a P-tunnel segmentation border router. Depending upon the role of the BFER for the given packet, it may need to follow the procedures of Section 4.2.1, the procedures of Section 4.2.2, or both.
セグメント化されたPトンネルが使用されている場合、BFERが出力PEではなくPトンネルセグメンテーション境界ルーターであるか、BFERが出力PEとPトンネルセグメンテーション境界ルーターの両方である可能性があることに注意してください。特定のパケットに対するBFERの役割に応じて、セクション4.2.1の手順、セクション4.2.2の手順、またはその両方に従う必要がある場合があります。
From looking up the packet's upstream-assigned label in the context of the packet's BFIR-prefix, the egress PE determines the egress VRF for the packet. From the IP header of the payload, the multicast states of the VRF, the upstream-assigned label, and the BFR-prefix, the egress PE can determine whether the packet needs to be forwarded out one or more VRF interfaces.
パケットのアップストリーム割り当てラベルをパケットのBFIRプレフィックスのコンテキストで検索することにより、出力PEはパケットの出力VRFを決定します。ペイロードのIPヘッダー、VRFのマルチキャストステート、アップストリームに割り当てられたラベル、およびBFRプレフィックスから、出力PEは、パケットを1つ以上のVRFインターフェイスに転送する必要があるかどうかを判断できます。
When segmented P-tunnels are being used, a BFER that receives a BIER-encapsulated MVPN multicast data packet may need to be forwarded on its next P-tunnel segment. The choice of the next P-tunnel segment for the packet depends upon the C-flow to which the packet belongs. As long as the BFIR has assigned the MPLS label according to the constraints specified in Section 2.1, the BFIR will have assigned distinct upstream-assigned MPLS labels to distinct C-flows. The BFER can thus select the proper "next P-tunnel segment" for a given packet simply by looking up the upstream-assigned label that immediately follows the BIER header.
セグメント化されたPトンネルが使用されている場合、BIERでカプセル化されたMVPNマルチキャストデータパケットを受信するBFERは、次のPトンネルセグメントで転送される必要がある場合があります。パケットの次のPトンネルセグメントの選択は、パケットが属するCフローによって異なります。 BFIRがセクション2.1で指定された制約に従ってMPLSラベルを割り当てている限り、BFIRは異なるアップストリーム割り当てMPLSラベルを異なるCフローに割り当てます。したがって、BFERは、BIERヘッダーの直後に続くアップストリームに割り当てられたラベルを検索するだけで、所定のパケットに適切な「次のPトンネルセグメント」を選択できます。
IANA has assigned the codepoint 0x0B to BIER in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.
IANAは、「P-Multicast Service Interface Tunnel（PMSI Tunnel）Tunnel Types」レジストリでコードポイント0x0BをBIERに割り当てました。
The procedures of this document do not, in themselves, provide privacy, integrity, or authentication for the control plane or the data plane. For a discussion of the security considerations regarding the use of BIER, please see [RFC8279] and [RFC8296]. Security considerations regarding VPN technology based on [RFC4364], [RFC6513], and [RFC6514] can be found in those RFCs.
このドキュメントの手順自体では、コントロールプレーンまたはデータプレーンのプライバシー、整合性、または認証は提供されません。 BIERの使用に関するセキュリティの考慮事項については、[RFC8279]および[RFC8296]を参照してください。 [RFC4364]、[RFC6513]、および[RFC6514]に基づくVPNテクノロジーに関するセキュリティの考慮事項は、これらのRFCに記載されています。
[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>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https://www.rfc-editor.org/info / rfc4364>。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<https：//www.rfc -editor.org/info/rfc5331>。
[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. Aggarwal編、「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>。
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <https://www.rfc-editor.org/info/rfc6625>.
[RFC6625]ローゼン、E。、編、Rekhter、Y。、編、Hendrickx、W。、およびR.秋、「マルチキャストVPN自動検出ルートのワイルドカード」、RFC 6625、DOI 10.17487 / RFC6625、2012年5月、<https://www.rfc-editor.org/info/rfc6625>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.
[RFC8279] Wijnands、IJ。、Ed。、Rosen、E.、Ed。、Dolganow、A.、Przygienda、T.、and S. Aldrin、 "Multicast Using Bit Index Explicit Replication（BIER）"、RFC 8279、DOI 10.17487 / RFC8279、2017年11月、<https://www.rfc-editor.org/info/rfc8279>。
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8296] Wijnands、IJ。、Ed。、Rosen、E.、Ed。、Dolganow、A.、Tantsura、J.、Aldrin、S.、and I. Meilik、 "Encapsulation for Bit Index Explicit Replication（BIER）in MPLS and Non-MPLS Networks」、RFC 8296、DOI 10.17487 / RFC8296、2018年1月、<https://www.rfc-editor.org/info/rfc8296>。
[RFC8534] Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang, "Explicit Tracking with Wildcard Routes in Multicast VPN", RFC 8534, DOI 10.17487/RFC8534, February 2019, <https://www.rfc-editor.org/info/rfc8534>.
[RFC8534] Dolganow、A.、Kotalwar、J.、Rosen、E.、Ed。、およびZ. Zhang、「マルチキャストVPNでのワイルドカードルートによる明示的な追跡」、RFC 8534、DOI 10.17487 / RFC8534、2019年2月、<https ：//www.rfc-editor.org/info/rfc8534>。
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, <https://www.rfc-editor.org/info/rfc7524>.
[RFC7524] Rekhter、Y.、Rosen、E.、Aggarwal、R.、Morin、T.、Grosclaude、I.、Leymann、N。、およびS. Saad、「エリア間ポイントツーマルチポイント（P2MP）セグメント化ラベルスイッチドパス（LSP）」、RFC 7524、DOI 10.17487 / RFC7524、2015年5月、<https://www.rfc-editor.org/info/rfc7524>。
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", RFC 7900, DOI 10.17487/RFC7900, June 2016, <https://www.rfc-editor.org/info/rfc7900>.
[RFC7900] Rekhter、Y.、Ed。、Rosen、E.、Ed。、Aggarwal、R.、Cai、Y。、およびT. Morin、「BGP / IP MPLS VPNでのエクストラネットマルチキャスト」、RFC 7900、DOI 10.17487 / RFC7900、2016年6月、<https://www.rfc-editor.org/info/rfc7900>。
Acknowledgments
謝辞
The authors wish to thank Jeffrey Zhang for his ideas and contributions to this work. We also thank Stig Venaas for his review and comments.
著者は、この作品への彼のアイデアと貢献に対してジェフリー・チャンに感謝したいと思います。また、Stig Venaasのレビューとコメントにも感謝します。
Contributors
貢献者
IJsbrand Wijnands Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com
IJsbrand Wijnands Cisco Systems、Inc. De Kleetlaan 6a Diegem 1831 Belgium Eメール：ice@cisco.com
Authors' Addresses
著者のアドレス
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
エリックC.ローゼン（編集者）ジュニパーネットワークス社10テクノロジーパークドライブウェストフォード、マサチューセッツ01886アメリカ合衆国
Email: erosen52@gmail.com
Mahesh Sivakumar Juniper Networks, Inc. 1137 Innovation Way Sunnyvale, California 94089 United States of America
Mahesh Sivakumar Juniper Networks、Inc. 1137 Innovation Wayサニーベール、カリフォルニア州94089アメリカ合衆国
Email: sivakumar.mahesh@gmail.com
Tony Przygienda Juniper Networks, Inc. 1137 Innovation Way Sunnyvale, California 94089 United States of America
Tony Przygienda Juniper Networks、Inc. 1137 Innovation Wayサニーベール、カリフォルニア州94089アメリカ合衆国
Email: prz@juniper.net
Sam K Aldrin Google, Inc. 1600 Amphitheatre Parkway Mountain View, California United States of America
Sam K Aldrin Google、Inc. 1600 Amphitheatre Parkway Mountain View、California United States of America
Email: aldrin.ietf@gmail.com
Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark Singapore 119968
アンドリュードルガノウノキア438Bアレクサンドラロード＃08-07 / 10アレクサンドラテクノパークシンガポール119968
Email: andrew.dolganow@nokia.com