[要約] RFC 8296は、MPLSおよび非MPLSネットワークでのBit Index Explicit Replication（BIER）のためのカプセル化に関するものです。このRFCの目的は、BIERをサポートするためのカプセル化メカニズムを提供することです。
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 8296 Cisco Systems, Inc.
Category: Experimental E. Rosen, Ed.
ISSN: 2070-1721 Juniper Networks, Inc.
A. Dolganow
Nokia
J. Tantsura
Individual
S. Aldrin
Google, Inc.
I. Meilik
Broadcom
January 2018
Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks
MPLSおよび非MPLSネットワークでのビットインデックス明示的レプリケーション（BIER）のカプセル化
Abstract
概要
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.
ビットインデックス明示的レプリケーション（BIER）は、中間ルーターがフローごとの状態を維持したり、明示的なツリー構築プロトコルに従事したりすることなく、「マルチキャストドメイン」を通じて最適なマルチキャスト転送を提供するアーキテクチャです。マルチキャストデータパケットがドメインに入ると、入力ルーターは、パケットの送信先となる一連の出力ルーターを決定します。次に、入力ルーターはパケットをBIERヘッダーにカプセル化します。 BIERヘッダーにはビット文字列が含まれ、各ビットはドメイン内の1つの出力ルーターを表します。パケットを特定の出力ルーターのセットに転送するには、これらのルーターに対応するビットをBIERヘッダーに設定します。カプセル化の詳細は、マルチキャストドメインの実現に使用されるネットワークのタイプによって異なります。このドキュメントでは、MPLSネットワークで、またはわずかな違いはあるものの非MPLSネットワークで使用できる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/rfc8296.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8296で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 ....................................................3
2. BIER Header .....................................................5
2.1. In MPLS Networks ...........................................5
2.1.1. Encapsulation Initial Four Octets ...................5
2.1.1.1. The BIER-MPLS Label ........................5
2.1.1.2. Other Fields of the Initial Four Octets ....8
2.1.2. Remainder of Encapsulation ..........................9
2.1.3. Further Encapsulating a BIER Packet ................12
2.2. In Non-MPLS Networks ......................................13
2.2.1. Encapsulation Initial Four Octets ..................13
2.2.1.1. The BIFT-id ...............................13
2.2.1.2. Other Fields of the Initial Four Octets ...13
2.2.2. Remainder of Encapsulation .........................14
2.2.3. Further Encapsulating a BIER Packet ................15
3. Imposing and Processing the BIER Encapsulation .................16
4. IANA Considerations ............................................18
5. IEEE Considerations ............................................18
6. Security Considerations ........................................19
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................21
Acknowledgements ..................................................22
Contributors ......................................................22
Authors' Addresses ................................................24
[RFC8279] describes a new architecture for the forwarding of multicast data packets. Known as "Bit Index Explicit Replication" (BIER), that architecture provides optimal forwarding of multicast data packets through a "multicast domain". It does so without requiring any explicit tree-building protocol and without requiring intermediate nodes to maintain any per-flow state.
[RFC8279]は、マルチキャストデータパケットを転送するための新しいアーキテクチャについて説明しています。 「ビットインデックス明示的レプリケーション」（BIER）として知られるこのアーキテクチャは、「マルチキャストドメイン」を介したマルチキャストデータパケットの最適な転送を提供します。明示的なツリー構築プロトコルを必要とせず、フローごとの状態を維持するための中間ノードも必要としません。
This document will use terminology defined in [RFC8279].
このドキュメントでは、[RFC8279]で定義されている用語を使用します。
A router that supports BIER is known as a "Bit-Forwarding Router" (BFR). A "BIER domain" is a connected set of BFRs, each of which has been assigned a BFR-prefix. A BFR-prefix is a routable IP address of a BFR and is used by BIER to identify a BFR. A packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). As specified in [RFC8279], each BFR of a given BIER domain is provisioned to be in one or more "sub-domains" (SDs). In the context of a given SD, each BFIR and BFER must have a BFR-id that is unique within that SD. A BFR-id is just a number in the range [1,65535] that, relative to a BIER SD, identifies a BFR uniquely.
BIERをサポートするルーターは、「ビット転送ルーター」（BFR）として知られています。 「BIERドメイン」は、BFRの接続されたセットであり、それぞれにBFRプレフィックスが割り当てられています。 BFRプレフィックスはBFRのルーティング可能なIPアドレスで、BIERがBFRを識別するために使用します。パケットは、ビット転送入力ルーター（BFIR）でBIERドメインに入り、1つ以上のビット転送出力ルーター（BFER）でBIERドメインを出ます。 [RFC8279]で指定されているように、特定のBIERドメインの各BFRは、1つ以上の「サブドメイン」（SD）になるようにプロビジョニングされます。特定のSDのコンテキストでは、各BFIRおよびBFERには、そのSD内で一意のBFR-idが必要です。 BFR-idは、[1,65535]の範囲の数値であり、BIER SDを基準にして、BFRを一意に識別します。
As described in [RFC8279], BIER requires that multicast data packets be encapsulated with a header that provides the information needed to support the BIER forwarding procedures. This information includes the SD to which the packet has been assigned, a Set Identifier (SI), a BitString, and a BitStringLength (BSL). Together, these values are used to identify the set of BFERs to which the packet must be delivered.
[RFC8279]で説明されているように、BIERでは、BIER転送手順をサポートするために必要な情報を提供するヘッダーでマルチキャストデータパケットをカプセル化する必要があります。この情報には、パケットが割り当てられているSD、セット識別子（SI）、BitString、およびBitStringLength（BSL）が含まれます。これらの値を一緒に使用して、パケットの配信先であるBFERのセットを識別します。
This document defines an encapsulation that can be used in either MPLS networks or non-MPLS networks. However, the construction and processing of the BIER header are slightly different in MPLS networks than in non-MPLS networks. In particular:
このドキュメントでは、MPLSネットワークまたは非MPLSネットワークのいずれかで使用できるカプセル化を定義します。ただし、BIERヘッダーの構築と処理は、MPLSネットワークと非MPLSネットワークで若干異なります。特に：
o The handling of certain fields in the encapsulation header (the "BIER header") is different, depending upon whether the underlying network is an MPLS network or not.
o カプセル化ヘッダー（「BIERヘッダー」）の特定のフィールドの処理は、基盤となるネットワークがMPLSネットワークであるかどうかによって異なります。
o In an MPLS network, the first four octets of a BIER header are also the bottom entry (the last four octets) of an MPLS label stack.
o MPLSネットワークでは、BIERヘッダーの最初の4オクテットは、MPLSラベルスタックの一番下のエントリ（最後の4オクテット）でもあります。
The MPLS-based encapsulation is explained in detail in Section 2.1. The differences between the MPLS-based encapsulation and the non-MPLS encapsulation are explained in Section 2.2.
MPLSベースのカプセル化については、セクション2.1で詳しく説明しています。 MPLSベースのカプセル化と非MPLSカプセル化の違いについては、セクション2.2で説明します。
Following the BIER header is the "payload". The payload may be an IPv4 packet, an IPv6 packet, an Ethernet frame, an MPLS packet, or an Operations, Administration, and Maintenance (OAM) packet. (The use of BIER with other payload types is also possible but is not further discussed in this document.) The BIER header contains information (the Next Protocol field) identifying the type of the payload.
BIERヘッダーの後には「ペイロード」があります。ペイロードは、IPv4パケット、IPv6パケット、イーサネットフレーム、MPLSパケット、または運用、管理、保守（OAM）パケットです。 （他のペイロードタイプでBIERを使用することも可能ですが、このドキュメントではこれ以上説明しません。）BIERヘッダーには、ペイロードのタイプを識別する情報（次のプロトコルフィールド）が含まれています。
If the payload is an MPLS packet, then an MPLS label stack immediately follows the BIER header. The top label of this MPLS label stack may be either a downstream-assigned label [RFC3031] or an upstream-assigned label [RFC5331].
ペイロードがMPLSパケットの場合、MPLSラベルスタックはBIERヘッダーの直後に続きます。このMPLSラベルスタックの最上位ラベルは、ダウンストリーム割り当てラベル[RFC3031]またはアップストリーム割り当てラベル[RFC5331]のいずれかです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The BIER header is shown in Figure 1.
BIERヘッダーを図1に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nibble | Ver | BSL | Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM|Rsv| DSCP | Proto | BFIR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BIER Header
図1：ビールヘッダー
The BIFT-id represents a particular Bit Index Forwarding Table (BIFT); see Section 6.4 of [RFC8279]. As explained in [RFC8279], each BIFT corresponds to a particular combination of SD, BSL, and SI.
BIFT-idは、特定のビットインデックス転送テーブル（BIFT）を表します。 [RFC8279]のセクション6.4をご覧ください。 [RFC8279]で説明されているように、各BIFTはSD、BSL、SIの特定の組み合わせに対応しています。
Section 2.1 explains how the fields of the encapsulation header are used in MPLS networks. For those fields that are used differently in non-MPLS networks, Section 2.2 explains the differences.
セクション2.1では、カプセル化ヘッダーのフィールドがMPLSネットワークでどのように使用されるかについて説明します。非MPLSネットワークで使用方法が異なるフィールドについては、セクション2.2で違いを説明しています。
The default BitStringLength value for the encapsulations defined in this document is 256. See Section 3 of [RFC8279] for a discussion of the default BitStringLength value.
このドキュメントで定義されているカプセル化のデフォルトのBitStringLength値は256です。デフォルトのBitStringLength値については、[RFC8279]のセクション3をご覧ください。
As stated in [RFC8279], when a BIER domain is also an IGP domain, IGP extensions can be used by each BFR to advertise the BFR-id and BFR-prefix. The extensions for OSPF are given in [OSPF_BIER_EXTENSIONS]. The extensions for IS-IS are given in [ISIS_BIER_EXTENSIONS].
[RFC8279]で述べられているように、BIERドメインがIGPドメインでもある場合、各BFRはIGP拡張を使用してBFR-idとBFR-prefixをアドバタイズできます。 OSPFの拡張機能は[OSPF_BIER_EXTENSIONS]で提供されています。 IS-ISの拡張機能は[ISIS_BIER_EXTENSIONS]で提供されています。
When a particular BIER domain is both an IGP domain and an MPLS network, we assume that each BFR will also use IGP extensions to advertise a set of one or more "BIER-MPLS" labels. When the domain contains a single SD, a given BFR needs to advertise one such label for each combination of SI and BSL. If the domain contains multiple SDs, a BFR needs to advertise one such label per SI per BSL for each SD.
特定のBIERドメインがIGPドメインとMPLSネットワークの両方である場合、各BFRもIGP拡張を使用して、1つ以上の「BIER-MPLS」ラベルのセットをアドバタイズすると想定します。ドメインに単一のSDが含まれている場合、特定のBFRは、SIとBSLの組み合わせごとにそのようなラベルを1つアドバタイズする必要があります。ドメインに複数のSDが含まれている場合、BFRは各SDのBSLごとにSIごとにそのようなラベルを1つアドバタイズする必要があります。
In some environments, the only routing protocol in a BIER domain might be BGP; in this case, the BGP extensions described in [BGP_BIER_EXTENSIONS] can be used to advertise the necessary set of BIER-MPLS labels.
一部の環境では、BIERドメインの唯一のルーティングプロトコルがBGPである場合があります。この場合、[BGP_BIER_EXTENSIONS]で説明されているBGP拡張を使用して、BIER-MPLSラベルの必要なセットをアドバタイズできます。
The BIER-MPLS labels are locally significant (i.e., unique only to the BFR that advertises them) downstream-assigned MPLS labels. Penultimate hop popping [RFC3031] MUST NOT be applied to a BIER-MPLS label.
BIER-MPLSラベルは、ローカルで重要な（つまり、それらをアドバタイズするBFRにのみ固有）ダウンストリーム割り当てMPLSラベルです。最後から2番目のホップポップ[RFC3031]は、BIER-MPLSラベルに適用してはなりません。
Suppose, for example, that there is a single SD (the default SD), that the network is using a BSL of 256, and that all BFERs in the SD have BFR-ids in the range [1,512]. Since each BIER BitString is 256 bits long, this requires the use of two SIs: SI=0 and SI=1. So each BFR will advertise, via IGP extensions, two MPLS labels for BIER: one corresponding to SI=0 and one corresponding to SI=1. The advertisements of these labels will also bind each label to the default SD and to BSL 256.
たとえば、単一のSD（デフォルトSD）があり、ネットワークが256のBSLを使用しており、SD内のすべてのBFERの範囲が[1,512]のBFR-idであるとします。各BIER BitStringは256ビット長であるため、SI = 0とSI = 1の2つのSIを使用する必要があります。したがって、各BFRは、IGP拡張を介して、BIERの2つのMPLSラベルをアドバタイズします。1つはSI = 0に対応し、もう1つはSI = 1に対応します。これらのラベルのアドバタイズは、各ラベルをデフォルトのSDおよびBSL 256にもバインドします。
As another example, suppose a particular BIER domain contains two SDs (SD 0 and SD 1), supports two BSLs (256 and 512), and contains 1024 BFRs. A BFR that is provisioned for both SDs, and that supports both BSLs, would have to advertise the following set of BIER-MPLS labels:
別の例として、特定のBIERドメインに2つのSD（SD 0およびSD 1）が含まれ、2つのBSL（256および512）をサポートし、1024のBFRが含まれているとします。両方のSDにプロビジョニングされ、両方のBSLをサポートするBFRは、次のBIER-MPLSラベルのセットをアドバタイズする必要があります。
L1: corresponding to SD 0, BSL 256, SI 0.
L1：SD 0、BSL 256、SI 0に対応。
L2: corresponding to SD 0, BSL 256, SI 1.
L2：SD 0、BSL 256、SI 1に対応
L3: corresponding to SD 0, BSL 256, SI 2.
L3：SD 0、BSL 256、SI 2に対応。
L4: corresponding to SD 0, BSL 256, SI 3.
L4：SD 0、BSL 256、SI 3に対応
L5: corresponding to SD 0, BSL 512, SI 0.
L5：SD 0、BSL 512、SI 0に対応
L6: corresponding to SD 0, BSL 512, SI 1.
L6：SD 0、BSL 512、SI 1に対応
L7: corresponding to SD 1, BSL 256, SI 0.
L7：SD 1、BSL 256、SI 0に対応。
L8: corresponding to SD 1, BSL 256, SI 1.
L8：SD 1、BSL 256、SI 1に対応。
L9: corresponding to SD 1, BSL 256, SI 2.
L9：SD 1、BSL 256、SI 2に対応。
L10: corresponding to SD 1, BSL 256, SI 3.
L10：SD 1、BSL 256、SI 3に対応。
L11: corresponding to SD 1, BSL 512, SI 0.
L11：SD 1、BSL 512、SI 0に対応。
L12: corresponding to SD 1, BSL 512, SI 1.
L12：SD 1、BSL 512、SI 1に対応
The above example should not be taken as implying that the BFRs need to advertise 12 individual labels. For instance, instead of advertising a label for <SD 1, BSL 512, SI 0> and a label for <SD 1, BSL 512, SI 1>, a BFR could advertise a contiguous range of labels (in this case, a range containing exactly two labels) corresponding to <SD 1, BSL 512>. The first label in the range could correspond to SI 0, and the second to SI 1. The precise mechanism for generating and forming the advertisements is outside the scope of this document; see [OSPF_BIER_EXTENSIONS] and [ISIS_BIER_EXTENSIONS].
上記の例は、BFRが12の個別のラベルをアドバタイズする必要があることを意味するものとして解釈されるべきではありません。たとえば、<SD 1、BSL 512、SI 0>のラベルと<SD 1、BSL 512、SI 1>のラベルをアドバタイズする代わりに、BFRは隣接するラベルの範囲（この場合、範囲<SD 1、BSL 512>に対応するラベルを2つだけ含む）。範囲の最初のラベルはSI 0に対応し、2番目のラベルはSI 1に対応する可能性があります。広告を生成および形成するための正確なメカニズムは、このドキュメントの範囲外です。 [OSPF_BIER_EXTENSIONS]および[ISIS_BIER_EXTENSIONS]を参照してください。
The BIER-MPLS label corresponding to a particular combination of SD, SI, and BSL is interpreted as representing the BIFT that corresponds to that same combination of SD, SI, and BSL. That is, the BIER-MPLS label performs the function of a BIFT-id. This label value is carried in the BIFT-id field of the BIER encapsulation.
SD、SI、およびBSLの特定の組み合わせに対応するBIER-MPLSラベルは、SD、SI、およびBSLの同じ組み合わせに対応するBIFTを表すものとして解釈されます。つまり、BIER-MPLSラベルはBIFT-idの機能を実行します。このラベル値は、BIERカプセル化のBIFT-idフィールドで伝達されます。
It is crucial to understand that in an MPLS network the first four octets of the BIER encapsulation header are also the last four octets of the MPLS header. Therefore, any prior MPLS label stack entries MUST have the S bit (see [RFC3032]) clear (i.e., the S bit must be 0).
MPLSネットワークでは、BIERカプセル化ヘッダーの最初の4オクテットがMPLSヘッダーの最後の4オクテットでもあることを理解することが重要です。したがって、以前のMPLSラベルスタックエントリには、Sビット（[RFC3032]を参照）がクリアされている必要があります（つまり、Sビットは0でなければなりません）。
When a BFR receives an MPLS packet and the next label to be processed is one of its BIER-MPLS labels, it will assume that the remainder of the BIER header (see Section 2.1.2) immediately follows the stack.
BFRがMPLSパケットを受信し、次に処理されるラベルがそのBIER-MPLSラベルの1つである場合、BIERヘッダーの残り（セクション2.1.2を参照）がスタックの直後に続くと想定します。
Note that in practice, labels only have to be assigned if they are going to be used. If a particular BIER domain supports BSLs 256 and 512, but some SD, say SD 1, only uses BSL 256, then it is not necessary to assign labels that correspond to the combination of SD 1 and BSL 512.
実際には、ラベルは、使用する場合にのみ割り当てる必要があることに注意してください。特定のBIERドメインがBSL 256および512をサポートしているが、一部のSD、たとえばSD 1はBSL 256のみを使用している場合、SD 1とBSL 512の組み合わせに対応するラベルを割り当てる必要はありません。
TC:
TC：
The "Traffic Class" field [RFC5462] has its usual meaning in an MPLS label stack entry.
「トラフィッククラス」フィールド[RFC5462]は、MPLSラベルスタックエントリで通常の意味を持っています。
S bit:
Sビット：
When a BIER packet is traveling through an MPLS network, the high-order 20 bits of the initial four octets of the BIER encapsulation contain an MPLS label in the BIFT-id field. These four octets are treated as the final entry in the packet's MPLS label stack. Hence, the S bit (see [RFC3032]) MUST be set to 1. If there are any MPLS label stack entries immediately preceding the BIER encapsulation, the S bit of those label stack entries MUST be set to 0.
BIERパケットがMPLSネットワークを通過するとき、BIERカプセル化の最初の4オクテットの上位20ビットには、BIFT-idフィールドにMPLSラベルが含まれています。これらの4つのオクテットは、パケットのMPLSラベルスタックの最後のエントリとして扱われます。したがって、Sビット（[RFC3032]を参照）を1に設定する必要があります。BIERカプセル化の直前にMPLSラベルスタックエントリがある場合、それらのラベルスタックエントリのSビットを0に設定する必要があります。
TTL:
TTL：
This is the usual MPLS "Time to Live" field [RFC3032]. When a BIER packet is received, its "incoming TTL" (see below) is taken from this TTL field.
これは通常のMPLS "Time to Live"フィールドです[RFC3032]。 BIERパケットが受信されると、その「着信TTL」（下記を参照）がこのTTLフィールドから取得されます。
When a BIER packet is forwarded to one or more BFR adjacencies, the BIER-MPLS label carried by the forwarded packet MUST have a TTL field whose value is one less than that of the packet's incoming TTL.
BIERパケットが1つ以上のBFR隣接に転送されるとき、転送されたパケットによって運ばれるBIER-MPLSラベルは、その値がパケットの着信TTLの値よりも1小さいTTLフィールドを持つ必要があります。
If a BIER packet's incoming TTL is 1 or greater and one of the bits in its BitString identifies the current BFR, then the current BFR is a BFER for the packet. Therefore, the current BFR MUST process the packet as a BFER, e.g., by removing the BIER encapsulation and processing the payload based on the contents of the Proto (Next Protocol) field.
BIERパケットの着信TTLが1以上で、そのBitStringのビットの1つが現在のBFRを識別する場合、現在のBFRはパケットのBFERです。したがって、現在のBFRは、たとえば、BIERカプセル化を削除し、Proto（Next Protocol）フィールドの内容に基づいてペイロードを処理するなどして、パケットをBFERとして処理する必要があります。
If the incoming TTL is 0, the packet is considered to be "expired". If the incoming TTL is 1 and the BitString has a bit set that does not identify the current BFR, the packet is also considered to be expired. Expired packets SHOULD be passed to an error-handling procedure. (Optional implementation-specific rate limiting may be applied to control the rate at which packets are passed to the error-handling procedure.) Specification of the error-handling procedure is outside the scope of this document.
着信TTLが0の場合、パケットは「期限切れ」と見なされます。着信TTLが1で、BitStringに現在のBFRを識別しないビットセットがある場合、パケットも期限切れと見なされます。期限切れのパケットは、エラー処理プロシージャに渡される必要があります（SHOULD）。 （オプションの実装固有のレート制限を適用して、パケットがエラー処理手順に渡される速度を制御できます。）エラー処理手順の仕様は、このドキュメントの範囲外です。
Note that if a received BIER packet has an incoming TTL of 1 and its BitString has a bit set identifying the current BFR, the payload MUST be processed by the current BFR, but the packet MUST NOT be forwarded further, and the packet SHOULD also be passed to the error-handling procedures for expired packets (subject to any implementation-specific rate limiting).
受信したBIERパケットの着信TTLが1で、そのBitStringに現在のBFRを識別するビットセットがある場合、ペイロードは現在のBFRによって処理される必要がありますが、パケットはそれ以上転送されてはならず（MUST）、パケットも期限切れのパケットのエラー処理手順に渡されます（実装固有のレート制限が適用されます）。
Nibble:
ニブル：
This field is set to the binary value 0101; this ensures that the MPLS ECMP logic will not confuse the remainder of the BIER header with an IP header or with the header of a pseudowire packet. In an MPLS network, if a BFR receives a BIER packet with any other value in the first nibble after the label stack, it SHOULD discard the packet and log an error.
このフィールドはバイナリ値0101に設定されます。これにより、MPLS ECMPロジックがBIERヘッダーの残りの部分をIPヘッダーまたは疑似配線パケットのヘッダーと混同しないようになります。 MPLSネットワークでは、BFRがラベルスタックの後の最初のニブルに他の値を持つBIERパケットを受信した場合、パケットを破棄してエラーをログに記録する必要があります（SHOULD）。
Ver:
見る：
This 4-bit field identifies the version of the BIER header. This document specifies version 0 of the BIER header. If a packet is received by a particular BFR and that BFR does not support the specified version of the BIER header, the BFR MUST discard the packet and log an error.
この4ビットのフィールドは、BIERヘッダーのバージョンを識別します。このドキュメントでは、BIERヘッダーのバージョン0を指定しています。パケットが特定のBFRによって受信され、そのBFRが指定されたバージョンのBIERヘッダーをサポートしない場合、BFRはパケットを破棄してエラーをログに記録する必要があります。
The value 0xF is reserved for experimental use; that value MUST NOT be assigned by any future IETF document or by IANA.
値0xFは実験用に予約されています。その値は、将来のIETFドキュメントまたはIANAによって割り当てられてはなりません。
BSL:
BSL：
This 4-bit field encodes the length in bits of the BitString.
この4ビットのフィールドは、ビットストリングの長さをビット単位でエンコードします。
Note: When parsing the BIER header, a BFR MUST infer the length of the BitString from the BIFT-id and MUST NOT infer it from the value of this field. This field is present only to enable offline tools (such as LAN analyzers) to parse the BIER header.
注：BIERヘッダーを解析する場合、BFRはBIFT-idからBitStringの長さを推測しなければならず、このフィールドの値からそれを推測してはなりません（MUST NOT）。このフィールドは、オフラインツール（LANアナライザーなど）がBIERヘッダーを解析できるようにするためにのみ存在します。
If k is the length of the BitString, the value of this field is log2(k)-5. However, only certain values are supported:
kがBitStringの長さである場合、このフィールドの値はlog2（k）-5です。ただし、特定の値のみがサポートされています。
1: 64 bits
1：64ビット
2: 128 bits
2：128ビット
3: 256 bits
3：256ビット
4: 512 bits
4：512ビット
5: 1024 bits
5：1024ビット
6: 2048 bits
6：2048ビット
7: 4096 bits
7：4096ビット
The value of this field MUST NOT be set to any value other than those listed above. A received packet containing another value in this field SHOULD be discarded and an error logged. If the value in this field is other than what is expected based on the BIER-MPLS label, the packet SHOULD be discarded and an error logged.
このフィールドの値は、上記にリストされたもの以外の値に設定してはいけません。このフィールドに別の値が含まれている受信パケットは破棄し、エラーをログに記録する必要があります（SHOULD）。このフィールドの値が、BIER-MPLSラベルに基づいて予期される値以外の場合、パケットを破棄してエラーをログに記録する必要があります（SHOULD）。
Entropy:
エントロピ：
This 20-bit field specifies an "entropy" value that can be used for load-balancing purposes. The BIER forwarding process may do equal-cost load balancing, in which case the load-balancing procedure MUST choose the same path for any two packets that have the same entropy value and the same BitString. Please see Section 6.7 ("Equal-Cost Multipath Forwarding") of [RFC8279] for a more detailed discussion of BIER load-balancing procedures.
この20ビットのフィールドは、負荷分散の目的で使用できる「エントロピー」値を指定します。 BIER転送プロセスは、等コストのロードバランシングを行う場合があります。その場合、ロードバランシング手順は、同じエントロピー値と同じBitStringを持つ2つのパケットに対して同じパスを選択する必要があります。 BIERロードバランシング手順の詳細については、[RFC8279]のセクション6.7（「等コストマルチパス転送」）を参照してください。
If a BFIR is encapsulating (as the payload) MPLS packets that have entropy labels, the BFIR MUST ensure that if two such packets have the same MPLS entropy label they also have the same value of the BIER entropy field.
BFIRがエントロピーラベルを持つMPLSパケットを（ペイロードとして）カプセル化している場合、BFIRは、そのような2つのパケットが同じMPLSエントロピーラベルを持つ場合、BIERエントロピーフィールドの値も同じであることを確認する必要があります。
OAM:
OAM：
By default, these two bits are set to 0 by the BFIR and are not modified by other BFRs. These two bits have no effect on the path taken by a BIER packet and have no effect on the quality of service applied to a BIER packet.
デフォルトでは、これらの2ビットはBFIRによって0に設定され、他のBFRによって変更されません。これらの2ビットは、BIERパケットがたどるパスには影響せず、BIERパケットに適用されるサービス品質には影響しません。
The use of these bits in other than the default manner is OPTIONAL. Specification of the non-default use or uses of these bits is outside the scope of this document; see [BIER-PMM] for an example of such a specification.
デフォルト以外の方法でのこれらのビットの使用はオプションです。デフォルト以外の使用またはこれらのビットの使用の指定は、このドキュメントの範囲外です。そのような仕様の例については、[BIER-PMM]を参照してください。
Rsv:
Rsv：
These two bits are currently unused. They SHOULD be set to 0 upon transmission and MUST be ignored upon reception.
これらの2ビットは現在使用されていません。それらは送信時に0に設定する必要があり（SHOULD）、受信時に無視する必要があります。
DSCP:
DSCP：
By default, this 6-bit field is not used in MPLS networks. The default behavior is that all six bits SHOULD be set to 0 upon transmission and MUST be ignored upon reception.
デフォルトでは、この6ビットフィールドはMPLSネットワークでは使用されません。デフォルトの振る舞いでは、6ビットすべてが送信時に0に設定されるべきで（SHOULD）、受信時に無視されなければなりません（MUST）。
Non-default use of this field in MPLS networks is outside the scope of this document.
MPLSネットワークでのこのフィールドのデフォルト以外の使用は、このドキュメントの範囲外です。
Proto:
したがって：
This 6-bit "Next Protocol" field identifies the type of the payload. (The "payload" is the packet or frame immediately following the BIER header.) IANA has created a registry called "BIER Next Protocol Identifiers". This field is to be populated with the appropriate entry from that registry.
この6ビットの「次のプロトコル」フィールドは、ペイロードのタイプを識別します。 （「ペイロード」は、BIERヘッダーの直後のパケットまたはフレームです。）IANAは、「BIER Next Protocol Identifiers」と呼ばれるレジストリを作成しました。このフィールドには、そのレジストリからの適切なエントリが入力されます。
If a BFER receives a BIER packet but does not recognize (or does not support) the value of the Next Protocol field, the BFER SHOULD discard the packet and log an error.
BFERがBIERパケットを受信しても、次のプロトコルフィールドの値を認識しない（またはサポートしない）場合、BFERはパケットを破棄してエラーをログに記録する必要があります（SHOULD）。
BFIR-id:
BFIR-id：
By default, this is the BFR-id of the BFIR, in the SD to which the packet has been assigned. The BFR-id is encoded in the 16-bit field as an unsigned integer in the range [1,65535].
デフォルトでは、これは、パケットが割り当てられているSD内のBFIRのBFR-idです。 BFR-idは、[1,65535]の範囲の符号なし整数として16ビットフィールドにエンコードされます。
Certain applications may require that the BFIR-id field contain the BFR-id of a BFR other than the BFIR. However, that usage of the BFIR-id field is outside the scope of this document.
特定のアプリケーションでは、BFIR-idフィールドにBFIR以外のBFRのBFR-idを含める必要がある場合があります。ただし、BFIR-idフィールドの使用は、このドキュメントの範囲外です。
BitString:
ビットストリング：
This field holds the BitString that, together with the packet's SI and SD, identifies the destination BFERs for this packet. Note that the SI and SD for the packet are not carried explicitly in the BIER header, as a particular BIFT-id always corresponds to a particular SI and SD.
このフィールドは、パケットのSIおよびSDとともに、このパケットの宛先BFERを識別するBitStringを保持します。特定のBIFT-idは常に特定のSIおよびSDに対応するため、パケットのSIおよびSDは、BIERヘッダーで明示的に伝達されないことに注意してください。
Sending a BIER packet from one BFR to another may require the packet to be further encapsulated. For example, in some scenarios it may be necessary to encapsulate a BIER packet in an Ethernet frame; in other scenarios it may be necessary to encapsulate a BIER packet in a UDP packet. In such cases, the BIER packet itself is the payload of an "outer" encapsulation.
BIERパケットをあるBFRから別のBFRに送信するには、パケットをさらにカプセル化する必要がある場合があります。たとえば、一部のシナリオでは、BIERパケットをイーサネットフレームにカプセル化する必要がある場合があります。他のシナリオでは、BIERパケットをUDPパケットにカプセル化する必要がある場合があります。このような場合、BIERパケット自体が「外部」カプセル化のペイロードです。
In this document, we assume that the frame or packet carrying a BIER packet as its payload is a unicast frame or packet. That is, although a BIER packet is a multicast packet, we assume that the frame or packet carrying the BIER packet as its payload is unicast from one BFR to the next.
このドキュメントでは、ペイロードとしてBIERパケットを伝送するフレームまたはパケットがユニキャストフレームまたはパケットであると想定しています。つまり、BIERパケットはマルチキャストパケットですが、BIERパケットをペイロードとして運ぶフレームまたはパケットは、1つのBFRから次のBFRへのユニキャストであると想定しています。
Generally, the outer encapsulation has a codepoint identifying the "next protocol". The outer encapsulation's "next protocol" codepoint for MPLS MUST be used. If a particular outer encapsulation has a codepoint for "MPLS with downstream-assigned label" and a different codepoint for "MPLS with upstream-assigned label", the codepoint for "MPLS with downstream-assigned label" MUST be used.
一般に、外部カプセル化には、「次のプロトコル」を識別するコードポイントがあります。 MPLSの外部カプセル化の「次のプロトコル」コードポイントを使用する必要があります。特定の外部カプセル化に「ダウンストリーム割り当てラベル付きMPLS」のコードポイントと「アップストリーム割り当てラベル付きMPLS」の異なるコードポイントがある場合、「ダウンストリーム割り当てラベル付きMPLS」のコードポイントを使用する必要があります。
For example, if a BIER packet is encapsulated in an Ethernet frame, the Ethertype MUST be 0x8847 [RFC5332], which is the Ethertype for a unicast Ethernet frame that carries an MPLS packet whose label stack begins with a downstream-assigned label.
たとえば、BIERパケットがイーサネットフレームにカプセル化されている場合、Ethertypeは0x8847 [RFC5332]である必要があります。これは、ラベルスタックがダウンストリーム割り当てラベルで始まるMPLSパケットを運ぶユニキャストイーサネットフレームのEthertypeです。
In the special case where the outer encapsulation is MPLS, the outer encapsulation has no "next protocol" codepoint. All that is needed to encapsulate the BIER packet is to push more MPLS label stack entries (with the S bit clear) on the BIER packet's label stack.
外部カプセル化がMPLSである特殊なケースでは、外部カプセル化に「次のプロトコル」コードポイントはありません。 BIERパケットをカプセル化するために必要なのは、BIERパケットのラベルスタックに（Sビットがクリアされた）より多くのMPLSラベルスタックエントリをプッシュすることだけです。
If two BIER packets have the same value in the entropy field of their respective BIER headers and if both are placed in an outer encapsulation, it is desirable for the outer encapsulation to preserve the fact that the two packets have the same entropy. If the outer encapsulation is MPLS and if the MPLS entropy label [RFC6790] is in use in a given deployment, one way to do this is to copy the value of the BIER header entropy field into an MPLS entropy label.
2つのBIERパケットのそれぞれのBIERヘッダーのエントロピーフィールドに同じ値があり、両方が外部カプセル化に配置されている場合、2つのパケットが同じエントロピーを持つという事実を外部カプセル化が保持することが望ましいです。外側のカプセル化がMPLSで、MPLSエントロピーラベル[RFC6790]が特定の展開で使用されている場合、これを行う1つの方法は、BIERヘッダーエントロピーフィールドの値をMPLSエントロピーラベルにコピーすることです。
In non-MPLS networks, a BIFT-id MUST be assigned for every combination of <SD, SI, BSL> that is to be used in that network. The correspondence between a BIFT-id and a particular <SD, SI, BSL> triple is unique throughout the BIER domain and is known to all the BFRs in the BIER domain.
非MPLSネットワークでは、そのネットワークで使用される<SD、SI、BSL>のすべての組み合わせにBIFT-idを割り当てる必要があります。 BIFT-idと特定の<SD、SI、BSL>トリプルの間の対応は、BIERドメイン全体で一意であり、BIERドメイン内のすべてのBFRに認識されています。
The means by which the BIFT-ids are assigned, and the means by which these assignments are made known to the BFRs, are outside the scope of this document.
BIFT-idが割り当てられる手段、およびこれらの割り当てがBFRに通知される手段は、このドキュメントの範囲外です。
In an MPLS network, since the BIFT-id is an MPLS label, its value may be changed as a BIER packet goes from BFR to BFR. In a non-MPLS network, since the BIFT-id is domain-wide unique, it is not expected to change as a BIER packet travels.
MPLSネットワークでは、BIFT-idはMPLSラベルであるため、BIERパケットがBFRからBFRに移動するときにその値が変更される可能性があります。非MPLSネットワークでは、BIFT-idはドメイン全体で一意であるため、BIERパケットが移動するときに変更されることはありません。
TC:
TC：
By default, the TC field has no significance in a non-MPLS network. The default behavior is that this field SHOULD be set to the binary value 000 upon transmission and MUST be ignored upon reception.
デフォルトでは、非MPLSネットワークではTCフィールドは重要ではありません。デフォルトの動作では、このフィールドは送信時にバイナリ値000に設定する必要があり（SHOULD）、受信時に無視する必要があります。
Non-default use of this field in non-MPLS networks is outside the scope of this document.
非MPLSネットワークでのこのフィールドのデフォルト以外の使用は、このドキュメントの範囲外です。
S bit:
Sビット：
The S bit has no significance in a non-MPLS network. It SHOULD be set to 1 upon transmission, but it MUST be ignored upon reception.
SMPビットは、非MPLSネットワークでは重要ではありません。送信時には1に設定する必要がありますが、受信時には無視する必要があります。
TTL:
TTL：
This is the BIER "Time to Live" field. Its purpose is to prevent BIER packets from looping indefinitely in the event of improper operation of the control plane. When a BIER packet is received, its "incoming TTL" (see below) is taken from this TTL field.
これは、BIERの「Time to Live」フィールドです。その目的は、コントロールプレーンが不適切に動作した場合にBIERパケットが無限にループするのを防ぐことです。 BIERパケットが受信されると、その「着信TTL」（下記を参照）がこのTTLフィールドから取得されます。
The effect of this field on the processing of a BIER packet is described in Section 2.1.1.2.
このフィールドがBIERパケットの処理に与える影響については、セクション2.1.1.2で説明します。
Nibble:
ニブル：
This field SHOULD be set to 0000 upon transmission but MUST be ignored upon reception.
このフィールドは送信時に0000に設定する必要がありますが、受信時には無視する必要があります。
Ver:
見る：
See Section 2.1.2.
セクション2.1.2を参照してください。
BSL:
BSL：
See Section 2.1.2.
セクション2.1.2を参照してください。
Entropy:
エントロピ：
See Section 2.1.2.
セクション2.1.2を参照してください。
OAM:
OAM：
See Section 2.1.2.
セクション2.1.2を参照してください。
Rsv:
Rsv：
See Section 2.1.2.
セクション2.1.2を参照してください。
DSCP:
DSCP：
This 6-bit field MAY be used to hold a Differentiated Services Codepoint [RFC2474]. The significance of this field is outside the scope of this document.
この6ビットフィールドは、Differentiated Services Codepoint [RFC2474]を保持するために使用される場合があります。このフィールドの重要性は、このドキュメントの範囲外です。
Proto:
したがって：
See Section 2.1.2.
セクション2.1.2を参照してください。
BFIR-id:
BFIR-id：
See Section 2.1.2.
セクション2.1.2を参照してください。
BitString:
ビットストリング：
See Section 2.1.2.
セクション2.1.2を参照してください。
Sending a BIER packet from one BFR to another may require the packet to be further encapsulated. For example, in some scenarios it may be necessary to encapsulate a BIER packet in an Ethernet frame; in other scenarios it may be necessary to encapsulate a BIER packet in a UDP packet. In such cases, the BIER packet itself is the payload of an "outer" encapsulation.
BIERパケットをあるBFRから別のBFRに送信するには、パケットをさらにカプセル化する必要がある場合があります。たとえば、一部のシナリオでは、BIERパケットをイーサネットフレームにカプセル化する必要がある場合があります。他のシナリオでは、BIERパケットをUDPパケットにカプセル化する必要がある場合があります。このような場合、BIERパケット自体が「外部」カプセル化のペイロードです。
In this document, we assume that the frame or packet carrying a BIER packet as its payload is a unicast frame or packet. That is, although a BIER packet is a multicast packet, we assume that the frame or packet carrying the BIER packet as its payload is unicast from one BFR to the next.
このドキュメントでは、ペイロードとしてBIERパケットを伝送するフレームまたはパケットがユニキャストフレームまたはパケットであると想定しています。つまり、BIERパケットはマルチキャストパケットですが、BIERパケットをペイロードとして運ぶフレームまたはパケットは、1つのBFRから次のBFRへのユニキャストであると想定しています。
Generally, the outer encapsulation has a codepoint identifying the "next protocol". This codepoint MUST be set to a value that means "non-MPLS BIER". In particular, a codepoint that means "MPLS" (with either upstream-assigned or downstream-assigned labels) MUST NOT be used.
一般に、外部カプセル化には、「次のプロトコル」を識別するコードポイントがあります。このコードポイントは、「非MPLS BIER」を意味する値に設定する必要があります。特に、「MPLS」を意味するコードポイント（上流割り当てまたは下流割り当てラベルのいずれかを使用）は使用してはなりません（MUST NOT）。
By requiring the use of a distinct codepoint for "non-MPLS BIER", we allow for deployment scenarios where non-MPLS BIER can coexist with non-BIER MPLS. The BIFT-id values used by the former will not conflict with MPLS label values used by the latter.
「非MPLS BIER」に別個のコードポイントを使用することを要求することにより、非MPLS BIERが非BIER MPLSと共存できる配置シナリオが可能になります。前者が使用するBIFT-id値は、後者が使用するMPLSラベル値と競合しません。
Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332]. IEEE has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
したがって、非MPLS BIERパケットがイーサネットヘッダーにカプセル化される場合、Ethertypeは0x8847または0x8848 [RFC5332]であってはなりません（MUST NOT）。 IEEEは、非MPLS BIERパケットにEthertype 0xAB37を割り当てています。
In the special case where the outer encapsulation is MPLS, the outer encapsulation has no "next protocol" codepoint. If it is necessary to use MPLS as an outer encapsulation for BIER packets, it is RECOMMENDED to use the MPLS encapsulation for BIER. Procedures for encapsulating a non-MPLS BIER packet in MPLS are outside the scope of this document.
外部カプセル化がMPLSである特殊なケースでは、外部カプセル化に「次のプロトコル」コードポイントはありません。 MPLSをBIERパケットの外部カプセル化として使用する必要がある場合は、BIERにMPLSカプセル化を使用することをお勧めします。 MPLSで非MPLS BIERパケットをカプセル化する手順は、このドキュメントの範囲外です。
If two BIER packets have the same value in the entropy field of their respective BIER headers and if both are placed in an outer encapsulation, it is desirable for the outer encapsulation to preserve the fact that the two packets have the same entropy.
2つのBIERパケットのそれぞれのBIERヘッダーのエントロピーフィールドに同じ値があり、両方が外部カプセル化に配置されている場合、2つのパケットが同じエントロピーを持つという事実を外部カプセル化が保持することが望ましいです。
Each BFIR is expected to know the Maximum Transmission Unit (MTU) of the BIER domain. This may be known by provisioning, or by some other method outside the scope of this document. Each BFIR also knows the size of the BIER encapsulation. Thus, each BFIR can deduce the maximum size of the payload that can be encapsulated in a BIER packet. We will refer to this payload size as the BIER-MTU.
各BFIRは、BIERドメインの最大伝送ユニット（MTU）を知っていることが期待されます。これは、プロビジョニング、またはこのドキュメントの範囲外のその他の方法で認識される場合があります。各BFIRは、BIERカプセル化のサイズも認識しています。したがって、各BFIRは、BIERパケットにカプセル化できるペイロードの最大サイズを推定できます。このペイロードサイズをBIER-MTUと呼びます。
If a BFIR receives a multicast packet from outside the BIER domain and the packet size exceeds the BIER-MTU, the BFIR takes whatever action is appropriate to take when receiving a multicast packet that is too large to be forwarded to all its next hops. If the appropriate action is to drop the packet and advertise an MTU to the source, then the BFIR drops the packet and advertises the BIER-MTU. If the appropriate action is to fragment the packet, then the procedures of this section are applied, in sequence, to each fragment.
BFIRがBIERドメインの外部からマルチキャストパケットを受信し、パケットサイズがBIER-MTUを超える場合、BFIRは、大きすぎて次のすべてのホップに転送できないマルチキャストパケットを受信するときに適切なアクションを実行します。適切なアクションがパケットをドロップし、MTUをソースにアドバタイズすることである場合、BFIRはパケットをドロップし、BIER-MTUをアドバタイズします。適切なアクションがパケットのフラグメント化である場合、このセクションの手順が各フラグメントに順番に適用されます。
When a BFIR processes a multicast packet (or fragment thereof) from outside the BIER domain, the BFIR carries out the following procedure:
BFIRがBIERドメインの外部からのマルチキャストパケット（またはそのフラグメント）を処理する場合、BFIRは次の手順を実行します。
1. By consulting the "multicast flow overlay" [RFC8279], it determines the value of the Proto field.
1. 「マルチキャストフローオーバーレイ」[RFC8279]を参照して、Protoフィールドの値を決定します。
2. By consulting the multicast flow overlay, it determines the set of BFERs that must receive the packet.
2. マルチキャストフローオーバーレイを調べて、パケットを受信する必要があるBFERのセットを決定します。
3. If more than one SD is supported, the BFIR assigns the packet to a particular SD. Procedures for determining the SD to which a particular packet should be assigned are outside the scope of this document.
3. 複数のSDがサポートされている場合、BFIRはパケットを特定のSDに割り当てます。特定のパケットを割り当てるSDを決定する手順は、このドキュメントの範囲外です。
4. The BFIR looks up the BFR-id, in the given SD, of each of the BFERs.
4. BFIRは、指定されたSDで、各BFERのBFR-idを検索します。
5. The BFIR converts each such BFR-id into "SI:BitString" format, as described in [RFC8279].
5. [RFC8279]で説明されているように、BFIRはそのような各BFR-idを「SI：BitString」形式に変換します。
6. All such BFR-ids that have the same SI can be encoded into the same BitString. Details of this encoding can be found in [RFC8279]. For each distinct SI that occurs in the list of the packet's destination BFERs:
6. 同じSIを持つすべてのそのようなBFR-idは、同じBitStringにエンコードできます。このエンコーディングの詳細は[RFC8279]にあります。パケットの宛先BFERのリストで発生する個別のSIごとに：
a. The BFIR makes a copy of the multicast data packet and encapsulates the copy in a BIER header (see Section 2). The BIER header contains the BitString that represents all the destination BFERs whose BFR-ids (in the given SD) correspond to the given SI. It also contains the BFIR's BFR-id in the SD to which the packet has been assigned.
a. BFIRは、マルチキャストデータパケットのコピーを作成し、そのコピーをBIERヘッダーにカプセル化します（セクション2を参照）。 BIERヘッダーには、BFR-id（特定のSD内）が特定のSIに対応するすべての宛先BFERを表すBitStringが含まれています。また、パケットが割り当てられているSD内のBFIRのBFR-idも含まれています。
Note well that for certain applications it may be necessary for the BFIR-id field to contain the BFR-id of a BFR other than the BFIR that is creating the header. Such uses are outside the scope of this document.
特定のアプリケーションでは、BFIR-idフィールドに、ヘッダーを作成しているBFIR以外のBFRのBFR-idを含める必要がある場合があることに注意してください。このような用途は、このドキュメントの範囲外です。
b. The BFIR then applies to that copy the forwarding procedure of [RFC8279]. This may result in one or more copies of the packet (possibly with a modified BitString) being transmitted to a neighboring BFR.
b. 次に、BFIRはそのコピーに[RFC8279]の転送手順を適用します。これにより、パケットの1つ以上のコピーが（おそらく変更されたBitStringとともに）隣接するBFRに送信されます。
c. If the non-MPLS BIER encapsulation is being used, the BIFT-id field is set to the BIFT-id that corresponds to the packet's <SD, SI, BSL>. The TTL is set according to policy.
c. 非MPLS BIERカプセル化が使用されている場合、BIFT-idフィールドは、パケットの<SD、SI、BSL>に対応するBIFT-idに設定されます。 TTLはポリシーに従って設定されます。
If the MPLS BIER encapsulation is being used, the BFIR finds the BIER-MPLS label that was advertised by the neighbor as corresponding to the given <SD, SI, BSL>. An MPLS label stack is then prepended to the packet. This label stack [RFC3032] will contain one label -- the aforementioned BIER-MPLS label. The S bit MUST be set, indicating the end of the MPLS label stack. The TTL field of this label stack entry is set according to policy.
MPLS BIERカプセル化が使用されている場合、BFIRは、ネイバーによってアドバタイズされたBIER-MPLSラベルを、指定された<SD、SI、BSL>に対応するものとして見つけます。次に、MPLSラベルスタックがパケットの先頭に追加されます。このラベルスタック[RFC3032]には、前述のBIER-MPLSラベルという1つのラベルが含まれます。 MPLSラベルスタックの終わりを示すSビットを設定する必要があります。このラベルスタックエントリのTTLフィールドは、ポリシーに従って設定されます。
d. The packet may then be transmitted to the neighboring BFR. (In an MPLS network, this may result in additional MPLS labels being pushed on the stack. For example, if an RSVP-TE tunnel is used to transmit packets to the neighbor, a label representing that tunnel would be pushed onto the stack.)
d. その後、パケットは隣接するBFRに送信されます。 （MPLSネットワークでは、これによりスタックに追加のMPLSラベルがプッシュされる可能性があります。たとえば、RSVP-TEトンネルを使用してパケットをネイバーに送信すると、そのトンネルを表すラベルがスタックにプッシュされます。
When an intermediate BFR is processing a received MPLS packet and one of the BFR's own BIER-MPLS labels rises to the top of the label stack, the BFR infers the BSL from the label. The SI and SD are also implicitly identified by the label. The BFR then follows the forwarding procedures of [RFC8279]. If it forwards a copy of the packet to a neighboring BFR, it first swaps the label at the top of the label stack with the BIER-MPLS label, advertised by that neighbor, that corresponds to the same <SD, SI, BSL>. Note that when this swap operation is done, the TTL field of the BIER-MPLS label of the outgoing packet MUST be one less than the "incoming TTL" of the packet, as defined in Section 2.1.1.2.
中間BFRが受信したMPLSパケットを処理していて、BFR自身のBIER-MPLSラベルの1つがラベルスタックの最上位に上昇すると、BFRはラベルからBSLを推測します。 SIとSDもラベルによって暗黙的に識別されます。次に、BFRは[RFC8279]の転送手順に従います。パケットのコピーを隣接するBFRに転送する場合、最初に、ラベルスタックの最上部のラベルを、同じネイバーによってアドバタイズされた、同じ<SD、SI、BSL>に対応するBIER-MPLSラベルと交換します。このスワップ操作が実行されるとき、送信パケットのBIER-MPLSラベルのTTLフィールドは、セクション2.1.1.2で定義されているように、パケットの「受信TTL」より1小さい必要があることに注意してください。
When an intermediate BFR is processing a received non-MPLS BIER packet, the BFR infers the BSL from the BIFT-id. The SI and SD are also implicitly identified by the BIFT-id. The BFR then follows the forwarding procedures of [RFC8279].
中間BFRが受信した非MPLS BIERパケットを処理しているとき、BFRはBIFT-idからBSLを推測します。 SIとSDも、BIFT-idによって暗黙的に識別されます。次に、BFRは[RFC8279]の転送手順に従います。
If the BIER payload is an MPLS packet, the BIER header is followed by an MPLS label stack. This stack is separate from any MPLS stack that may precede the BIER header. For an example of an application where it is useful to carry an MPLS packet as the BIER payload, see [BIER_MVPN]. If the BIER encapsulation's Proto field indicates that the payload is an MPLS packet with an upstream-assigned label at the top of the stack, the upstream-assigned label is interpreted in the context of <BFIR-id, sub-domain-id>. Note that the sub-domain-id must be inferred from the BIFT-id.
BIERペイロードがMPLSパケットの場合、BIERヘッダーの後にMPLSラベルスタックが続きます。このスタックは、BIERヘッダーの前にあるMPLSスタックとは別です。 MPLSパケットをBIERペイロードとして伝送すると便利なアプリケーションの例については、[BIER_MVPN]を参照してください。 BIERカプセル化のプロトフィールドが、ペイロードがスタックの最上部に上流割り当てラベルが付いたMPLSパケットであることを示している場合、上流割り当てラベルは<BFIR-id、sub-domain-id>のコンテキストで解釈されます。 sub-domain-idはBIFT-idから推測する必要があることに注意してください。
IANA has set up a registry called "BIER Next Protocol Identifiers". The registration policy for this registry is "IETF Review" [RFC8126] [RFC7120].
IANAは、「BIER Next Protocol Identifiers」と呼ばれるレジストリを設定しています。このレジストリの登録ポリシーは「IETFレビュー」[RFC8126] [RFC7120]です。
The initial values in the "BIER Next Protocol Identifiers" registry are:
「BIER Next Protocol Identifiers」レジストリの初期値は次のとおりです。
0: Reserved
0：予約済み
1: MPLS packet with downstream-assigned label at top of stack
1：スタックの最上部にダウンストリームが割り当てられたラベルを持つMPLSパケット
2: MPLS packet with upstream-assigned label at top of stack
2：スタックの最上部にアップストリームが割り当てられたラベルを持つMPLSパケット
3: Ethernet frame
3：イーサネットフレーム
4: IPv4 packet
4：IPv4パケット
5: OAM packet (Reference: [BIER_PING])
5：OAMパケット（参照：[BIER_PING]）
6: IPv6 packet
6：IPv6パケット
63: Reserved
63：予約済み
IEEE has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
IEEEは、非MPLS BIERパケットにEthertype 0xAB37を割り当てています。
Insofar as this document makes use of MPLS, it inherits any security considerations that apply to the use of the MPLS data plane.
このドキュメントがMPLSを使用する限り、MPLSデータプレーンの使用に適用されるセキュリティ上の考慮事項を継承します。
If a BIER encapsulation header is modified in ways other than those specified in [RFC8279] and in this document, packets may be lost, stolen, or otherwise misdelivered. Such modifications are likely to go undetected, as the BIER encapsulation does not provide cryptographic integrity protection.
[RFC8279]およびこのドキュメントで指定されている以外の方法でBIERカプセル化ヘッダーが変更された場合、パケットが失われたり、盗まれたり、その他の方法で誤配信される可能性があります。 BIERカプセル化は暗号化の完全性保護を提供しないため、このような変更は検出されない可能性があります。
Layer 2 encryption can be used to ensure that a BIER-encapsulated packet is not altered while in transit between adjacent BFRs. If a BFR itself is compromised, there is no way to prevent the compromised BFR from making illegitimate modifications to the BIER header or to prevent it from misforwarding or misdelivering the BIER-encapsulated packet.
レイヤー2暗号化を使用して、BIERカプセル化パケットが隣接するBFR間の転送中に変更されないようにすることができます。 BFR自体が侵害された場合、侵害されたBFRがBIERヘッダーに不正な変更を加えたり、BIERカプセル化されたパケットを誤って転送または配信したりするのを防ぐ方法はありません。
If the routing underlay (see Section 4.1 of [RFC8279]) is based on a unicast routing protocol, BIER assumes that the routers participating in the unicast routing protocol have not been compromised. BIER has no procedures to ensure that the unicast routing adjacencies have not been compromised; that falls within the scope of whatever unicast routing protocols are being used.
ルーティングアンダーレイ（[RFC8279]のセクション4.1を参照）がユニキャストルーティングプロトコルに基づいている場合、BIERは、ユニキャストルーティングプロトコルに参加しているルーターが危険にさらされていないと想定します。 BIERには、ユニキャストルーティング隣接が危険にさらされていないことを確認する手順はありません。これは、使用されているユニキャストルーティングプロトコルの範囲に含まれます。
BIER-encapsulated packets should generally not be accepted from untrusted interfaces or tunnels. For example, an operator may wish to have a policy of accepting BIER-encapsulated packets only from interfaces to trusted routers, and not from customer-facing interfaces.
一般に、BIERでカプセル化されたパケットは、信頼できないインターフェイスまたはトンネルから受け入れられるべきではありません。たとえば、オペレータは、信頼できるルータへのインターフェイスからのみ、顧客側のインターフェイスからではなく、BIERでカプセル化されたパケットを受け入れるポリシーを希望する場合があります。
There may be applications that require a BFR to accept a BIER-encapsulated packet from an interface to a system that is not controlled by the network operator. For instance, there may be an application in which a virtual machine in a data center submits BIER-encapsulated packets to a router. In such a case, it is desirable to verify that the packet is from a legitimate source and that its BitString denotes only systems to which that source is allowed to send. However, the BIER encapsulation itself does not provide a way to verify that the source is (1) legitimate, (2) really the system denoted by the BFIR-id, or (3) allowed to set any particular set of bits in the BitString.
ネットワークオペレータによって制御されていないシステムへのインターフェイスからのBIERカプセル化パケットを受け入れるためにBFRを必要とするアプリケーションがあるかもしれません。たとえば、データセンターの仮想マシンがBIERカプセル化パケットをルーターに送信するアプリケーションがある場合があります。このような場合、パケットが正当な送信元からのものであり、そのBitStringが、その送信元が送信を許可されているシステムのみを示していることを確認することが望ましいです。ただし、BIERカプセル化自体は、ソースが（1）正当である、（2）実際にBFIR-idで示されるシステムである、または（3）BitStringで特定のビットセットを設定できることを確認する方法を提供しません。
Insofar as this document relies upon IGP extensions, it inherits any security considerations that apply to the IGP.
このドキュメントがIGP拡張機能に依存している限り、それはIGPに適用されるセキュリティの考慮事項を継承します。
The security considerations of [RFC8279] also apply.
[RFC8279]のセキュリティに関する考慮事項も適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、DOI 10.17487 / RFC3032、2001年1月、<https://www.rfc-editor.org/info/rfc3032>。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<https：//www.rfc -editor.org/info/rfc5331>。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>.
[RFC5332] Eckert、T.、Rosen、E.、Ed。、Aggarwal、R。、およびY. Rekhter、「MPLSマルチキャストカプセル化」、RFC 5332、DOI 10.17487 / RFC5332、2008年8月、<https：// www。 rfc-editor.org/info/rfc5332>。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5462] Andersson、L。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP」Field Renamed to" Traffic Class "Field」、RFC 5462、DOI 10.17487 / RFC5462、2009年2月、<https： //www.rfc-editor.org/info/rfc5462>。
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7120] Cotton、M。、「Early IANA Allocation of Standards Track Code Points」、BCP 100、RFC 7120、DOI 10.17487 / RFC7120、2014年1月、<https://www.rfc-editor.org/info/rfc7120> 。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.
[RFC8279] Wijnands、IJ。、Ed。、Rosen、E.、Ed。、Dolganow、A.、Przygienda、T.、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>。
[BGP_BIER_EXTENSIONS] Xu, X., Ed., Chen, M., Patel, K., Wijnands, IJ., and A. Przygienda, "BGP Extensions for BIER", Work in Progress, draft-ietf-bier-idr-extensions-04, January 2018.
[BGP_BIER_EXTENSIONS] Xu、X.、Ed。、Chen、M.、Patel、K.、Wijnands、IJ。、およびA. Przygienda、「BIERのBGP拡張機能」、Work in Progress、draft-ietf-bier-idr- extensions-04、2018年1月。
[BIER-PMM] Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Work in Progress, draft-ietf-bier-pmmm-oam-03, October 2017.
[BIER-PMM] Mirsky、G.、Zheng、L.、Chen、M。、およびG. Fioccola、「ビットインデックスエクスプリシットレプリケーション（BIER）レイヤーでのマーキング方式によるパフォーマンス測定（PM）」、進行中の作業、ドラフト-ietf-bier-pmmm-oam-03、2017年10月。
[BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Przygienda, "Multicast VPN Using BIER", Work in Progress, draft-ietf-bier-mvpn-09, November 2017.
[BIER_MVPN] Rosen、E.、Ed。、Sivakumar、M.、Aldrin、S.、Dolganow、A。、およびT. Przygienda、「BIERを使用したマルチキャストVPN」、Work in Progress、draft-ietf-bier-mvpn- 2017年11月9日。
[BIER_PING] Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", Work in Progress, draft-ietf-bier-ping-02, July 2017.
[BIER_PING] Kumar、N.、Pignataro、C.、Akiya、N.、Zheng、L.、Chen、M。、およびG. Mirsky、「BIER Ping and Trace」、Work in Progress、draft-ietf-bier- ping-02、2017年7月。
[ISIS_BIER_EXTENSIONS] Ginsberg, L., Ed., Przygienda, A., Aldrin, S., and J. Zhang, "BIER support via ISIS", Work in Progress, draft-ietf-bier-isis-extensions-06, October 2017.
[ISIS_BIER_EXTENSIONS] Ginsberg、L.、Ed。、Przygienda、A.、Aldrin、S。、およびJ. Zhang、「ISISによるBIERサポート」、作業中、draft-ietf-bier-isis-extensions-06、10月2017。
[OSPF_BIER_EXTENSIONS] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions for BIER", Work in Progress, draft-ietf-bier-ospf-bier-extensions-10, December 2017.
[OSPF_BIER_EXTENSIONS] Psenak、P.、Ed。、Kumar、N.、Wijnands、IJ。、Dolganow、A.、Przygienda、T.、Zhang、J。、およびS. Aldrin、「OSPF Extensions for BIER」、Work in進捗、draft-ietf-bier-ospf-bier-extensions-10、2017年12月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W.、and L. Yong、 "The Use of Entropy Labels in MPLS Forwarding"、RFC 6790、DOI 10.17487 / RFC6790、November 2012、 <https://www.rfc-editor.org/info/rfc6790>。
Acknowledgements
謝辞
The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, Xiaohu Xu, and Jeffrey Zhang for their ideas and contributions to this work.
著者は、この作業へのアイデアと貢献について、Rajiv Asati、John Bettink、Nagendra Kumar、Christian Martin、Neale Ranns、Greg Shepherd、Ramji Vaithianathan、Xiaohu Xu、およびJeffrey Zhangに感謝します。
Contributors
貢献者
The following people (listed in alphabetical order) contributed significantly to the content of this document and should be considered co-authors:
次の人々（アルファベット順）は、このドキュメントの内容に大きく貢献し、共著者と見なされます。
Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com
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 Uwe Joorde Deutsche Telekom Hammer Str. 216-226 Muenster D-48153 Germany Email: Uwe.Joorde@telekom.de
マーティンホーネファードイツテレコムハンマーStr。 216-226 Muenster 48153ドイツEメール：Martin.Horneffer@telekom.de Uwe Joorde Deutsche Telekom Hammer Str。 216-226 Muenster D-48153ドイツEメール：Uwe.Joorde@telekom.de
Tony Przygienda Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, California 94089 United States of America Email: prz@juniper.net
Tony Przygienda Juniper Networks、Inc. 1194 N. Mathilda Ave. Sunnyvale、California 94089アメリカ合衆国メール：prz@juniper.net
Authors' Addresses
著者のアドレス
IJsbrand Wijnands (editor) Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com
IJsbrand Wijnands（編集者）Cisco Systems、Inc. De Kleetlaan 6a Diegem 1831ベルギーメール：ice@cisco.com
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America Email: erosen@juniper.net
Eric C. Rosen（編集者）Juniper Networks、Inc. 10 Technology Park Drive Westford、Massachusetts 01886アメリカ合衆国メール：erosen@juniper.net
Andrew Dolganow Nokia 438B Alexandra Rd #08-07/10 Alexandra Technopark Singapore 119968 Singapore Email: andrew.dolganow@nokia.com
Andrew Dolganow Nokia 438B Alexandra Rd＃08-07 / 10 Alexandra Technopark Singapore 119968 Singaporeメール：andrew.dolganow@nokia.com
Jeff Tantsura Individual Email: jefftant.ietf@gmail.com
ジェフタンチュラ個人メール：jefftant.ietf@gmail.com
Sam K. Aldrin Google, Inc. 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America Email: aldrin.ietf@gmail.com
Sam K. Aldrin Google、Inc. 1600 Amphitheatre Parkway Mountain View、California 94043 United States Email：aldrin.ietf@gmail.com
Israel Meilik Broadcom Email: israel@broadcom.com
イスラエルがBroadcomのメールを所有：israel@broadcom.com