[要約] RFC 9262 は、BIER-TE（Tree Engineering for Bit Index Explicit Replication）についての要約です。BIER-TEは、Traffic Engineering with BIERのためのパス制御メカニズムとして使用され、ネットワークトポロジーの隣接関係を示す新しいセマンティクスを導入します。
Internet Engineering Task Force (IETF) T. Eckert, Ed.
Request for Comments: 9262 Futurewei
Category: Standards Track M. Menth
ISSN: 2070-1721 University of Tuebingen
G. Cauchie
KOEVOO
October 2022
Tree Engineering for Bit Index Explicit Replication (BIER-TE)
ビットインデックス明示的複製のツリーエンジニアリング（Bier-TE）
Abstract
概要
This memo describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index Explicit Replication" (BIER) packets (RFC 8279); it is called "Tree Engineering for Bit Index Explicit Replication" (BIER-TE) and is intended to be used as the path steering mechanism for Traffic Engineering with BIER.
このメモでは、パケットごとのステートレスの厳格でゆるいパス操縦レプリケーションと「ビットインデックス明示的複製」（BIER）パケット（RFC 8279）の転送について説明しています。「ビットインデックスの明示的複製のツリーエンジニアリング」（Bier-TE）と呼ばれ、Bierを使用した交通工学のパスステアリングメカニズムとして使用することを目的としています。
BIER-TE introduces a new semantic for "bit positions" (BPs). These BPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded by BIER-TE. BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible -- for example, by using separate BIER "subdomains" (SDs). Except for the optional routed adjacencies, BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "Interior Gateway Protocol" (IGP).
Bierteは、「ビットポジション」（BPS）の新しいセマンティックを紹介します。これらのBPは、BPSが「ビットフォワードエグレスルーター」（BFERS）を示す（非）ビアとは対照的に、ネットワークトポロジの隣接を示しています。したがって、ビアテの「パケットビットストリング」は、パケットがビアテによって転送される（ループフリーの）ツリーのエッジを示します。BierTTEは、ほとんど変更されていないビア転送エンジンを活用できます。同じドメインでのビアとビアテの転送の共存は可能です - たとえば、個別のビア「サブドメイン」（SDS）を使用することにより。オプションのルーティングされた隣接を除いて、BierTTEはビアールーティングアンダーレイを必要とせず、したがって、「インテリアゲートウェイプロトコル」（IGP）などのルーティングプロトコルに依存せずに動作できます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9262.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9262で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Overview
2. Introduction
2.1. Requirements Language
2.2. Basic Examples
2.3. BIER-TE Topology and Adjacencies
2.4. Relationship to BIER
2.5. Accelerated Hardware Forwarding Comparison
3. Components
3.1. The Multicast Flow Overlay
3.2. The BIER-TE Control Plane
3.2.1. The BIER-TE Controller
3.2.1.1. BIER-TE Topology Discovery and Creation
3.2.1.2. Engineered Trees via BitStrings
3.2.1.3. Changes in the Network Topology
3.2.1.4. Link/Node Failures and Recovery
3.3. The BIER-TE Forwarding Plane
3.4. The Routing Underlay
3.5. Traffic Engineering Considerations
4. BIER-TE Forwarding
4.1. The BIER-TE Bit Index Forwarding Table (BIFT)
4.2. Adjacency Types
4.2.1. Forward Connected
4.2.2. Forward Routed
4.2.3. ECMP
4.2.4. Local Decap(sulation)
4.3. Encapsulation / Co-existence with BIER
4.4. BIER-TE Forwarding Pseudocode
4.5. BFR Requirements for BIER-TE Forwarding
5. BIER-TE Controller Operational Considerations
5.1. Bit Position Assignments
5.1.1. P2P Links
5.1.2. BFERs
5.1.3. Leaf BFERs
5.1.4. LANs
5.1.5. Hub and Spoke
5.1.6. Rings
5.1.7. Equal-Cost Multipath (ECMP)
5.1.8. Forward Routed Adjacencies
5.1.8.1. Reducing Bit Positions
5.1.8.2. Supporting Nodes without BIER-TE
5.1.9. Reuse of Bit Positions (without DNC)
5.1.10. Summary of BP Optimizations
5.2. Avoiding Duplicates and Loops
5.2.1. Loops
5.2.2. Duplicates
5.3. Managing SIs, Subdomains, and BFR-ids
5.3.1. Why SIs and Subdomains?
5.3.2. Assigning Bits for the BIER-TE Topology
5.3.3. Assigning BFR-ids with BIER-TE
5.3.4. Mapping from BFRs to BitStrings with BIER-TE
5.3.5. Assigning BFR-ids for BIER-TE
5.3.6. Example Bit Allocations
5.3.6.1. With BIER
5.3.6.2. With BIER-TE
5.3.7. Summary
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. BIER-TE and Segment Routing (SR)
Acknowledgements
Authors' Addresses
"Tree Engineering for Bit Index Explicit Replication" (BIER-TE) is based on the (non-TE) BIER architecture, terminology, and packet formats as described in [RFC8279] and [RFC8296]. This document describes BIER-TE, with the expectation that the reader is familiar with these two documents.
「ビットインデックスのツリーエンジニアリング明示的複製」（Bier-TE）は、[RFC8279]および[RFC8296]で説明されているように、（非TE）ビアアーキテクチャ、用語、およびパケット形式に基づいています。このドキュメントは、読者がこれらの2つのドキュメントに精通していることを期待して、BierTEについて説明しています。
BIER-TE introduces a new semantic for "bit positions" (BPs). These BPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded by BIER-TE. With BIER-TE, the "Bit Index Forwarding Table" (BIFT) of each "Bit-Forwarding Router" (BFR) is only populated with BPs that are adjacent to the BFR in the BIER-TE topology. Other BPs are empty in the BIFT. The BFR replicates and forwards BIER packets to adjacent BPs that are set in the packets. BPs are normally also cleared upon forwarding to avoid duplicates and loops.
Bierteは、「ビットポジション」（BPS）の新しいセマンティックを紹介します。これらのBPは、BPSが「ビットフォワードエグレスルーター」（BFERS）を示す（非）ビアとは対照的に、ネットワークトポロジの隣接を示しています。したがって、ビアテの「パケットビットストリング」は、パケットがビアテによって転送される（ループフリーの）ツリーのエッジを示します。BierTEを使用すると、各「ビットフォワードルーター」（BFR）の「ビットインデックス転送テーブル」（BIFT）には、BierTEトポロジのBFRに隣接するBPSのみが入力されます。他のBPはBIFTで空です。BFRは、パケットに設定された隣接するBPSにビアパケットを再現および転送します。BPSは通常、重複やループを避けるために転送時にクリアされます。
BIER-TE can leverage BIER forwarding engines with little or no changes. It can also co-exist with BIER forwarding in the same domain -- for example, by using separate BIER subdomains. Except for the optional routed adjacencies, BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "Interior Gateway Protocol" (IGP).
Bier-TEは、変更なしでビア転送エンジンを活用できます。また、同じドメインでのビア転送と共存することもできます。たとえば、個別のビアサブドメインを使用することにより。オプションのルーティングされた隣接を除いて、BierTTEはビアールーティングアンダーレイを必要とせず、したがって、「インテリアゲートウェイプロトコル」（IGP）などのルーティングプロトコルに依存せずに動作できます。
This document is structured as follows:
このドキュメントは次のように構成されています。
* Section 2 introduces BIER-TE with two forwarding examples, followed by an introduction to the new concepts of the BIER-TE (overlay) topology, and finally a summary of the relationship between BIER and BIER-TE and a discussion of accelerated hardware forwarding.
* セクション2では、2つの転送例を備えたBierTEを紹介し、その後、BierTe（オーバーレイ）トポロジの新しい概念の紹介、そして最後にBierとBierTeの関係の概要と、加速ハードウェア転送の議論を紹介します。
* Section 3 describes the components of the BIER-TE architecture: the multicast flow overlay, the BIER-TE layer with the BIER-TE control plane (including the BIER-TE controller), the BIER-TE forwarding plane, and the routing underlay.
* セクション3では、ビアテアーキテクチャのコンポーネント：マルチキャストフローオーバーレイ、ビアテコントロールプレーン（ビアテコントローラーを含む）を備えたビアテレイヤー、ビアテポローワーフォワーリングプレーン、ルーティングアンダーレイについて説明します。
* Section 4 specifies the behavior of the BIER-TE forwarding plane with the different types of adjacencies and possible variations of BIER-TE forwarding pseudocode, and finally the mandatory and optional requirements.
* セクション4では、さまざまな種類の隣接とビアテ転送の可能なバリエーションを備えたビアテ転送面の動作を指定し、最後に必須およびオプションの要件を指定します。
* Section 5 describes operational considerations for the BIER-TE controller, primarily how the BIER-TE controller can optimize the use of BPs by using specific types of BIER-TE adjacencies for different types of topological situations. It also describes how to assign bits to avoid loops and duplicates (which, in BIER-TE, does not come "for free"). Finally, it discusses how "Set Identifiers" (SIs), "subdomains" (SDs), and BFR-ids can be managed by a BIER-TE controller; examples and a summary are provided.
* セクション5では、BierTTEコントローラーの運用上の考慮事項について説明します。主に、さまざまな種類のトポロジー状況に対して特定のタイプのBier-TE隣接を使用して、BierTEコントローラーがBPSの使用を最適化する方法について説明します。また、ループや複製を避けるためにビットを割り当てる方法についても説明しています（ビアテでは「無料で」来ることはありません）。最後に、「識別子のセット」（SIS）、「サブドメイン」（SDS）、およびBFR-IDがBier-TEコントローラーによってどのように管理できるかについて説明します。例と要約が提供されます。
* Appendix A concludes this document; details regarding the relationship between BIER-TE and "Segment Routing" (SR) are discussed.
* 付録Aはこのドキュメントを結論付けています。Bier-TEと「セグメントルーティング」（SR）の関係に関する詳細について説明します。
Note that related work [CONSTRAINED-CAST] uses Bloom filters [Bloom70] to represent leaves or edges of the intended delivery tree. Bloom filters in general can support larger trees/topologies with fewer addressing bits than explicit BitStrings, but they introduce the heuristic risk of false positives and cannot clear bits in the BitStrings during forwarding to avoid loops. For these reasons, BIER-TE, like BIER, uses explicit BitStrings. Explicit BitStrings as used by BIER-TE can also be seen as a special type of Bloom filter, and this is how other related work [ICC] describes it.
関連する作業[制約付きキャスト]は、Bloom Filters [Bloom70]を使用して、意図した配信ツリーの葉または端を表すことに注意してください。一般的にブルームフィルターは、明示的なビットストリングよりもアドレス指定ビットが少ない大きな木/トポロジーをサポートできますが、誤検知のヒューリスティックリスクを導入し、転送中にビットストリングのビットをクリアすることはできません。これらの理由により、BierTTはBierと同様に、明示的なビットストリングを使用しています。BierTTEが使用する明示的なビットストリングは、特別なタイプのブルームフィルターとも見なすことができます。これは、他の関連作業[ICC]がそれを説明する方法です。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
BIER-TE forwarding is best introduced with simple examples. These examples use formal terms defined later in this document (Figure 4 in Section 4.1), including forward_connected(), forward_routed(), and local_decap().
Bier-TEの転送は、簡単な例で紹介するのが最適です。これらの例では、Forward_Connected（）、Forward_Routed（）、およびlocal_decap（）を含む、このドキュメントの後半で定義された正式な用語（セクション4.1の図4）を使用します。
Consider the simple network in the BIER-TE overview example shown in Figure 1, with six BFRs. p1...p15 are the bit positions used. All BFRs can act as a "Bit-Forwarding Ingress Router" (BFIR); BFR1, BFR3, BFR4, and BFR6 can also be BFERs. "Forward_connected()" is the name used for adjacencies that represent subnet adjacencies of the network. "Local_decap()" is the name used for the adjacency that decapsulates BIER-TE packets and passes their payload to higher-layer processing.
6つのBFRを持つ図1に示すビアテの概要例の単純なネットワークを考えてみましょう。P1 ... P15は使用されるビット位置です。すべてのBFRは、「ビットフォワードイングレスルーター」（BFIR）として機能することができます。BFR1、BFR3、BFR4、およびBFR6もBFERである可能性があります。「Forward_Connected（）」は、ネットワークのサブネット隣接を表す隣接に使用される名前です。「local_decap（）」は、隣接するために使用される名前で、ビアテパケットを脱カプセル化し、ペイロードを高層処理に渡すことです。
BIER-TE Topology:
Bierteトポロジ：
Diagram:
図：
p5 p6
--- BFR3 ---
p3/ p13 \p7 p15
BFR1 ---- BFR2 BFR5 ----- BFR6
p1 p2 p4\ p14 /p10 p11 p12
--- BFR4 ---
p8 p9
(simplified) BIER-TE Bit Index Forwarding Tables (BIFTs):
（簡素化）Bier-TEビットインデックス転送表（BIFTS）：
BFR1: p1 -> local_decap()
p2 -> forward_connected() to BFR2
BFR2: p1 -> forward_connected() to BFR1
p5 -> forward_connected() to BFR3
p8 -> forward_connected() to BFR4
BFR3: p3 -> forward_connected() to BFR2
p7 -> forward_connected() to BFR5
p13 -> local_decap()
BFR4: p4 -> forward_connected() to BFR2
p10 -> forward_connected() to BFR5
p14 -> local_decap()
BFR5: p6 -> forward_connected() to BFR3
p9 -> forward_connected() to BFR4
p12 -> forward_connected() to BFR6
BFR6: p11 -> forward_connected() to BFR5
p15 -> local_decap()
Figure 1: BIER-TE Basic Example
図1：Bierte Basic Example
Assume that a packet from BFR1 should be sent via BFR4 to BFR6. This requires a BitString (p2,p8,p10,p12,p15). When this packet is examined by BIER-TE on BFR1, the only bit position from the BitString that is also set in the BIFT is p2. This will cause BFR1 to send the only copy of the packet to BFR2. Similarly, BFR2 will forward to BFR4 because of p8, BFR4 to BFR5 because of p10, and BFR5 to BFR6 because of p12. p15 finally makes BFR6 receive and decapsulate the packet.
BFR1からのパケットをBFR4を介してBFR6に送信する必要があると仮定します。これには、ビットストリングが必要です（P2、P8、P10、P12、P15）。このパケットがBFR1のBierTTEで検査されると、BITSTRINGからのビットストリングの唯一のビット位置は、BIFTに設定されています。これにより、BFR1はパケットの唯一のコピーをBFR2に送信します。同様に、BFR2は、P8、BFR4からBFR5のためにBFR4に転送されます。P10のため、P12のためにBFR5からBFR6へ。P15は最終的にBFR6にパケットを受信および脱カプセル化します。
To send a copy to BFR6 via BFR4 and also a copy to BFR3, the BitString needs to be (p2,p5,p8,p10,p12,p13,p15). When this packet is examined by BFR2, p5 causes one copy to be sent to BFR3 and p8 one copy to BFR4. When BFR3 receives the packet, p13 will cause it to receive and decapsulate the packet.
BFR4を介してBFR6にコピーを送信し、BFR3へのコピーを送信するには、ビットストリングを必要とする必要があります（P2、P5、P8、P10、P12、P13、P15）。このパケットがBFR2で検査されると、P5は1つのコピーをBFR3に送信し、P8はBFR4に1コピーを送信します。BFR3がパケットを受信すると、P13はパケットを受信して脱カプセル化します。
If instead the BitString was (p2,p6,p8,p10,p12,p13,p15), the packet would be copied by BFR5 towards BFR3 because of p6 instead of being copied by BFR2 to BFR3 because of p5 in the prior case. This demonstrates the ability of the BIER-TE topology, as shown in Figure 1, to make the traffic pass across any possible path and be replicated where desired.
代わりにビットストリングが（P2、P6、P8、P10、P12、P13、P15）の場合、前のケースではP5からBFR2にコピーされる代わりに、P6のためにBFR5によってBFR5にコピーされます。これは、図1に示すように、可能なパスを横切ってトラフィックを通過させ、望ましい場合に複製するBier-TEトポロジの能力を示しています。
BIER-TE has various options for minimizing BP assignments, many of which are based on out-of-band knowledge about the required multicast traffic paths and bandwidth consumption in the network, e.g., from predeployment planning.
BIER-TEには、BPの割り当てを最小限に抑えるためのさまざまなオプションがあります。その多くは、必要なマルチキャストトラフィックパスとネットワーク内の帯域幅の消費に関する帯域外の知識に基づいています。
Figure 2 shows a modified example, in which Rtr2 and Rtr5 are assumed not to support BIER-TE, so traffic has to be unicast encapsulated across them. To explicitly distinguish routed/tunneled forwarding of BIER-TE packets from Layer 2 forwarding (forward_connected()), these adjacencies are called "forward_routed()" adjacencies. Otherwise, there is no difference in their processing over the aforementioned forward_connected() adjacencies.
図2は、RTR2とRTR5がBierTTEをサポートしないと想定される修正された例を示しているため、トラフィックはそれら全体にユニキャストをカプセル化する必要があります。レイヤー2転送（Forward_Connected（））からBier-TEパケットのルーティング/トンネル転送を明示的に区別するために、これらの隣接は「Forward_Routed（）」隣接と呼ばれます。それ以外の場合、前述のForward_Connected（）隣接を介して処理に違いはありません。
In addition, bits are saved in the following example by assuming that BFR1 only needs to be a BFIR -- not a BFER or a transit BFR.
さらに、BFR1はBFIRである必要があると仮定することにより、次の例でBITSが保存されます - BFERまたはTransit BFRではありません。
BIER-TE Topology:
Bierteトポロジ：
Diagram:
図：
p1 p3 p7
....> BFR3 <.... p5
........ ........>
BFR1 (Rtr2) (Rtr5) BFR6
........ ........> p9
....> BFR4 <.... p6
p2 p4 p8
(simplified) BIER-TE Bit Index Forwarding Tables (BIFTs):
（簡素化）Bier-TEビットインデックス転送表（BIFTS）：
BFR1: p1 -> forward_routed() to BFR3
p2 -> forward_routed() to BFR4
BFR3: p3 -> local_decap()
p5 -> forward_routed() to BFR6
BFR4: p4 -> local_decap()
p6 -> forward_routed() to BFR6
BFR6: p7 -> forward_routed() to BFR3
p8 -> forward_routed() to BFR4
p9 -> local_decap()
Figure 2: BIER-TE Basic Overlay Example
図2：BierTE Basic Overlayの例
To send a BIER-TE packet from BFR1 via BFR3 to be received by BFR6, the BitString is (p1,p5,p9). A packet from BFR1 via BFR4 to be received by BFR6 uses the BitString (p2,p6,p9). A packet from BFR1 to be received by BFR3,BFR4 and from BFR3 to be received by BFR6 uses (p1,p2,p3,p4,p5,p9). A packet from BFR1 to be received by BFR3,BFR4 and from BFR4 to be received by BFR6 uses (p1,p2,p3,p4,p6,p9). A packet from BFR1 to be received by BFR4, then from BFR4 to be received by BFR6, and finally from BFR6 to be received by BFR3, uses (p2,p3,p4,p6,p7,p9). A packet from BFR1 to be received by BFR3, then from BFR3 to be received by BFR6, and finally from BFR6 to be received by BFR4, uses (p1,p3,p4,p5,p8,p9).
BFR3を介してBFR1からBiRE-TEパケットを送信してBFR6が受信するために、BitStringは（P1、P5、P9）です。BFR4を介してBFR4を介したBFR1からのパケットは、BITSTRING（P2、P6、P9）を使用します。BFR1、BFR4、およびBFR3からBFR6使用（P1、P2、P3、P4、P5、P9）が受信するBFR1からのパケット。BFR1、BFR4、およびBFR4からBFR6の使用（P1、P2、P3、P4、P6、P9）が受信するBFR1からのパケット。BFR1からBFR4が受信し、BFR4からBFR6が受信し、最後にBFR6がBFR3が受信するパケットを使用します（P2、P3、P4、P6、P7、P9）。BFR1からBFR3が受信し、BFR3からBFR6が受信し、最後にBFR6がBFR4が受信するパケット（P1、P3、P4、P5、P8、P9）を使用します。
The key new component in BIER-TE compared to (non-TE) BIER is the BIER-TE topology as introduced through the two examples in Section 2.2. It is used to control where replication can or should happen and how to minimize the required number of BPs for adjacencies.
（非）ビアと比較したBierTEの主要な新しいコンポーネントは、セクション2.2の2つの例で導入されたBier-TEトポロジです。これは、複製がどこで発生するか、または発生する可能性があるか、隣接するために必要な数のBPを最小化する方法を制御するために使用されます。
The BIER-TE topology consists of the BIFTs of all the BFRs and can also be expressed as a directed graph where the edges are the adjacencies between the BFRs labeled with the BP used for the adjacency. Adjacencies are naturally unidirectional. A BP can be reused across multiple adjacencies as long as this does not lead to undesired duplicates or loops, as explained in Section 5.2.
Bierteトポロジは、すべてのBFRのビフトで構成されており、エッジが隣接に使用されるBPとラベル付けされたBFR間の隣接である指向グラフとして表現することもできます。隣接は自然に一方向です。セクション5.2で説明されているように、これが望ましくない複製またはループにつながらない限り、BPは複数の隣接にわたって再利用できます。
If the BIER-TE topology represents (a subset of) the underlying (Layer 2) topology of the network as shown in the first example, this may be called an "underlay" BIER-TE topology. A topology consisting only of "forward_routed()" adjacencies as shown in the second example may be called an "overlay" BIER-TE topology. A BIER-TE topology with both forward_connected() and forward_routed() adjacencies may be called a "hybrid" BIER-TE topology.
Bier-TEトポロジが、最初の例に示すように、ネットワークの基礎となる（レイヤー2）トポロジを（レイヤー2）トポロジを表している場合、これは「アンダーレイ」ビアテポロジーと呼ばれる場合があります。2番目の例に示されている「Forward_Routed（）」の隣接のみで構成されるトポロジは、「オーバーレイ」ビアテポロジーと呼ばれる場合があります。Forward_Connected（）とForward_Routed（）の両方の隣接を備えたBier-TEトポロジは、「ハイブリッド」Bier-TEトポロジと呼ばれる場合があります。
BIER-TE is designed so that its forwarding plane is a simple extension to the (non-TE) BIER forwarding plane, hence allowing it to be added to BIER deployments where it can be beneficial.
BierTEは、その転送面が（非）ビア転送面の単純な拡張であるように設計されているため、Bier展開に追加できるようにします。
BIER-TE is also intended as an option to expand the BIER architecture into deployments where (non-TE) BIER may not be the best fit, such as statically provisioned networks that need path steering but do not want distributed routing protocols.
BierTTEは、パスステアリングが必要であるが配布されたルーティングプロトコルを必要としない静的プロビジョニングネットワークなど、ビアアーキテクチャを展開に拡張するオプションとしても意図されています。
1. BIER-TE inherits the following aspects from BIER unchanged:
1. ビアテは、変更されていないBierから次の側面を継承します。
1.a The fundamental purpose of per-packet signaled replication and delivery via a BitString.
1.パケットごとの基本的な目的は、ビットストリングを介したレプリケーションと配信の信号と配信の基本的な目的です。
1.b The overall architecture, which consists of three layers: the flow overlay, the BIER(-TE) layer, and the routing underlay.
1.Bフローオーバーレイ、ビア（-TE）レイヤー、およびルーティングアンダーレイの3つのレイヤーで構成される全体的なアーキテクチャ。
1.c The supported encapsulations [RFC8296].
1.Cサポートされているカプセル[RFC8296]。
1.d The semantics of all BIER header elements [RFC8296] used by the BIER-TE forwarding plane, other than the semantic of the BP in the BitString.
1.DビットストリングのBPのセマンティック以外に、ビアテ転送面で使用されるすべてのビアヘッダー要素[RFC8296]のセマンティクス。
1.e The BIER forwarding plane, except for how bits have to be cleared during replication.
1.e bier転送面。ただし、複製中にビットをクリアする必要がある場合を除きます。
2. BIER-TE has the following key changes with respect to BIER:
2. Bier-TEには、Bierに関して次の重要な変更があります。
2.a In BIER, bits in the BitString of a BIER packet header indicate a BFER, and bits in the BIFT indicate the BIER control plane's calculated next hop towards that BFER. In BIER-TE, a bit in the BitString of a BIER packet header indicates an adjacency in the BIER-TE topology, and only the BFR that is the upstream of that adjacency has its BP populated with the adjacency in its BIFT.
2. bierで、ビアパケットヘッダーのビットストリングのビットはbferを示し、ビフトのビットは、そのbferに向けて計算された次のホップを計算したビア制御プレーンを示します。BierTeでは、Bier-Packet Headerのビットストリングで少しでBierteトポロジの隣接性が示されており、その隣接の上流であるBFRのみがBPがBiftの隣接に浸透しています。
2.b In BIER, the implied reference options for the core part of the BIER layer control plane are the BIER extensions for distributed routing protocols. These include IS-IS and OSPF extensions for BIER, as specified in [RFC8401] and [RFC8444], respectively.
2.B Bierでは、Bier層制御プレーンのコア部分の暗黙の参照オプションは、分散ルーティングプロトコルのビア拡張機能です。これらには、[RFC8401]と[RFC8444]でそれぞれ指定されているIS-ISおよびOSPF拡張機能が含まれます。
2.c The reference option for the core part of the BIER-TE control plane is the BIER-TE controller. Nevertheless, both the BIER and BIER-TE BIFTs' forwarding plane state could equally be populated by any mechanism.
2.Cビアテ制御プレーンのコア部分の参照オプションは、Bier-TEコントローラーです。それにもかかわらず、ビアとビアテの両方のバイフトのフォワーディングプレーン状態は、あらゆるメカニズムによって等しく入力される可能性があります。
2.d Assuming the reference options for the control plane, BIER-TE replaces in-network autonomous path calculations with explicit paths calculated by the BIER-TE controller.
2.コントロールプレーンの参照オプションを仮定すると、BierTTEは、ネットワーク内の自律パス計算をBier-TEコントローラーによって計算された明示的なパスに置き換えます。
3. The following elements/functions described in the BIER architecture are not required by the BIER-TE architecture:
3. Bierアーキテクチャで説明されている次の要素/機能は、Bier-Teアーキテクチャでは必要ありません。
3.a "Bit Index Routing Tables" (BIRTs) are not required on BFRs for BIER-TE when using a BIER-TE controller, because the controller can directly populate the BIFTs. In BIER, BIRTs are populated by the distributed routing protocol support for BIER, allowing BFRs to populate their BIFTs locally from their BIRTs. Other BIER-TE control plane or management plane options may introduce requirements for BIRTs for BIER-TE BFRs.
3.A「ビットインデックスルーティングテーブル」（BIRTS）は、Bier-TEコントローラーを使用する場合、BIRE-TEのBFRでは必要ありません。Bierでは、BIRTSはBierの分散ルーティングプロトコルサポートによって入力されており、BFRがBIRTSから局所的にビフトを入力できるようにします。他のビアテ制御プレーンまたは管理プレーンのオプションでは、BIRE-TE BFRのBIRTSの要件を導入する場合があります。
3.b The BIER-TE layer forwarding plane does not require BFRs to have a unique BP; see Section 5.1.3. Therefore, BFRs may not have a unique BFR-id; see Section 5.3.3.
3.bビアテ層転送面では、BFRに一意のBPを持たせる必要はありません。セクション5.1.3を参照してください。したがって、BFRSには一意のBFR-IDがない場合があります。セクション5.3.3を参照してください。
3.c Identification of BFRs by the BIER-TE control plane is outside the scope of this specification. Whereas the BIER control plane uses BFR-ids in its BFR-to-BFR signaling, a BIER-TE controller may choose any form of identification deemed appropriate.
3.C Bier-TEコントロールプレーンによるBFRの識別は、この仕様の範囲外です。BIERコントロールプレーンは、BFR-to-BFRシグナル伝達でBFR-IDを使用しますが、Bier-TEコントローラーは、適切と見なされるあらゆる形式の識別を選択できます。
3.d BIER-TE forwarding does not require the BFIR-id field of the BIER packet header.
3.D Bier-TE転送では、BierパケットヘッダーのBFIR-IDフィールドを必要としません。
4. Co-existence of BIER and BIER-TE in the same network requires the following:
4. 同じネットワークでのBierとBierTEの共存には、次のものが必要です。
4.a The BIER/BIER-TE packet header needs to allow the addressing of both BIER and BIER-TE BIFTs. Depending on the encapsulation option, the same SD may or may not be reusable across BIER and BIER-TE. See Section 4.3. In either case, a packet is always forwarded only end to end via BIER or via BIER-TE ("ships in the night" forwarding).
4.Bier/Bier-TEパケットヘッダーは、ビアとビアテの両方のバイフトのアドレス指定を許可する必要があります。カプセル化オプションに応じて、同じSDがBierとBierTEを越えて再利用可能である場合とできない場合があります。セクション4.3を参照してください。どちらの場合でも、パケットは常にBierまたはBier-Te（「夜間の船」の転送）を介して端から端までのみ転送されます。
4.b BIER-TE deployments will have to assign BFR-ids to BFRs and insert them into the BFIR-id field of BIER packet headers, as does BIER, whenever the deployment uses (unchanged) components developed for BIER that use BFR-ids, such as multicast flow overlays or BIER layer control plane elements. See also Section 5.3.3.
4.B Bier-TE展開は、BFR-IDをBFRSに割り当て、BIERパケットヘッダーのBFIR-IDフィールドに挿入する必要があります。、マルチキャストフローオーバーレイやビア層制御プレーン要素など。セクション5.3.3も参照してください。
BIER-TE forwarding rules, especially BitString parsing, are designed to be as close as possible to those of BIER, with the expectation that this eases the programming of BIER-TE forwarding code and/or BIER-TE forwarding hardware on platforms supporting BIER. The pseudocode in Section 4.4 shows how existing (non-TE) BIER/BIFT forwarding can be modified to support the required BIER-TE forwarding functionality (Section 4.5), by using the BIER BIFT's "Forwarding Bit Mask" (F-BM): only the clearing of bits to avoid sending duplicate packets to a BFR's neighbor is skipped in BIER-TE forwarding, because it is not necessary and could not be done when using a BIER F-BM.
Bier-TEの転送規則、特にビットストリングの解析は、Bierのプログラミングを容易にすることを期待して、Bierのプログラミングを容易にすることを期待して、Bierをサポートするプラットフォーム上のプラットフォーム上のビアテ転送ハードウェアを容易にすることを期待しています。セクション4.4の擬似コードは、Bier Biftの「転送ビットマスク」（F-BM）を使用して、既存（非）ビア/バイフト転送をどのように変更できるかを示しています（セクション4.5）。BFRの隣人に重複したパケットを送信しないようにビットのクリアのみがビアテの転送でスキップされます。これは、ビアF-BMを使用するときに必要ではなく、実行できないためです。
Whether to use BIER or BIER-TE forwarding is simply a choice of the mode of the BIFT indicated by the packet (BIER or BIER-TE BIFT). This is determined by the BFR configuration for the encapsulation; see Section 4.3.
BierまたはBierteの転送を使用するかどうかは、パケット（BierまたはBierte Bift）で示されるBIFTのモードの選択です。これは、カプセル化のBFR構成によって決定されます。セクション4.3を参照してください。
BIER-TE can be thought of as being composed of the same three layers as BIER: the "multicast flow overlay", the "BIER layer", and the "routing underlay". Figure 3 also shows how the BIER layer is composed of the "BIER-TE forwarding plane" and the "BIER-TE control plane" as represented by the "BIER-TE controller".
ビアテは、「マルチキャストフローオーバーレイ」、「ビアレイヤー」、「ルーティングアンダーレイ」という3つのレイヤーで構成されていると考えることができます。図3は、Bier層が「ビアテ転送面」と「Bier-TEコントローラー」で表される「ビアテコンロールプレーン」で構成されている方法も示しています。
<------BGP/PIM----->
|<-IGMP/PIM-> multicast flow <-PIM/IGMP->|
overlay
BIER-TE [BIER-TE Controller] <=> [BIER-TE Topology]
control ^ ^ ^
plane / | \ BIER-TE control protocol
| | | (e.g., YANG/NETCONF/RESTCONF
| | | PCEP/...)
v v v
Src -> Rtr1 -> BFIR-----BFR-----BFER -> Rtr2 -> Rcvr
|<----------------->|
BIER-TE forwarding plane
|<- BIER-TE domain->|
| <-bier-te domain-> |
|<--------------------->|
Routing underlay
Figure 3: BIER-TE Architecture
図3：ビアテアーキテクチャ
The multicast flow overlay has the same role as that described for BIER in [RFC8279], Section 4.3. See also Section 3.2.1.2.
マルチキャストフローオーバーレイは、[RFC8279]、セクション4.3のBierについて説明した役割と同じ役割を持っています。セクション3.2.1.2も参照してください。
When a BIER-TE controller is used, it might also be preferable that multicast flow overlay signaling be performed through a central point of control. For BGP-based overlay flow services such as "Multicast VPN Using Bit Index Explicit Replication (BIER)" [RFC8556], this can be achieved by making the BIER-TE controller operate as a BGP Route Reflector [RFC4456] and combining it with signaling through BGP or a different protocol for the BIER-TE controller's calculated BitStrings. See Sections 3.2.1.2 and 5.3.4.
BierTEコントローラーを使用する場合、マルチキャストフローオーバーレイシグナル伝達を中心的な制御点を介して実行することも望ましい場合があります。「ビットインデックス明示的複製（BIER）を使用したマルチキャストVPN」[RFC8556]などのBGPベースのオーバーレイフローサービスの場合、これはBier-TEコントローラーをBGPルートリフレクター[RFC4456]として動作させ、それをシグナル伝達と組み合わせることで実現できます。BIER-TEコントローラーの計算ビットストリング用のBGPまたは異なるプロトコルを介して。セクション3.2.1.2および5.3.4を参照してください。
In the (non-TE) BIER architecture [RFC8279], the BIER layer is summarized in Section 4.2 of [RFC8279]. This summary includes both the functions of the BIER-layer control plane and forwarding plane, without using those terms. Example standardized options for the BIER control plane include IS-IS and OSPF extensions for BIER, as specified in [RFC8401] and [RFC8444], respectively.
（非）ビアアーキテクチャ[RFC8279]では、ビア層は[RFC8279]のセクション4.2に要約されています。この要約には、これらの用語を使用せずに、ビア層制御プレーンの機能と転送面の両方が含まれます。ビア制御プレーンの標準化されたオプションの例には、それぞれ[RFC8401]と[RFC8444]で指定されているように、BierのIS-ISおよびOSPF拡張機能が含まれます。
For BIER-TE, the control plane includes, at a minimum, the following functionality.
BierTEの場合、コントロールプレーンには、少なくとも次の機能が含まれます。
1. BIER-TE topology control: During initial provisioning of the network and/or during modifications of its topology and/or services, the protocols and/or procedures to establish BIER-TE BIFTs:
1. Bierteトポロジコントロール：ネットワークの初期プロビジョニング中および/またはトポロジおよび/またはサービスの変更中に、ビアテビフトを確立するためのプロトコルおよび/または手順：
1.a Determine the desired BIER-TE topology for BIER-TE subdomains: the adjacencies that are assigned to BPs. Topology discovery is discussed in Section 3.2.1.1, and the various aspects of the BIER-TE controller's determinations regarding the topology are discussed throughout Section 5.
1.aビアテサブドメインの目的のビアテポロジーを決定します。トポロジの発見については、セクション3.2.1.1で説明し、トポロジに関するBier-TEコントローラーの決定のさまざまな側面について説明します。
1.b Determine the per-BFR BIFT from the BIER-TE topology. This is achieved by simply extracting the adjacencies of the BFR from the BIER-TE topology and populating the BFR's BIFT with them.
1.b Bier-TEトポロジからBR BFR BIFTを決定します。これは、BIRTEトポロジーからBFRの隣接を抽出し、BFRのビフトをそれらに住むだけで達成されます。
1.c Optionally assign BFR-ids to BFIRs for later insertion into BIER headers on BFIRs as BFIR-ids. Alternatively, BFIR-ids in BIER packet headers may be managed solely by the flow overlay layer and/or be unused. This is discussed in Section 5.3.3.
1.Cオプションで、BFIRSとしてBFIRSのビアヘッダーに後で挿入するために、BFR-IDをBFIRSに割り当てます。あるいは、BierパケットヘッダーのBFIR-IDは、フローオーバーレイレイヤーのみによって管理されるか、未使用である場合があります。これについては、セクション5.3.3で説明します。
1.d Install/update the BIFTs into the BFRs and, optionally, BFR-ids into BFIRs. This is discussed in Section 3.2.1.1.
1.D BFRSにBIFTをインストール/更新し、オプションではBFR-IDをBFIRSにインストールします。これについては、セクション3.2.1.1で説明します。
2. BIER-TE tree control: During network operations, protocols and/or procedures to support creation/change/removal of overlay flows on BFIRs:
2. Bier-TEツリー制御：ネットワーク操作中に、BFIRSでのオーバーレイフローの作成/変更/削除をサポートするプロトコルおよび/または手順：
2.a Process the BIER-TE requirements for the multicast overlay flow: BFIRs and BFERs of the flow as well as policies for the path selection of the flow. This is discussed in Section 3.5.
2.プロセスマルチキャストオーバーレイフローのビアテの要件：フローのBFIRとBFERS、およびフローのパス選択のポリシー。これについては、セクション3.5で説明します。
2.b Determine the BitStrings and, optionally, entropy. BitStrings are discussed in Sections 3.2.1.2, 3.5, and 5.3.4. Entropy is discussed in Section 4.2.3.
2.bビットストリングと、オプションでエントロピーを決定します。ビットストリングについては、セクション3.2.1.2、3.5、および5.3.4で説明します。エントロピーについては、セクション4.2.3で説明します。
2.c Install state on the BFIR to impose the desired BIER packet header(s) for packets of the overlay flow. Different aspects of this point, as well as the next point, are discussed throughout Section 3.2.1 and in Section 4.3. The main component responsible for these two points is the multicast flow overlay (Section 3.1), which is architecturally inherited from BIER.
2.C BFIRに状態をインストールして、オーバーレイフローのパケットに目的のビアパケットヘッダーを課します。次のポイントと同様に、この点のさまざまな側面については、セクション3.2.1およびセクション4.3で説明します。これらの2つのポイントを担当する主なコンポーネントは、マルチキャストフローオーバーレイ（セクション3.1）です。これは、ビアからアーキテクチャに継承されています。
2.d Install the necessary state on the BFERs to decapsulate the BIER packet header and properly dispatch its payload.
2.D BFERに必要な状態を取り付けて、Bierパケットヘッダーを脱カプセル化し、ペイロードを適切に発送します。
This architecture describes the BIER-TE control plane, as shown in Figure 3, as consisting of:
このアーキテクチャは、図3に示すように、次のようにビアテの制御プレーンを説明しています。
* A BIER-TE controller.
* Bierteコントローラー。
* BFR data models and protocols to communicate between the controller and BFRs in support of BIER-TE topology control (see the list under "BIER-TE topology control"), such as YANG/NETCONF/ RESTCONF [RFC7950] [RFC6241] [RFC8040].
* Yang/ NetConf/ RestConf [RFC7950] [RFC6241] [RFC8040]など、Bier-TEトポロジコントロールをサポートしてコントローラーとBFRS間で通信するBFRデータモデルとプロトコル（Bier-TEトポロジコントロールをサポートする）。
* BFR data models and protocols to communicate between the controller and BFIRs in support of BIER-TE tree control (see Section 3.2, point 2.), such as BIER-TE extensions for [RFC5440].
* [RFC5440]のBier-TE拡張機能など、ビアテツリー制御をサポートするために、コントローラーとBFIRS間で通信するBFRデータモデルとプロトコル。
The single, centralized BIER-TE controller is used in this document as the reference option for the BIER-TE control plane, but other options are equally feasible. The BIER-TE control plane could equally be implemented without automated configuration/protocols, by an operator via a CLI on the BFRs. In that case, operator-configured local policy on the BFIR would have to determine how to set the appropriate BIER header fields. The BIER-TE control plane could also be decentralized and/or distributed, but this document does not consider any additional protocols and/or procedures that would then be necessary to coordinate its (distributed/decentralized) entities to achieve the above-described functionality.
このドキュメントでは、単一の集中化されたBierTTEコントローラーがBier-TEコントロールプレーンの参照オプションとして使用されていますが、他のオプションも同様に実現可能です。BFRS上のCLIを介してオペレーターによって、自動化された構成/プロトコルなしでは、Bier-TEコントロールプレーンを等しく実装できます。その場合、BFIRに関するオペレーターが構成したローカルポリシーは、適切なビアヘッダーフィールドを設定する方法を決定する必要があります。BierTEコントロールプレーンも分散型および/または分布することもできますが、このドキュメントでは、上記の機能を達成するために（分散/分散化された）エンティティを調整するために必要な追加のプロトコルおよび/または手順を考慮しません。
The first item listed for BIER-TE topology control (Section 3.2, point 1.a.) includes network topology discovery and BIER-TE topology creation. The latter describes the process by which a controller determines which routers are to be configured as BFRs and the adjacencies between them.
BierTTEトポロジコントロール（セクション3.2、ポイント1.A.）にリストされている最初の項目には、ネットワークトポロジの発見とBierTEトポロジの作成が含まれます。後者は、コントローラーがどのルーターをBFRとして構成するか、およびそれらの間の隣接を決定するプロセスを説明しています。
In statically managed networks, e.g., industrial environments, both discovery and creation can be a manual/offline process.
静的に管理されたネットワーク、たとえば、産業環境では、発見と作成の両方がマニュアル/オフラインプロセスになる可能性があります。
In other networks, topology discovery may rely on such protocols as those that include extending an IGP based on a link-state protocol into the BIER-TE controller itself, e.g., BGP-LS [RFC7752] or YANG topology [RFC8345], as well as methods specific to BIER-TE -- for example, via [BIER-TE-YANG]. These options are non-exhaustive.
他のネットワークでは、トポロジの発見は、Bier-TEコントローラー自体にリンク状態プロトコルに基づいてIGPを拡張することを含むプロトコルに依存する場合があります。BierTeに固有の方法として - たとえば、[Bier-Te-Yang]を介して。これらのオプションは網羅的ではありません。
Dynamic creation of the BIER-TE topology can be as easy as mapping the network topology 1:1 to the BIER-TE topology by assigning a BP for every network subnet adjacency. In larger networks, it likely involves more complex policy and optimization decisions, including how to minimize the number of BPs required and how to assign BPs across different BitStrings to minimize the number of duplicate packets across links when delivering an overlay flow to BFERs using different SIs:BitStrings. These topics are discussed in Section 5.
BierTEトポロジの動的作成は、すべてのネットワークサブネット隣接にBPを割り当てることにより、ネットワークトポロジ1：1をBierTTEトポロジにマッピングするのと同じくらい簡単です。大規模なネットワークでは、必要なBPの数を最小限に抑える方法や、異なるSISを使用してオーバーレイフローをBFERに配信する際のリンク全体の重複パケットの数を最小限に抑える方法など、より複雑なポリシーと最適化の決定が含まれる可能性があります。：ビットストリング。これらのトピックについては、セクション5で説明します。
When the BIER-TE topology has been determined, the BIER-TE controller pushes the BPs/adjacencies to the BIFT of the BFRs. On each BFR, only those SIs:BPs that are adjacencies to other BFRs in the BIER-TE topology are populated.
Bier-TEトポロジが決定されると、Bier-TEコントローラーはBPRS/隣接をBFRSのビフトに押し上げます。各BFRで、Bier-TEトポロジの他のBFRに隣接するsis：BPのみが存在します。
Communications between the BIER-TE controller and BFRs for both BIER-TE topology control and BIER-TE tree control are ideally via standardized protocols and data models such as NETCONF/RESTCONF/YANG/ PCEP. A vendor-specific CLI on the BFRs is also an option (as in many other "Software-Defined Network" (SDN) solutions lacking definitions of standardized data models).
Bier-TEトポロジコントロールとBierTTEツリー制御の両方のBier-TEコントローラーとBFRS間の通信は、標準化されたプロトコルとNetConf/RestConf/Yang/PCEPなどのデータモデルを介して理想的です。BFRS上のベンダー固有のCLIもオプションです（他の多くの「ソフトウェア定義ネットワーク」（SDN）ソリューションのように、標準化されたデータモデルの定義がありません）。
In BIER, the same set of BFERs in a single subdomain is always encoded as the same BitString. In BIER-TE, the BitString used to reach the same set of BFERs in the same subdomain can be different for different overlay flows because the BitString encodes the paths towards the BFERs, so the BitStrings from different BFIRs to the same set of BFERs will often be different. Likewise, the BitString from the same BFIR to the same set of BFERs can be different for different overlay flows if different policies should be applied to those overlay flows, such as shortest path trees, Steiner trees (minimum cost trees), diverse path trees for redundancy, and so on.
Bierでは、単一のサブドメイン内の同じセットのBFERが常に同じビットストリングとしてエンコードされます。ビアテでは、同じサブドメインの同じbferのセットに到達するために使用されるビットストリングは、ビットストリングがbferに向かうパスをエンコードするため、異なるオーバーレイフローで異なる場合があります。異なる。同様に、同じBFIRから同じBFIRのセットへのビットストリングは、最短パスツリー、シュタイナーツリー（最小コストツリー）、Diverse Path Treesなどのオーバーレイフローに異なるポリシーを適用する必要がある場合、異なるオーバーレイフローに対して異なる場合があります。冗長性など。
See also [BIER-MCAST-OVERLAY] for an application leveraging BIER-TE engineered trees.
Bier-TEエンジニアリングツリーを活用するアプリケーションについては、[Bier-Mcast-Overlay]も参照してください。
If the network topology changes (not failure based) so that adjacencies that are assigned to bit positions are no longer needed, the BIER-TE controller can reuse those bit positions for new adjacencies. First, these bit positions need to be removed from any BFIR flow state and BFR BIFT state. Then, they can be repopulated, first into the BIFT and then into the BFIR.
ネットワークトポロジがビット位置に割り当てられている隣接が不要になった場合（障害ベースではない）場合、Bier-TEコントローラーは新しい隣接のビット位置を再利用できます。まず、これらのビット位置は、BFIRフロー状態およびBFRバフト状態から削除する必要があります。次に、最初にビフトに、次にBFIRに再現することができます。
When links or nodes fail or recover in the topology, BIER-TE could quickly respond with "Fast Reroute" (FRR) procedures such as those described in [BIER-TE-PROTECTION], the details of which are out of scope for this document. It can also more slowly react by recalculating the BitStrings of affected multicast flows. This reaction is slower than the FRR procedure because the BIER-TE controller needs to receive link/node up/down indications, recalculate the desired BitStrings, and push them down into the BFIRs. With FRR, this is all performed locally on a BFR receiving the adjacency up/down notification.
リンクまたはノードがトポロジで失敗または回復すると、BierTEは[Bier-TeTotection]で説明されているような「Fast Reroute」（FRR）手順で迅速に応答できます。その詳細は、このドキュメントの範囲外です。また、影響を受けるマルチキャストフローのビットストリングを再計算することにより、よりゆっくりと反応する可能性があります。Bier-TEコントローラーはリンク/ノードアップ/ダウン表示を受信し、目的のビットストリングを再計算し、それらをBFIRSに押し込む必要があるため、この反応はFRR手順よりも遅いです。FRRを使用すると、これはすべてBFRでローカルに実行され、隣接するアップ/ダウン通知を受け取ります。
The BIER-TE forwarding plane consists of the following components:
ビアテ転送面は、次のコンポーネントで構成されています。
1. On a BFIR, imposition of the BIER header for packets from overlay flows. This is driven by state established by the BIER-TE control plane, the multicast flow overlay as explained in Section 3.1, or a combination of both.
1. BFIRでは、オーバーレイフローからのパケットのビアヘッダーの賦課。これは、セクション3.1で説明されているように、Bier-TEコントロールプレーン、マルチキャストフローオーバーレイ、または両方の組み合わせによって確立された状態によって駆動されます。
2. On BFRs (including BFIRs and BFERs), forwarding/replication of BIER packets according to their SD, SI, "BitStringLength" (BSL), BitString, and, optionally, entropy fields as explained in Section 4. Processing of other BIER header fields, such as the "Differentiated Services Code Point" (DSCP) field, is outside the scope of this document.
2. BFR（BFIRSおよびBFERSを含む）では、SD、SI、「BitStringLength」（BSL）、BitString、およびオプションで、セクション4で説明されているエントロピーフィールドに従って、Bierパケットの転送/複製「差別化されたサービスコードポイント」（DSCP）フィールドなどは、このドキュメントの範囲外です。
3. On BFERs, removal of the BIER header and dispatching of the payload according to state created by the BIER-TE control plane and/or overlay layer.
3. Bferでは、ビアヘッダーの除去と、Bier-TEコントロールプレーンおよび/またはオーバーレイ層によって作成された状態に応じたペイロードのディスパッチ。
When the BIER-TE forwarding plane receives a packet, it simply looks up the bit positions that are set in the BitString of the packet in the BIFT that was populated by the BIER-TE controller. For every BP that is set in the BitString and has one or more adjacencies in the BIFT, a copy is made according to the types of adjacencies for that BP in the BIFT. Before sending any copies, the BFR clears all BPs in the BitString of the packet for which the BFR has one or more adjacencies in the BIFT. Clearing these bits prevents packets from looping when a BitString erroneously includes a forwarding loop. When a forward_connected() adjacency has the "DoNotClear" (DNC) flag set, this BP is reset for the packet copied to that adjacency. See Section 4.2.1.
Bier-TE転送面がパケットを受信すると、ビアテコンソーが入力されたビフトのパケットのビットストリングに設定されたビット位置を調べるだけです。BitStringに設定され、Biftに1つ以上の隣接があるすべてのBPについて、コピーはBIFTのBPの隣接の種類に従って行われます。コピーを送信する前に、BFRは、BFRがBIFTに1つ以上の隣接を持っているパケットのビットストリングですべてのBPをクリアします。これらのビットをクリアすると、ビットストリングに誤って転送ループが含まれている場合、パケットがループを防ぎます。Forward_Connected（）隣接が「DonotClear」（DNC）フラグセットがある場合、このBPはその隣接にコピーされたパケットにリセットされます。セクション4.2.1を参照してください。
For forward_connected() adjacencies, BIER-TE sends BIER packets to directly connected BIER-TE neighbors as L2 (unicast) BIER packets without requiring a routing underlay. For forward_routed() adjacencies, BIER-TE forwarding encapsulates a copy of the BIER packet so that it can be delivered by the forwarding plane of the routing underlay to the routable destination address indicated in the adjacency. See Section 4.2.2 for details on forward_routed() adjacencies.
Forward_Connected（）の隣接の場合、BierTTEは、ルーティングアンダーレイを必要とせずに、Bier-TE NeighborsにBier-TE NeigborsにL2（Unicast）Bierパケットとして直接接続されたBier-TE Neighborsに送信します。Forward_Routed（）隣接の場合、Bier-TE転送はBierパケットのコピーをカプセル化して、隣接するルーティングアンダーレイの転送面によって配信できるようにします。Forward_Routed（）隣接の詳細については、セクション4.2.2を参照してください。
BIER relies on the routing underlay to calculate paths towards BFERs and derive next-hop BFR adjacencies for those paths. These two steps commonly rely on BIER-specific extensions to the routing protocols of the routing underlay but may also be established by a controller. In BIER-TE, the next hops for a packet are determined by the BitString through the BIER-TE controller-established adjacencies on the BFR for the BPs of the BitString. There is thus no need for BFR-specific routing underlay extensions to forward BIER packets with BIER-TE semantics.
Bierは、ルーティングアンダーレイに依存して、BFERSへのパスを計算し、それらのパスの次のHOP BFR隣接を導き出します。これらの2つのステップは、一般に、ルーティングアンダーレイのルーティングプロトコルへのビア固有の拡張に依存していますが、コントローラーによっても確立される場合があります。BierTEでは、パケットの次のホップは、ビットストリングのBPSのBFRのBIRTEコントローラーが確立した隣接を介してビットストリングによって決定されます。したがって、BIR-TEセマンティクスを使用してBierパケットを転送するために、BFR固有のルーティングアンダーレイエクステンションは必要ありません。
Encapsulation parameters can be provisioned by the BIER-TE controller into the forward_connected() or forward_routed() adjacencies directly without relying on a routing underlay.
カプセル化パラメーターは、ルーティングアンダーレイに依存することなく、Bier-TEコントローラーによってForward_Connected（）またはForward_Routed（）隣接（）に直接プロビジョニングできます。
If the BFR intends to support FRR for BIER-TE, then the BIER-TE forwarding plane needs to receive fast adjacency up/down notifications: link up/down or neighbor up/down, e.g., from "Bidirectional Forwarding Detection" (BFD). Providing these notifications is considered to be part of the routing underlay in this document.
BFRがBierTTEのFRRをサポートする予定の場合、Bier-TE転送面は、「双方向転送検出」（BFD）から、アップ/ダウン/ダウンのリンクアップ/ダウン/ダウン通知を迅速に隣接する必要があります。。これらの通知を提供することは、このドキュメントのルーティングアンダーレイの一部であると見なされます。
Traffic Engineering [TE-OVERVIEW] provides performance optimization of operational IP networks while utilizing network resources economically and reliably. The key elements needed to effect Traffic Engineering are policy, path steering, and resource management. These elements require support at the control/controller level and within the forwarding plane.
トラフィックエンジニアリング[TE-Overview]は、ネットワークリソースを経済的かつ確実に利用しながら、運用上のIPネットワークのパフォーマンス最適化を提供します。トラフィックエンジニアリングに影響を与えるために必要な重要な要素は、ポリシー、パスステアリング、およびリソース管理です。これらの要素は、コントロール/コントローラーレベルおよび転送面内でのサポートが必要です。
Policy decisions are made within the BIER-TE control plane, i.e., within BIER-TE controllers. Controllers use policy when composing BitStrings and BFR BIFT state. The mapping of user/IP traffic to specific BitStrings / BIER-TE flows is made based on policy. The specific details of BIER-TE policies and how a controller uses them are out of scope for this document.
政策決定は、Bier-TEコントロールプレーン内、つまりBier-TEコントローラー内で行われます。コントローラーは、ビットストリングとBFRバイフト状態を構成するときにポリシーを使用します。特定のビットストリング /ビアテフローへのユーザー / IPトラフィックのマッピングは、ポリシーに基づいて行われます。BierTEポリシーの具体的な詳細と、コントローラーがそれらを使用する方法は、このドキュメントの範囲外です。
Path steering is supported via the definition of a BitString. BitStrings used in BIER-TE are composed based on policy and resource management considerations. For example, when composing BIER-TE BitStrings, a controller must take into account the resources available at each BFR and for each BP when it is providing congestion-loss-free services such as Rate-Controlled Service Disciplines [RCSD94]. Resource availability could be provided, for example, via routing protocol information but may also be obtained via a BIER-TE control protocol such as NETCONF or any other protocol commonly used by a controller to understand the resources of the network on which it operates. The resource usage of the BIER-TE traffic admitted by the BIER-TE controller can be solely tracked on the BIER-TE controller based on local accounting as long as no forward_routed() adjacencies are used (see Section 4.2.2 for the definition of forward_routed() adjacencies). When forward_routed() adjacencies are used, the paths selected by the underlying routing protocol need to be tracked as well.
パスステアリングは、ビットストリングの定義を介してサポートされています。 BierTEで使用されるビットストリングは、ポリシーとリソース管理の考慮事項に基づいて構成されています。たとえば、BierTTEビットストリングを作成する場合、コントローラーは、各BFRで利用可能なリソースを、レート制御サービス分野[RCSD94]などの混雑損失のないサービスを提供する場合に、各BPで利用可能なリソースを考慮する必要があります。たとえば、ルーティングプロトコル情報を介してリソースの可用性を提供できますが、NetConfなどのBier-TEコントロールプロトコルまたはコントローラーが一般的に使用するその他のプロトコルなどのBier-TEコントロールプロトコルを介して取得することもできます。 BierTTEコントローラーが認めているBier-TEトラフィックのリソース使用は、wordword_routed（）隣接が使用されていない限り、ローカルアカウンティングに基づいてBierteコントローラーでのみ追跡できます（セクション4.2.2を参照してください。 Forward_Routed（）隣接）。 Forward_Routed（）隣接が使用される場合、基礎となるルーティングプロトコルによって選択されたパスも追跡する必要があります。
Resource management has implications for the forwarding plane beyond the BIER-TE-defined steering of packets; this includes allocation of buffers to guarantee the worst-case requirements for admitted RCSD traffic and potentially policing and/or rate-shaping mechanisms, typically done via various forms of queuing. This level of resource control, while optional, is important in networks that wish to support congestion management policies to control or regulate the offered traffic to deliver different levels of service and alleviate congestion problems, or those networks that wish to control latencies experienced by specific traffic flows.
リソース管理は、パケットのビアテで定義されたステアリングを超えた転送面に影響を与えます。これには、一般的にさまざまな形式のキューイングを介して行われる、認められたRCSDトラフィックおよび潜在的にポリシングおよび/または速度形成メカニズムの最悪の要件を保証するバッファの割り当てが含まれます。このレベルのリソース制御は、オプションではありますが、さまざまなレベルのサービスを提供し、渋滞の問題を軽減するために提供されるトラフィックを制御または規制するための混雑管理ポリシーをサポートしたいネットワークでは重要です。流れ。
The BIER-TE BIFT is equivalent to the (non-TE) BIER BIFT. It exists on every BFR running BIER-TE. For every BIER "subdomain" (SD) in use for BIER-TE, the BIFT is constructed per the example shown in Figure 4. The BIFT in the figure assumes a BSL of 8 "bit positions" (BPs) in the packets BitString. As in [RFC8279], this BSL is purely used as an example and is not a BSL supported by BIER/BIER-TE (minimum BSL is 64).
Bierte Biftは、（非）ビアビフトに相当します。それはすべてのBFRランニングビアテに存在します。Bier-TEに使用されているすべてのBier「サブドメイン」（SD）について、図4に示す例に従ってBIFTは構築されます。図のビフトは、ビットストリングのパケットのBSLを8 "ビット位置"（BPS）と想定しています。[RFC8279]のように、このBSLは純粋に例として純粋に使用されており、Bier/BierTEでサポートされているBSLではありません（最小BSLは64）。
A BIER-TE BIFT is compared to a BIER BIFT as shown in [RFC8279] as follows.
次のように、[RFC8279]に示すように、ビアテビフトと比較されます。
In both BIER and BIER-TE, BIFT rows/entries are indexed in their respective BIER pseudocode ([RFC8279], Section 6.5) and BIER-TE pseudocode (Section 4.4) by the BIFT-index derived from the packet's SI, BSL, and the one bit position of the packets BitString (BP) addressing the BIFT row: BIFT-index = SI * BSL + BP - 1. BPs within a BitString are numbered from 1 to BSL -- hence, the - 1 offset when converting to a BIFT-index. This document also uses the notion "SI:BP" to indicate BIFT rows. [RFC8279] uses the equivalent notion "SI:BitString", where the BitString is filled with only the BPs for the BIFT row.
BierとBierTEの両方で、Bift行/エントリは、パケットのSi、BSL、およびBift-Indexによってそれぞれのビア偽コード（[RFC8279]、セクション6.5）およびビアテの擬似コード（セクション4.4）でインデックス化されています。Bift -index = si * bsl bp -1に対処するパケットの1つのポジションBitString（BP）は、ビットストリング内のBPSに1からBSLに番号が付けられています。-索引。このドキュメントでは、概念「SI：BP」も使用して、BIFT行を示しています。[RFC8279]は、同等の概念「SI：BitString」を使用します。ここでは、ビットストリングにはBIFT列のBPSのみが満たされています。
In BIER, each BIFT-index addresses one BFER by its BFR-id = BIFT-index + 1 and is populated on each BFR with the next-hop "BFR Neighbor" (BFR-NBR) towards that BFER.
Bierでは、各Bift-IndexはBFR-ID = bift-Index 1に1つのBferにアドレス指定され、各BFRに次のホップ「BFR隣」（BFR-NBR）がそのBFerに向かって入力されます。
In BIER-TE, each BIFT-index and, therefore, SI:BP indicates one or, in the case of reuse of SI:BP, more than one adjacency between BFRs in the topology. The SI:BP is populated with the adjacency on the upstream BFR of the adjacency. The BIFT entries are empty on all other BFRs.
BierTEでは、各Bift-Index、したがってSi：BPは、Si：BPの再利用の場合、またはトポロジーのBFR間の複数の隣接性を示します。SI：BPには、隣接する上流のBFRの隣接性が埋め込まれています。BIFTエントリは、他のすべてのBFRで空です。
In BIER, each BIFT row also requires a "Forwarding Bit Mask" (F-BM) entry for BIER forwarding rules. In BIER-TE forwarding, an F-BM is not required but can be used when implementing BIER-TE on forwarding hardware, derived from BIER forwarding, that must use an F-BM. This is discussed in the first variation of BIER-TE forwarding pseudocode shown in Section 4.4.
Bierでは、各バフト行には、ビア転送ルールの「転送ビットマスク」（F-BM）エントリも必要です。BierTE転送では、F-BMは必要ありませんが、FIREの転送から派生したフォワードハードウェアにBierTTEを実装するときに使用できます。これは、F-BMを使用する必要があります。これは、セクション4.4に示されているビアテ転送擬似コードの最初のバリエーションで説明されています。
-------------------------------------------------------------------
| BIFT-index | | Adjacencies: |
| (SI:BP) |(F-BM)| <empty> or one or more per entry |
===================================================================
| BIFT indices for Packets with SI=0 |
-------------------------------------------------------------------
| 0 (0:1) | ... | forward_connected(interface,neighbor{,DNC}) |
-------------------------------------------------------------------
| 1 (0:2) | ... | forward_connected(interface,neighbor{,DNC}) |
| | ... | forward_connected(interface,neighbor{,DNC}) |
-------------------------------------------------------------------
| ... | ... | ... |
-------------------------------------------------------------------
| 4 (0:5) | ... | local_decap({VRF}) |
-------------------------------------------------------------------
| 5 (0:6) | ... | forward_routed({VRF,}l3-neighbor) |
-------------------------------------------------------------------
| 6 (0:7) | ... | <empty> |
-------------------------------------------------------------------
| 7 (0:8) | ... | ECMP((adjacency1,...adjacencyN){,seed}) |
-------------------------------------------------------------------
| BIFT indices for BitString/Packet with SI=1 |
-------------------------------------------------------------------
| 9 (1:1) | | ... |
| ... | ... | ... |
-------------------------------------------------------------------
Figure 4: BIER-TE Bit Index Forwarding Table (BIFT) with Different Adjacencies
図4：さまざまな隣接を持つビアテビットインデックス転送テーブル（bift）
The BIFT is configured for the BIER-TE data plane of a BFR by the BIER-TE controller through an appropriate protocol and data model. The BIFT is then used to forward packets, according to the procedures for the BIER-TE forwarding plane as specified in Section 3.3.
BIFTは、適切なプロトコルとデータモデルを介して、BIRTEコントローラーによってBFRのBier-TEデータプレーン用に構成されています。セクション3.3で指定されているように、Bier-TE転送面の手順に従って、BIFTはパケットを転送するために使用されます。
Note that a BIFT-index (SI:BP) may be populated in the BIFT of more than one BFR to save BPs. See Section 5.1.6 for an example of how a BIER-TE controller could assign BPs to (logical) adjacencies shared across multiple BFRs, Section 5.1.3 for an example of assigning the same BP to different adjacencies, and Section 5.1.9 for general guidelines regarding the reuse of BPs across different adjacencies.
BPSを節約するために、Bift-Index（SI：BP）が複数のBFRのビフトに入力される可能性があることに注意してください。BIER-TEコントローラーが複数のBFRで共有された（論理）隣接にBPを割り当てる方法の例については、セクション5.1.6、同じBPを異なる隣接に割り当てる例については、セクション5.1.3、およびセクション5.1.9の例を参照してください。さまざまな隣接にわたるBPの再利用に関する一般的なガイドライン。
{VRF} indicates the Virtual Routing and Forwarding context into which the BIER payload is to be delivered. This is optional and depends on the multicast flow overlay.
{vrf}は、ビアペイロードを配信する仮想ルーティングと転送コンテキストを示します。これはオプションであり、マルチキャストフローオーバーレイに依存します。
A "forward_connected()" adjacency is an adjacency towards a directly connected BFR-NBR using an interface address of that BFR on the connecting interface. A forward_connected() adjacency does not route packets; only L2 forwards them to the neighbor.
「Forward_Connected（）」の隣接は、接続インターフェイス上のそのBFRのインターフェイスアドレスを使用して、直接接続されたBFR-NBRへの隣接です。Forward_Connected（）隣接はパケットをルーティングしません。L2だけが隣人に転送します。
Packets sent to an adjacency with "DoNotClear" (DNC) set in the BIFT MUST NOT have the bit position for that adjacency cleared when the BFR creates a copy for it. The bit position will still be cleared for copies of a packet made towards other adjacencies. This can be used, for example, in ring topologies as explained in Section 5.1.6.
biftに設定された「donotclear」（DNC）が隣接するパケットは、BFRがコピーを作成したときにクリアされた隣接のビット位置を持たないはずです。ビット位置は、他の隣接に向けて作成されたパケットのコピーに対してまだクリアされます。これは、たとえば、セクション5.1.6で説明されているように、リングトポロジーで使用できます。
For protection against loops caused by misconfiguration (see Section 5.2.1), DNC is only permissible for forward_connected() adjacencies. No need or benefit of DNC for other types of adjacencies was identified, and associated risks were not analyzed.
誤解によって引き起こされるループに対する保護のため（セクション5.2.1を参照）、DNCはForward_Connected（）隣接のみを許可します。他のタイプの隣接するためのDNCのニーズまたは利点は特定されておらず、関連するリスクは分析されませんでした。
A "forward_routed()" adjacency is an adjacency towards a BFR that uses a (tunneling) encapsulation that will cause a packet to be forwarded by the routing underlay towards the adjacent BFR indicated via the l3-neighbor parameter of the forward_routed() adjacency. This can leverage any feasible encapsulation, such as MPLS or tunneling over IP/IPv6, as long as the BIER-TE packet can be identified as a payload. This identification can rely on either the BIER/BIER-TE co-existence mechanisms described in Section 4.3 or explicit support for a BIER-TE payload type in the tunneling encapsulation.
「Forward_Routed（）」の隣接は、（トンネリング）カプセル化を使用するBFRへの隣接であり、パケットが転送された隣接BFRに向かって転送されるパケットを転送します。これにより、Bier-TEパケットがペイロードとして識別できる限り、MPLSやIP/IPv6上のトンネルなどの実行可能なカプセル化を活用できます。この識別は、セクション4.3で説明されているビア/ビアテの共存メカニズム、またはトンネリングカプセル化のビアテペイロードタイプの明示的なサポートのいずれかに依存できます。
Forward_routed() adjacencies are necessary to pass BIER-TE traffic across routers that are not BIER-TE capable or to minimize the number of required BPs by tunneling over (BIER-TE-capable) routers on which neither replication nor path steering is desired, or simply to leverage the routing underlay's path redundancy and FRR towards the next BFR. They may also be useful to a multi-subnet adjacent BFR for leveraging the routing underlay ECMP independently of BIER-TE ECMP (Section 4.2.3).
Forward_Routed（）隣接は、ビアテが使用できないルーターにビアテのトラフィックを渡すか、複製もパスステアリングも望まないトンネリング（ビアテテーブル）ルーターをトンネリングすることで必要なBPの数を最小限に抑えるために必要です。または、単にルーティングアンダーレイのパス冗長性とFRRを次のBFRに向けて活用するためです。また、ビアテECMPとは無関係にルーティングアンダーレイECMPを活用するために、マルチサブネット隣接するBFRにとっても役立ちます（セクション4.2.3）。
(Non-TE) BIER ECMP is tied to the BIER BIFT processing semantic and is therefore not directly usable with BIER-TE.
（非TE）Bier ECMPは、Bier Bift Processing Semanticに結び付けられているため、BierTEで直接使用できません。
A BIER-TE "Equal-Cost Multipath" (ECMP()) adjacency as shown in Figure 4 for BIFT-index 7 has a list of two or more non-ECMP() adjacencies as parameters and an optional seed parameter. When a BIER-TE packet is copied onto such an ECMP() adjacency, an implementation-specific so-called hash function will select one out of the list's adjacencies to which the packet is forwarded. If the packet's encapsulation contains an entropy field, the entropy field SHOULD be respected; two packets with the same value of the entropy field SHOULD be sent on the same adjacency. The seed parameter permits the design of hash functions that are easy to implement at high speed without running into polarization issues across multiple consecutive ECMP hops. See Section 5.1.7 for details.
Bift-Index 7の図4に示すように、ビアテの「等しいコストマルチパス」（ECMP（））の隣接は、パラメーターとして2つ以上の非ECMP（）隣接のリストとオプションのシードパラメーターのリストを持っています。BierTTEパケットがそのようなECMP（）隣接にコピーされると、実装固有のいわゆるハッシュ関数は、パケットが転送されるリストの隣接から1つを選択します。パケットのカプセル化にエントロピーフィールドが含まれている場合、エントロピーフィールドを尊重する必要があります。エントロピーフィールドの同じ値を持つ2つのパケットは、同じ隣接する上で送信する必要があります。シードパラメーターは、複数の連続したECMPホップで偏光の問題に遭遇することなく、高速で簡単に実装できるハッシュ関数の設計を許可します。詳細については、セクション5.1.7を参照してください。
A "local_decap()" adjacency passes a copy of the payload of the BIER-TE packet to the protocol ("NextProto") within the BFR (IP/IPv6, Ethernet,...) responsible for that payload according to the packet header fields. A local_decap() adjacency turns the BFR into a BFER for matching packets. Local_decap() adjacencies require the BFER to support routing or switching for NextProto to determine how to further process the packets.
「local_decap（）」隣接は、パケットヘッダーに従ってそのペイロードを担当するbfr（ip/ipv6、ethernet、...）内のプロトコル（ "nextproto"）へのBier-TEパケットのペイロードのコピーを渡します。田畑。local_decap（）隣接は、一致するパケットのためにBFRをBFRに変えます。local_decap（）隣接は、パケットをさらに処理する方法を決定するために、nextprotoのルーティングまたはスイッチングをサポートする必要があります。
Specifications for BIER-TE encapsulation are outside the scope of this document. This section gives explanations and guidelines.
BierTEカプセル化の仕様は、このドキュメントの範囲外です。このセクションでは、説明とガイドラインを示します。
The handling of "Maximum Transmission Unit" (MTU) limitations is outside the scope of this document and is not discussed in [RFC8279] either. Instead, this process is part of the BIER-TE packet encapsulation and/or flow overlay; for example, see [RFC8296], Section 3. It applies equally to BIER-TE and BIER.
「最大送信ユニット」（MTU）の制限の取り扱いは、このドキュメントの範囲外であり、[RFC8279]でも説明されていません。代わりに、このプロセスは、Bier-TEパケットカプセル化および/またはフローオーバーレイの一部です。たとえば、[RFC8296]、セクション3を参照してください。これは、BierTeとBierに等しく適用されます。
Because a BFR needs to interpret the BitString of a BIER-TE packet differently from a (non-TE) BIER packet, it is necessary to distinguish BIER packets from BIER-TE packets. In BIER encapsulation [RFC8296], the BIFT-id field of the packet indicates the BIFT of the packet. BIER and BIER-TE can therefore be run simultaneously, when the BIFT-id address space is shared across BIER BIFTs and BIER-TE BIFTs. Partitioning the BIFT-id address space is subject to BIER-TE/ BIER control plane procedures.
BFRは、（非TTE）ビアパケットとは異なるBierTTEパケットのビットストリングを解釈する必要があるため、Bier-TEパケットとBier-TEパケットを区別する必要があります。Bierカプセル化[RFC8296]では、パケットのBIFT-IDフィールドはパケットのBIFTを示しています。したがって、Bift-IDアドレススペースがビアバイフトとビアテバイフトで共有される場合、ビアとビアテは同時に実行できます。BIFT-IDアドレススペースのパーティション化は、Bier-TE/ Bierコントロールプレーンの手順の対象となります。
When [RFC8296] is used for BIER with MPLS, BIFT-id address ranges can be dynamically allocated from MPLS label space only for the set of actually used SD:BSL BIFTs. This also permits the allocation of non-overlapping label ranges for BIFT-ids that are to be used with BIER-TE BIFTs.
[RFC8296]がMPLSでビアに使用される場合、BIFT-IDアドレス範囲は、実際に使用されるSD：BSL BIFTSのセットに対してのみ、MPLSラベルスペースから動的に割り当てることができます。これにより、Bier-Te Biftsで使用されるBift-IDの非重複ラベル範囲の割り当ても可能になります。
With MPLS, it is also possible to reuse the same SD space for both BIER-TE and BIER, so that the same SD has both a BIER BIFT with a corresponding range of BIFT-ids and disjoint BIER-TE BIFTs with a non-overlapping range of BIFT-ids.
MPLSを使用すると、同じSDスペースをビアテとビアの両方に再利用することもできます。そのため、同じSDには、対応する範囲のbift-idsと非重複するバイアテバイフトの両方のビアバイフトがあります。Bift-IDの範囲。
Assume that a fixed mapping from BSL, SD, and SI to a BIFT-id is used, which does not explicitly partition the BIFT-id space between BIER and BIER-TE -- for example, as proposed for non-MPLS forwarding with BIER encapsulation [RFC8296] in [NON-MPLS-BIER-ENCODING], Section 5. In this case, it is necessary to allocate disjoint SDs to BIER and BIER-TE BIFTs so that both can be addressed by the BIFT-ids. The encoding proposed in Section 6 of [NON-MPLS-BIER-ENCODING] does not statically encode the BSL or SD into the BIFT-id, but the encoding permits a mapping and hence could provide the same freedom as when MPLS is being used (the same SD, or different SDs for BIER/ BIER-TE).
BSL、SD、およびSIからBift-IDへの固定マッピングが使用されていると仮定します。これは、BierとBier-TEの間のBift-IDスペースを明示的に分割しないと仮定します。[Non-Mpls-Bier-Encoding]、セクション5のカプセル化[RFC8296]、この場合、Bift-IDが両方に対処できるように、BierとBierteのバイフトに馬鹿げたSDを割り当てる必要があります。[Non-Mpls-Bier-Encoding]のセクション6で提案されているエンコーディングは、BSLまたはSDをBIFT-IDに静的にエンコードしませんが、エンコードによりマッピングが許可されているため、MPLSが使用されている場合と同じ自由を提供できます（同じSD、またはBier/ Bier-Teの異なるSD）。
Forward_routed() requires an encapsulation that permits directing unicast encapsulated BIER-TE packets to a specific interface address on a target BFR. With MPLS encapsulation, this can simply be done via a label stack with that address's label as the top label, followed by the label assigned to the (BSL,SD,SI) BitString. With non-MPLS encapsulation, some form of IP encapsulation would be required (for example, IP/GRE).
Forward_Routed（）では、ターゲットBFRの特定のインターフェイスアドレスにユニキャストカプセル化されたビアテパケットを向けることを可能にするカプセル化が必要です。MPLSのカプセル化を使用すると、このアドレスのラベルをトップレーベルとしてラベルスタックを介して実行でき、その後に（BSL、SD、SI）BitStringに割り当てられたラベルが続きます。非MPLSカプセル化の場合、何らかの形のIPカプセル化が必要です（たとえば、IP/GRE）。
The encapsulation used for forward_routed() adjacencies can equally support existing advanced adjacency information such as "loose source routes" via, for example, MPLS label stacks or appropriate header extensions (e.g., for IPv6).
Forward_Routed（）隣接に使用されるカプセル化は、MPLSラベルスタックや適切なヘッダー拡張機能（IPv6など）を介して「ルーズソースルート」などの既存の高度な隣接情報を均等にサポートできます。
The pseudocode for BIER-TE forwarding, as shown in Figure 5, is based on the (non-TE) BIER forwarding pseudocode provided in [RFC8279], Section 6.5, with one modification.
図5に示すように、ビアテ転送用の擬似コードは、[RFC8279]、セクション6.5に記載されている（非）ビア転送擬似コードに基づいています。
void ForwardBitMaskPacket_withTE (Packet)
{
SI=GetPacketSI(Packet);
Offset=SI*BitStringLength;
for (Index = GetFirstBitPosition(Packet->BitString); Index ;
Index = GetNextBitPosition(Packet->BitString, Index)) {
F-BM = BIFT[Index+Offset]->F-BM;
if (!F-BM) continue; [3]
BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
PacketCopy = Copy(Packet);
PacketCopy->BitString &= F-BM; [2]
PacketSend(PacketCopy, BFR-NBR);
// The following must not be done for BIER-TE:
// Packet->BitString &= ~F-BM; [1]
}
}
Figure 5: BIER-TE Forwarding Pseudocode for Required Functions, Based on BIER Pseudocode
図5：Bier-Pseudocodeに基づいて、必要な関数のビアテ転送擬似コード
In step [2], the F-BM is used to clear one or more bits in PacketCopy. This step exists in both BIER and BIER-TE, but the F-BMs need to be populated differently for BIER-TE than for BIER for the desired clearing.
ステップ[2]では、F-BMを使用して、PacketCopyの1つ以上のビットをクリアします。このステップはBierTTとBierTEの両方に存在しますが、F-BMSは、希望のクリアリングのビアよりもビアテの場合に異なる方法で入力する必要があります。
In BIER, multiple bits of a BitString can have the same BFR-NBR. When a received packets BitString has more than one of those bits set, BIER's replication logic has to prevent more than one PacketCopy from being sent to that BFR-NBR ([1]). Likewise, the PacketCopy sent to a BFR-NBR must clear all bits in its BitString that are not routed across a BFR-NBR. This prevents BIER's replication logic from creating duplicates on any possible further BFRs ([2]).
ビアでは、ビットストリングの複数のビットに同じBFR-NBRがあります。受信したパケットBitStringがこれらのビットセットを複数持っている場合、Bierのレプリケーションロジックは、複数のPacketCopyがそのBFR-NBRに送信されるのを防ぐ必要があります（[1]）。同様に、BFR-NBRに送信されたPacketCopyは、BFR-NBRを横切ってルーティングされていないビットストリングのすべてのビットをクリアする必要があります。これにより、Bierの複製ロジックが可能なさらなるBFRに重複を作成することを防ぎます（[2]）。
To solve both [1] and [2] for BIER, the F-BM of each bit index needs to have all bits set that this BFR wants to route across a BFR-NBR. [2] clears all other bits in PacketCopy->BitString, and [1] clears those bits from Packet->BitString after the first PacketCopy.
ビアに対して[1]と[2]の両方を解くには、各ビットインデックスのF-BMには、このBFRがBFR-NBRを横断するすべてのビットを設定する必要があります。[2] PacketCopy-> BitStringの他のすべてのビットをクリアし、[1]は、最初のPacketCopyの後にPacket-> BitStringからそれらのビットをクリアします。
In BIER-TE, a BFR-NBR in this pseudocode is an adjacency -- forward_connected(), forward_routed(), or local_decap(). There is no need for [2] to suppress duplicates in the same way that BIER does, because in general, different BPs would never have the same adjacency. If a BIER-TE controller actually finds some optimization in which this would be desirable, then the controller is also responsible for ensuring that only one of those bits is set in any Packet->BitString, unless the controller explicitly wants duplicates to be created.
Bier-TEでは、この擬似コードのBFR-NBRは、隣接 - forward_connected（）、forward_routed（）、またはlocal_decap（）です。[2]は、一般に、異なるBPが同じ隣接を持たないため、Bierと同じ方法で重複を抑制する必要はありません。Bierteコントローラーが実際にこれが望ましい最適化を見つけた場合、コントローラーは、コントローラーが明示的に重複を作成したい場合を除き、それらのビットの1つだけがパケットに設定されていることを保証する責任もあります。
The following points describe how the F-BM for each BP is configured in the BIFT and how this impacts the BitString of the packet being processed with that BIFT:
次のポイントは、各BPのF-BMがBIFTでどのように構成され、これがそのBIFTで処理されるパケットのビットストリングにどのように影響するかを説明します。
1. The F-BMs of all BIFT BPs without an adjacency have all their bits clear. This will cause [3] to skip further processing of such a BP.
1. 隣接するすべてのBIFT BPSのF-BMSには、すべてのビットがクリアされています。これにより、[3]はそのようなBPのさらなる処理をスキップします。
2. All BIFT BPs with an adjacency (with the DNC flag clear) have an F-BM that has only those BPs set for which this BFR does not have an adjacency. This causes [2] to clear all bits from PacketCopy->BitString for which this BFR does have an adjacency.
2. 隣接するすべてのBIFT BPS（DNCフラグがクリアされた）には、このBFRに隣接性がないBPSのみが設定されているF-BMがあります。これにより、[2]は、このBFRが隣接しているPacketCopy-> BitStringからすべてのビットをクリアします。
3. [1] is not performed for BIER-TE. All bit clearing required by BIER-TE is performed by [2].
3. [1]は、BierTeに対しては実行されません。BierTTEが必要とするすべてのビットクリアリングは、[2]によって実行されます。
This forwarding pseudocode can support the required BIER-TE forwarding functions (see Section 4.5) -- forward_connected(), forward_routed(), and local_decap() -- but cannot support the recommended functions (DNC flag and multiple adjacencies per bit) or the optional function (i.e., ECMP() adjacencies). The DNC flag cannot be supported when using only [1] to mask bits.
この転送擬似コードは、必要なBier-TE転送機能をサポートできます（セクション4.5を参照） - Forward_Connected（）、Forward_Routed（）、およびlocal_decap（） - は、推奨機能（DNCフラグとビットあたりの複数の隣接）またはオプション関数（つまり、ECMP（）隣接）。[1]のみを使用してビットをマスクする場合、DNCフラグはサポートできません。
The modified and expanded forwarding pseudocode in Figure 6 specifies how to support all BIER-TE forwarding functions (required, recommended, and optional):
図6の修正および拡張された転送擬似コードは、すべてのビアー転送機能（必須、推奨、およびオプション）をサポートする方法を示しています。
1. This pseudocode eliminates per-bit F-BMs, therefore reducing the size of BIFT state by SI*BSL^2 and eliminating the need for per-packet-copy BitString masking operations, except for adjacencies with the DNC flag set:
1. この擬似コードはビットごとのF-BMSを排除するため、DNCフラグセットの隣接を除き、パケットごとのビットストリングマスキング操作の必要性をsi*bsl^2で削除し、次のことを除きます。
1.a AdjacentBits[SI] are bit positions with a non-empty list of adjacencies in this BFR BIFT. This can be computed whenever the BIER-TE controller updates (adds/removes) adjacencies in the BIFT.
1.A隣接ビット[SI]は、このBFR BIFTの隣接の非空白のリストを持つビット位置です。これは、BIRTの隣接をBIFTで更新（追加/削除）するたびに計算できます。
1.b The BFR needs to create packet copies for these adjacent bits when they are set in the packets BitString. This set of bits is calculated in PktAdjacentBits.
1.b BFRは、これらの隣接するビットのパケットコピーを作成する必要があります。このビットのセットは、pktadjacentbitsで計算されます。
1.c All bit positions for which the BFR creates copies have to be cleared in packet copies to avoid loops. This is done by masking the BitString of the packet with ~AdjacentBits[SI]. When an adjacency has DNC set, this bit position is set again only for the packet copy towards that bit position.
1.C BFRが作成するすべてのビット位置は、ループを避けるためにパケットコピーでコピーをクリアする必要があります。これは、パケットのビットストリングを〜隣接ビット[si]でマスキングすることによって行われます。隣接するDNCが設定されている場合、このビット位置は、そのビット位置に向かってパケットコピーに対してのみ再度設定されます。
2. BIFT entries may contain more than one adjacency in support of specific configurations, such as a hub and multiple spokes (Section 5.1.5). The code therefore includes a loop over these adjacencies.
2. BIFTエントリには、ハブや複数のスポークなどの特定の構成をサポートするために、複数の隣接を含めることができます（セクション5.1.5）。したがって、コードには、これらの隣接するループが含まれています。
3. The ECMP() adjacency is also shown in the figure. Its parameters are a seed and "ListOfAdjacencies", from which one is picked.
3. ECMP（）隣接も図にも示されています。そのパラメーターは、シードと「リストファジエンシー」であり、そこから選択されます。
4. The forward_connected(), forward_routed(), and local_decap() adjacencies are shown with their parameters.
4. Forward_Connected（）、Forward_Routed（）、およびlocal_decap（）隣接はパラメーターとともに表示されます。
void ForwardBitMaskPacket_withTE (Packet)
{
SI = GetPacketSI(Packet);
Offset = SI * BitStringLength;
// Determine adjacent bits in the packets BitString
PktAdjacentBits = Packet->BitString & AdjacentBits[SI];
// Clear adjacent bits in the packet header to avoid loops
Packet->BitString &= ~AdjacentBits[SI];
// Loop over PktAdjacentBits to create packet copies
for (Index = GetFirstBitPosition(PktAdjacentBits); Index ;
Index = GetNextBitPosition(PktAdjacentBits, Index)) {
for adjacency in BIFT[Index+Offset]->Adjacencies {
if(adjacency.type == ECMP(ListOfAdjacencies,seed) ) {
I = ECMP_hash(sizeof(ListOfAdjacencies),
Packet->Entropy,seed);
adjacency = ListOfAdjacencies[I];
}
PacketCopy = Copy(Packet);
switch(adjacency.type) {
case forward_connected(interface,neighbor,DNC):
if(DNC)
PacketCopy->BitString |= 1<<(Index-1);
SendToL2Unicast(PacketCopy,interface,neighbor);
case forward_routed({VRF,}l3-neighbor):
SendToL3(PacketCopy,{VRF,}l3-neighbor);
case local_decap({VRF},neighbor):
DecapBierHeader(PacketCopy);
PassTo(PacketCopy,{VRF,}Packet->NextProto);
}
}
}
}
Figure 6: Complete BIER-TE Forwarding Pseudocode for Required, Recommended, and Optional Functions
図6：必要、推奨、およびオプションの機能に合わせて、BierTE転送の完了PSEUDOCODE
BFRs that support BIER-TE and BIER MUST support a configuration that enables BIER-TE instead of (non-TE) BIER forwarding rules for all BIFTs of one or more BIER subdomains. Every BP in a BIER-TE BIFT MUST support having zero or one adjacency. BIER-TE forwarding MUST support the adjacency types forward_connected() with the DNC flag not set, forward_routed(), and local_decap(). As explained in Section 4.4, these required BIER-TE forwarding functions can be implemented via the same forwarding pseudocode as that used for BIER forwarding, except for one modification (skipping one masking with an F-BM).
BierTTEおよびBIERをサポートするBFRは、1つ以上のビアサブドメインのすべてのバイフトの（非）ビア転送ルールの代わりにBierTEを有効にする構成をサポートする必要があります。Bierte BiftのすべてのBPは、ゼロまたは1つの隣接を持つことをサポートする必要があります。BierTTE転送は、dncフラグを設定していないDNC Flag、forward_routed（）、およびlocal_decap（）を使用して、隣接型forward_connected（）をサポートする必要があります。セクション4.4で説明したように、これらの必要なビアテ転送機能は、1つの変更（F-BMで1つのマスキングをスキップする）を除き、ビア転送に使用したものと同じ転送擬似コードを介して実装できます。
BIER-TE forwarding SHOULD support forward_connected() adjacencies with the DNC flag set, as this is very useful for saving bits in rings (see Section 5.1.6).
Bier-TEの転送は、DNCフラグセットのForward_Connected（）隣接をサポートする必要があります。これは、リングのビットを保存するのに非常に役立つためです（セクション5.1.6を参照）。
BIER-TE forwarding SHOULD support more than one adjacency on a bit. This allows bits to be saved in hub-and-spoke scenarios (see Section 5.1.5).
Bierteの転送は、複数の隣接を少しサポートする必要があります。これにより、ハブアンドスポークシナリオでビットを保存できます（セクション5.1.5を参照）。
BIER-TE forwarding MAY support ECMP() adjacencies to save bits in ECMP scenarios; see Section 5.1.7 for an example. This is an optional requirement, because for ECMP deployments using BIER-TE one can also leverage the routing underlay ECMP via forward_routed() adjacencies and/or might prefer to have more explicit control of the path chosen via explicit BPs/adjacencies for each ECMP path alternative.
BierTTE転送は、ECMP（）隣接をサポートして、ECMPシナリオのビットを節約することができます。例については、セクション5.1.7を参照してください。これはオプションの要件です。Bier-TEを使用したECMPの展開では、forward_routed（）隣接を介してルーティングアンダーレイECMPを活用したり、各ECMPパスの明示的なBPS/隣接を介して選択されたパスをより明示的に制御することを好む可能性があるため別。
This section describes how the BIER-TE controller can use the different BIER-TE adjacency types to define the bit positions of a BIER-TE domain.
このセクションでは、Bier-TEコントローラーがさまざまなBier-TE隣接型タイプを使用して、Bier-TEドメインのビット位置を定義する方法について説明します。
Because the size of the BitString limits the size of the BIER-TE domain, many of the options described here exist to support larger topologies with fewer bit positions.
ビットストリングのサイズはビアテドメインのサイズを制限するため、ここで説明するオプションの多くは、ビット位置が少ない大きなトポロジをサポートするために存在します。
On a "point-to-point" (P2P) link that connects two BFRs, the same bit position can be used on both BFRs for the adjacency to the neighboring BFR. A P2P link therefore requires only one bit position.
2つのBFRを接続する「ポイントツーポイント」（P2P）リンクでは、隣接するBFRへの隣接するために両方のBFRで同じビット位置を使用できます。したがって、P2Pリンクには1つのビット位置のみが必要です。
Every non-leaf BFER is given a unique bit position with a local_decap() adjacency.
すべての非葉のBFerには、local_decap（）隣接を備えた一意のビット位置が与えられます。
A leaf BFER is one where incoming BIER-TE packets never need to be forwarded to another BFR but are only sent to the BFER to exit the BIER-TE domain. For example, in networks where "Provider Edge" (PE) routers are spokes connected to Provider (P) routers, those PEs are leaf BFERs, unless there is a U-turn between two PEs.
葉のbferは、入ってくるビアテのパケットを別のBFRに転送する必要はなく、Bier-TEドメインを出るためにBFERにのみ送られる場合です。たとえば、「プロバイダーエッジ」（PE）ルーターがプロバイダー（P）ルーターに接続されたスポークであるネットワークでは、2つのPEの間にUターンがない限り、これらのPEは葉の範囲です。
Consider how redundant disjoint traffic can reach BFER1/BFER2 as shown in Figure 7: when BFER1/BFER2 are non-leaf BFERs as shown on the right-hand side, one traffic copy would be forwarded to BFER1 from BFR1, but the other one could only reach BFER1 via BFER2, which makes BFER2 a non-leaf BFER. Likewise, BFER1 is a non-leaf BFER when forwarding traffic to BFER2. Note that the BFERs on the left-hand side of the figure are only guaranteed to be leaf BFERs by correctly applying a routing configuration that prohibits transit traffic from passing through the BFERs, which is commonly applied in these topologies.
図7に示すように、冗長な分離トラフィックがBFER1/BFER2にどのように到達できるかを考えてください：BFER1/BFER2が右側に示されているように非葉のBFERSである場合、1つのトラフィックコピーはBFR1からBFER1に転送されますが、もう1つは可能です。Bfer2を介してBfer1にのみ到達するため、Bfer2は非葉のBFerになります。同様に、BFER1はBFER2にトラフィックを転送する際の非葉のBFerです。図の左側のBFERは、これらのトポロジに一般的に適用されるBFERSを通過することを輸送することを禁止するルーティング構成を正しく適用することにより、葉のBFEであることのみが保証されていることに注意してください。
BFR1(P) BFR2(P) BFR1(P) BFR2(P)
| \ / | | |
| X | | |
| / \ | | |
BFER1(PE) BFER2(PE) BFER1(PE)----BFER2(PE)
^ U-turn link
^ Uターンリンク
Leaf BFER / Non-leaf BFER / PE router PE router
リーフbfer / leaf bfer / peルーターPEルーター
Figure 7: Leaf vs. Non-Leaf BFER Example
図7：葉と非葉のbferの例
In most situations, leaf BFERs that are to be addressed via the same BitString can share a single bit position for their local_decap() adjacency in that BitString and therefore save bit positions. On a non-leaf BFER, a received BIER-TE packet may only need to transit the BFER, or it may also need to be decapsulated. Whether or not to decapsulate the packet therefore needs to be indicated by a unique bit position populated only on the BIFT of this BFER with a local_decap() adjacency. On a leaf BFER, packets never need to pass through; any packet received is therefore usually intended to be decapsulated. This can be expressed by a single, shared bit position that is populated with a local_decap() adjacency on all leaf BFERs addressed by the BitString.
ほとんどの状況では、同じビットストリングを介して対処される葉のbferは、そのビットストリングでlocal_decap（）隣接の単一のビット位置を共有し、したがってビット位置を節約できます。非葉のBFERでは、受信したビアテのパケットは、BFERを通過するだけであるか、脱カプセル化する必要がある場合があります。したがって、パケットを脱カプセル化するかどうかは、Local_decap（）隣接性を備えたこのbferのビフトにのみ存在する一意のビット位置を示す必要があります。葉のbferでは、パケットを通過する必要はありません。したがって、受信したパケットは、通常、脱カプセル化することを目的としています。これは、ビットストリングが扱うすべての葉のbferにlocal_decap（）隣接が入力される単一の共有ビット位置で表現できます。
The possible exceptions to this leaf BFER bit position optimization scenario can be cases where the bit position on the prior BIER-TE BFR (which created the packet copy for the leaf BFER in question) is populated with multiple adjacencies as an optimization -- for example, as described in Sections 5.1.4 and 5.1.5. With either of these two optimizations, the sender of the packet could only control explicitly whether the packet was to be decapsulated on the leaf BFER in question, if the leaf BFER has a unique bit position for its local_decap() adjacency.
このLeaf Bfer BITの位置最適化シナリオの可能な例外は、以前のBier-TE BFRのビット位置（問題のLeaf Bferのパケットコピーを作成した）が最適化として複数の隣接を入力している場合です。、セクション5.1.4および5.1.5で説明されています。これら2つの最適化のいずれかを使用して、パケットの送信者は、Leaf BferがLocal_Decap（）隣接性のユニークなビット位置を持っている場合、問題のLeaf Bferでパケットを脱カプセル化するかどうかのみを明示的に制御できます。
However, if the bit position is shared across a leaf BFER and packets are therefore decapsulated -- potentially unnecessarily -- this may still be appropriate if the decapsulated payload of the BIER-TE packet indicates whether or not the packets need to be further processed/received. This is typically true, for example, if the payload is IP multicast, because IP multicast on a BFER would know the membership state of the IP multicast payload and be able to discard it if the packets were delivered unnecessarily by the BIER-TE layer. If the payload has no such membership indication and the BFIR wants to have explicit control regarding which BFERs are to receive and decapsulate a packet, then these two optimizations cannot be used together with shared bit position optimization for a leaf BFER.
ただし、ビット位置がリーフbferで共有され、パケットが脱カプセル化されている場合（潜在的に不必要に）、Bier-TEパケットのカプセル化されたペイロードがパケットをさらに処理する必要があるかどうかを示している場合、これはまだ適切かもしれません/受け取った。これは通常、ペイロードがIPマルチキャストの場合、BFERのIPマルチキャストがIPマルチキャストペイロードのメンバーシップ状態を知っており、ビアテ層によってパケットが不必要に配信された場合に破棄することができるためです。ペイロードにそのようなメンバーシップの兆候がなく、BFIRがパケットを受信して脱カプセル化するbferに関して明示的な制御を望んでいる場合、これら2つの最適化は、リーフbferの共有ビット位置最適化と一緒に使用できません。
In a LAN, the adjacency to each neighboring BFR is given a unique bit position. The adjacency of this bit position is a forward_connected() adjacency towards the BFR, and this bit position is populated into the BIFT of all the other BFRs on that LAN.
LANでは、隣接する各BFRへの隣接には一意のビット位置が与えられます。このビット位置の隣接は、BFRへのForward_Connected（）隣接性であり、このビット位置は、そのLAN上の他のすべてのBFRのビフトに入力されます。
BFR1
|p1
LAN1-+-+---+-----+
p3| p4| p2|
BFR3 BFR4 BFR7
Figure 8: LAN Example
図8：LANの例
If bandwidth on the LAN is not an issue and most BIER-TE traffic should be copied to all neighbors on a LAN, then bit positions can be saved by assigning just a single bit position to the LAN and populating the bit position of the BIFTs of each BFR on the LAN with a list of forward_connected() adjacencies to all other neighbors on the LAN.
LANの帯域幅が問題ではなく、ほとんどのビアテトラフィックをLAN上のすべての隣人にコピーする必要がある場合、LANに単一のビット位置を割り当てて、ビフトのビート位置を入力することでビット位置を保存できます。LAN上の各BFRは、LAN上の他のすべての隣人へのForward_Connected（）隣接のリストを掲載しています。
This optimization does not work in the case of BFRs redundantly connected to more than one LAN with this optimization. These BFRs would receive duplicates and forward those duplicates into the other LANs. Such BFRs require separate bit positions for each LAN they connect to.
この最適化は、この最適化を伴うBFRSの場合、BFRSの場合には機能しません。これらのBFRは重複を受け取り、それらの重複を他のLANに転送します。このようなBFRは、接続する各LANに対して個別のビット位置を必要とします。
In a setup with a hub and multiple spokes connected via separate P2P links to the hub, all P2P adjacencies from the hub to the spokes' links can share the same bit position. The bit position on the hub's BIFT is set up with a list of forward_connected() adjacencies, one for each spoke.
ハブへの個別のP2Pリンクを介して接続されたハブと複数のスポークを備えたセットアップでは、ハブからスポークのリンクまでのすべてのP2P隣接が同じビット位置を共有できます。HubのBiftのビット位置は、SOPEDごとに1つずつ、Forward_Connected（）隣接のリストでセットアップされています。
This option is similar to the bit position optimization in LANs: redundantly connected spokes need their own bit positions, unless they are themselves leaf BFERs.
このオプションは、LANSのビットポジションの最適化に似ています。冗長に接続されたスポークは、自分自身が葉のbferでない限り、独自のビットポジションを必要とします。
This type of optimized BP could be used, for example, when all traffic is "broadcast" traffic (very dense receiver sets), such as live TV or many-to-many telemetry, including situational awareness. This BP optimization can then be used to explicitly steer different traffic flows across different ECMP paths in data-center or broadband-aggregation networks with minimal use of BPs.
このタイプの最適化されたBPは、たとえば、すべてのトラフィックがライブテレビや多くのテレメトリなど、状況認識を含む多くの多くのテレメトリなどのトラフィック（非常に密なレシーバーセット）を「ブロードキャスト」している場合に使用できます。このBPの最適化を使用して、BPの使用を最小限に抑えながら、データセンターまたはブロードバンド凝集ネットワークの異なるECMPパスを越えて異なるトラフィックフローを明示的に操作できます。
In L3 rings, instead of assigning a single bit position for every P2P link in the ring, it is possible to save bit positions by setting the "DoNotClear" (DNC) flag on forward_connected() adjacencies.
L3リングでは、リング内のP2Pリンクごとに単一のビット位置を割り当てる代わりに、forward_connected（）隣接（）隣接する「donotclear」（DNC）フラグを設定することにより、ビット位置を保存することができます。
For the ring shown in Figure 9, a single bit position will suffice to forward traffic entering the ring at BFRa or BFRb all the way up to BFR1, as follows.
図9に示すリングの場合、次のように、BFRAまたはBFRBのリングに入るトラフィックをBFRAまたはBFRBに移動するのに1つのビット位置で十分です。
On BFRa, BFRb, BFR30,... BFR3, the bit position is populated with a forward_connected() adjacency pointing to the clockwise neighbor on the ring and with DNC set. On BFR2, the adjacency also points to the clockwise neighbor BFR1, but without DNC set.
BFRA、BFRB、BFR30、... BFR3では、ビット位置には、リング上の時計回りの隣人とDNCセットを指すForward_Connected（）隣接する隣接性が入力されています。BFR2では、隣接は時計回りの隣のBFR1を指していますが、DNCセットはありません。
Handling DNC this way ensures that copies forwarded from any BFRs in the ring to a BFR outside the ring will not have the ring bit position set, therefore minimizing the risk of creating loops.
この方法でDNCを処理すると、リング内のBFRからリングの外側のBFRに転送されたコピーがリングビット位置が設定されていないため、ループを作成するリスクが最小限に抑えられます。
v v
| |
L1 | L2 | L3
/-------- BFRa ---- BFRb --------------------\
| |
\- BFR1 - BFR2 - BFR3 - ... - BFR29 - BFR30 -/
| | L4 | |
p33| p15|
BFRd BFRc
Figure 9: Ring Example
図9：リングの例
Note that this example only permits packets intended to make it all the way around the ring to enter it at BFRa and BFRb. Note also that packets will always travel clockwise. If packets should be allowed to enter the ring at any of the ring's BFRs, then one would have to use two ring bit positions, one for each direction: clockwise and counterclockwise.
この例は、リングの周りにすべてのパケットを作成してBFRAとBFRBに入力することを目的としていることに注意してください。また、パケットは常に時計回りに移動することに注意してください。パケットがリングのBFRのいずれかでリングに入ることを許可する場合、1つは2つのリングビット位置を使用する必要があります。1つは、時計回りと反時計回りです。
Both would be set up to stop rotating on the same link, e.g., L1. When the ring's BFIR creates the clockwise copy, it will clear the counterclockwise bit position because the DNC bit only applies to the bit for which the replication is done (likewise for the clockwise bit position for the counterclockwise copy). As a result, the ring's BFIR will send a copy in both directions, serving BFRs on either side of the ring up to L1.
どちらも同じリンク、例えばL1で回転するのを停止するように設定されます。リングのBFIRが時計回りのコピーを作成すると、DNCビットが複製が行われるビットにのみ適用されるため、反時計回りのビット位置がクリアされます（同様に、反時計回りのコピーの時計回りのビット位置に対して）。その結果、リングのBFIRは両方向にコピーを送信し、リングの両側にBFRをL1まで提供します。
An ECMP() adjacency allows the use of just one BP to deliver packets to one of N adjacencies instead of one BP for each adjacency. In the common example case shown in Figure 10, a link bundle of three links L1,L2,L3 connects BFR1 and BFR2, and only one BP is used instead of three BPs to deliver packets from BFR1 to BFR2.
ECMP（）隣接により、1つのBPのみを使用して、各隣接する1つのBPではなく、N隣接の1つにパケットを配信できます。図10に示す一般的な例では、3つのリンクL1、L2、L3のリンクバンドルがBFR1およびBFR2を接続し、BFR1からBFR2にパケットを配信するために3つのBPの代わりに1つのBPのみが使用されます。
--L1-----
BFR1 --L2----- BFR2
--L3-----
BIFT entry in BFR1:
------------------------------------------------------------------
| Index | Adjacencies |
==================================================================
| 0:6 | ECMP({forward_connected(L1, BFR2), |
| | forward_connected(L2, BFR2), |
| | forward_connected(L3, BFR2)}, seed) |
------------------------------------------------------------------
BIFT entry in BFR2:
------------------------------------------------------------------
| Index | Adjacencies |
==================================================================
| 0:6 | ECMP({forward_connected(L1, BFR1), |
| | forward_connected(L2, BFR1), |
| | forward_connected(L3, BFR1)}, seed) |
------------------------------------------------------------------
Figure 10: ECMP Example
図10：ECMPの例
This document does not standardize any ECMP algorithm because it is sufficient for implementations to document their freely chosen ECMP algorithm. Figure 11 shows an example ECMP algorithm and would double as its documentation: a BIER-TE controller could determine which adjacency is chosen based on the seed and adjacencies parameters and on packet entropy.
このドキュメントは、実装が自由に選択されたECMPアルゴリズムを文書化するのに十分であるため、ECMPアルゴリズムを標準化しません。図11は、ECMPアルゴリズムの例を示しており、そのドキュメントを兼ねます。ビアテコントローラーは、種子および隣接パラメーターとパケットエントロピーに基づいて選択される隣接を決定できます。
forward(packet, ECMP(adj(0), adj(1),... adj(N-1), seed)):
i = (packet(bier-header-entropy) XOR seed) % N
forward packet to adj(i)
Figure 11: ECMP Algorithm Example
図11：ECMPアルゴリズムの例
In the example shown in Figure 12, all traffic from BFR1 towards BFR10 is intended to be ECMP load-split equally across the topology. This example is not meant as a likely setup; rather, it illustrates that ECMP can be used to share BPs not only across link bundles but also across alternative paths across different transit BFRs, and it explains the use of the seed parameter.
図12に示す例では、BFR1からBFR10へのすべてのトラフィックは、トポロジ全体にわたってECMP負荷分散を等しく等しくスプリットすることを目的としています。この例は、可能性のあるセットアップとしての意味ではありません。むしろ、ECMPを使用して、リンクバンドル間だけでなく、異なるトランジットBFRの代替パス全体でBPSを共有できることを示しており、シードパラメーターの使用を説明しています。
BFR1 (BFIR)
/L11 \L12
/ \
BFR2 BFR3
/L21 \L22 /L31 \L32
/ \ / \
BFR4 BFR5 BFR6 BFR7
\ / \ /
\ / \ /
BFR8 BFR9
\ /
\ /
BFR10 (BFER)
BIFT entry in BFR1:
------------------------------------------------------------------
| 0:6 | ECMP({forward_connected(L11, BFR2), |
| | forward_connected(L12, BFR3)}, seed1) |
------------------------------------------------------------------
BIFT entry in BFR2:
------------------------------------------------------------------
| 0:7 | ECMP({forward_connected(L21, BFR4), |
| | forward_connected(L22, BFR5)}, seed1) |
------------------------------------------------------------------
BIFT entry in BFR3:
------------------------------------------------------------------
| 0:7 | ECMP({forward_connected(L31, BFR6), |
| | forward_connected(L32, BFR7)}, seed1) |
------------------------------------------------------------------
BIFT entry in BFR4, BFR5:
------------------------------------------------------------------
| 0:8 | forward_connected(Lxx, BFR8) |xx differs on BFR4/BFR5|
------------------------------------------------------------------
BIFT entry in BFR6, BFR7:
------------------------------------------------------------------
| 0:8 | forward_connected(Lxx, BFR9) |xx differs on BFR6/BFR7|
------------------------------------------------------------------
BIFT entry in BFR8, BFR9:
------------------------------------------------------------------
| 0:9 | forward_connected(Lxx, BFR10) |xx differs on BFR8/BFR9|
------------------------------------------------------------------
Figure 12: Polarization Example
図12：偏光の例
Note that for the following discussion of ECMP, only the BIFT ECMP() adjacencies on BFR1, BFR2, and BFR3 are relevant. The reuse of BPs across BFRs in this example is further explained in Section 5.1.9 below.
ECMPの以下の議論では、BFR1、BFR2、およびBFR3のBIFT ECMP（）隣接のみが関連していることに注意してください。この例でBFRを横切るBPSの再利用については、以下のセクション5.1.9でさらに説明しています。
With the ECMP setup shown in the topology above, traffic would not be equally load-split. Instead, links L22 and L31 would see no traffic at all: BFR2 will only see traffic from BFR1, for which the ECMP hash in BFR1 selected the first adjacency in the list of two adjacencies given as parameters to the ECMP: link L11-to-BFR2. BFR2 again performs ECMP with two adjacencies on that subset of traffic using the same seed1 and will therefore again select the first of its two adjacencies: L21-to-BFR4. Therefore, L22 and BFR5 see no traffic (likewise for L31 and BFR6).
上記のトポロジに示されているECMPセットアップでは、トラフィックは等しく負荷分散ではありません。代わりに、LINKS L22とL31にはトラフィックがまったく表示されません。BFR2にはBFR1からのトラフィックのみが表示されます。BFR1のECMPハッシュは、ECMPへのパラメーターとして与えられた2つの隣接のリストの最初の隣接を選択しました。BFR2。BFR2は、同じSEED1を使用してトラフィックのサブセットに2つの隣接を持つECMPを再度実行するため、2つの隣接の最初の隣接を再度選択します。L21-to-BFR4。したがって、L22とBFR5はトラフィックを見ません（L31およびBFR6も同様です）。
This issue in BFR2/BFR3 is called "polarization". It results from the reuse of the same hash function across multiple consecutive hops in topologies like these. To resolve this issue, the ECMP() adjacency on BFR1 can be set up with a different seed2 than the ECMP() adjacencies on BFR2/BFR3. BFR2/BFR3 can use the same hash because packets will not sequentially pass across both of them. Therefore, they can also use the same BP (i.e., 0:7).
BFR2/BFR3でのこの問題は、「偏光」と呼ばれます。このようなトポロジーの複数の連続したホップにまたがる同じハッシュ関数の再利用に起因します。この問題を解決するために、BFR1のECMP（）隣接は、BFR2/BFR3のECMP（）隣接とは異なるSeed2でセットアップできます。BFR2/BFR3は、パケットが両方のハッシュを順番に通過しないため、同じハッシュを使用できます。したがって、同じBP（つまり、0：7）を使用することもできます。
Note that ECMP solutions outside of BIER often hide the seed by auto-selecting it from local entropy such as unique local or next-hop identifiers. Allowing the BIER-TE controller to explicitly set the seed gives the BIER-TE controller the ability to control the selection of the same path or different paths across multiple consecutive ECMP hops.
ビアの外側のECMPソリューションは、ユニークなローカルまたはネクストホップ識別子などのローカルエントロピーから自動選択することにより、種子を隠すことが多いことに注意してください。Bierteコントローラーがシードを明示的に設定できるようにすると、Bier-TEコントローラーが複数の連続したECMPホップにまたがる同じパスまたは異なるパスの選択を制御する機能を提供します。
Forward_routed() adjacencies can reduce the number of bit positions required when the path steering requirement is not hop-by-hop explicit path selection but rather is loose-hop selection. Forward_routed() adjacencies can also permit BIER-TE operation across intermediate-hop routers that do not support BIER-TE.
Forward_Routed（）隣接は、パスステアリング要件がHop-By-Hopの明示的なパスの選択ではなく、ルーズホップ選択である場合に必要なビット位置の数を減らすことができます。Forward_Routed（）隣接は、BierTEをサポートしていない中間ホップルーター全体でビアテ操作を可能にすることもできます。
Assume that the requirement in Figure 13 is to explicitly steer traffic flows that have arrived at BFR1 or BFR4 via a path in the routing underlay "Network Area 1" to one of the following next three segments: (1) BFR2 via link L1, (2) BFR2 via link L2, or (3) via BFR3 and then not caring whether the packet is forwarded via L3 or L4.
図13の要件は、次の3つのセグメントのいずれかに、ルーティングアンダーレイ「ネットワークエリア1」のパスを介してBFR1またはBFR4に到達したトラフィックフローを明示的に操縦することであると仮定します。2）Link L2を介してBFR2、または（3）BFR3を介して、その後、パケットがL3またはL4を介して転送されるかどうかを気にしません。
...............
...BFR1--... ...--L1-- BFR2...
... .Routers. ...--L2--/
...BFR4--... ...--L3-- BFR3...
... ...--L4--/ |
............... |
LO
Network Area 1
Figure 13: Forward Routed Adjacencies Example
図13：フォワードルーティングされた隣接の例
To enable this, both BFR1 and BFR4 are set up with a forward_routed() adjacency bit position towards an address of BFR2 on link L1, another forward_routed() bit position towards an address of BFR2 on link L2, and a third forward_routed() bit position towards a node address LO of BFR3.
これを有効にするために、bfr1とbfr4の両方が、link l1のbfr2のアドレスに向かってforward_routed（）隣接ビットの位置でセットアップされ、別のforward_routed（）ビット位置はリンクl2上のbfr2のアドレスに向かって、3番目のworward_routed（）ビットBFR3のノードアドレスLOに向けて位置。
Forward_routed() adjacencies also enable incremental deployment of BIER-TE. Only the nodes through which BIER-TE traffic needs to be steered -- with or without replication -- need to support BIER-TE. Where they are not directly connected to each other, forward_routed() adjacencies are used to pass over nodes that are not BIER-TE enabled.
Forward_Routed（）隣接は、BierTEの増分展開も可能にします。ビアテトラフィックを操縦する必要があるノードのみ - 複製の有無にかかわらず、ビアテをサポートする必要があります。それらが互いに直接接続されていない場合、forward_routed（）隣接は、ビアテが有効になっていないノードを渡すために使用されます。
BPs can be reused across multiple BFRs to minimize the number of BPs needed. This happens when adjacencies on multiple BFRs use the DNC flag as described above, but it can also be done for non-DNC adjacencies. This section only discusses this non-DNC case.
BPSを複数のBFRで再利用して、必要なBPの数を最小限に抑えることができます。これは、複数のBFRの隣接が上記のDNCフラグを使用している場合に発生しますが、非DNC隣接に対しても実行できます。このセクションでは、この非DNCケースのみについて説明します。
Because a given BP is cleared when passing a BFR with an adjacency for that BP, reusing BPs across multiple BFRs does not introduce any problems with duplicates or loops that do not also exist when every adjacency has a unique BP. Instead, the challenge when reusing BPs is whether the desired Tree Engineering goals can still be achieved.
そのBPの隣接するBFRを渡すときに特定のBPがクリアされるため、複数のBFRにわたってBPを再利用しても、すべての隣接が一意のBPを持っているときに存在しない複製またはループに問題は導入されません。代わりに、BPSを再利用する際の課題は、望ましいツリーエンジニアリングの目標を達成できるかどうかです。
A BP cannot be reused across two BFRs that would need to be passed sequentially for some path: the first BFR will clear the BP, so those paths cannot be built. A BP can be set across BFRs that would only occur across (A) different paths or (B) different branches of the same tree.
BPは、何らかのパスのために連続的に渡す必要がある2つのBFRで再利用できません。最初のBFRはBPをクリアするため、それらのパスを構築できません。BPは、（a）異なるパスまたは（b）同じツリーの異なる枝全体でのみ発生するBFRに設定できます。
An example of (A) was given in Figure 12, where BP 0:7, BP 0:8, and BP 0:9 are each reused across multiple BFRs because a single packet/ path would never be able to reach more than one BFR sharing the same BP.
（a）の例が図12に示されています。ここでは、BP 0：7、BP 0：8、およびBP 0：9がそれぞれ複数のBFRで再利用されています。同じBPを共有します。
Assume that the example was changed: BFR1 has no ECMP() adjacency for BP 0:6 but instead has BP 0:5 with forward_connected() to BFR2 and BP 0:6 with forward_connected() to BFR3. Packets with both BP 0:5 and BP 0:6 would now be able to reach both BFR2 and BFR3, and the still-existing reuse of BP 0:7 between BFR2 and BFR3 is a case of (B) where reusing a BP is perfect because it does not limit the set of useful path choices, as in the following example.
例が変更されたと仮定します。BFR1には、BP 0：6のECMP（）隣接はありませんが、代わりにbp 0：5をbfr2に、bp 0：6を使用してbp 0：6を使用して、forward_connected（）をbfr3にします。BP 0：5とBP 0：6の両方を持つパケットは、BFR2とBFR3の両方に到達できるようになり、BP 0：7のまだ存在している再利用は、BPの再利用がBPの場合です。次の例のように、有用なパスの選択のセットを制限しないため、完璧です。
If instead of reusing BP 0:7 BFR3 used a separate BP 0:10 for its ECMP() adjacency, no useful additional path steering options would be enabled. If duplicates at BFR10 were undesirable, this would be done by not setting BP 0:5 and BP 0:6 for the same packet. If the duplicates were desirable (e.g., resilient transmission), the additional BP 0:10 would also not render additional value.
BP 0：7 BFR3を再利用する代わりに、ECMP（）隣接に個別のBP 0:10を使用した場合、有用な追加パスステアリングオプションは有効になりません。BFR10の複製が望ましくない場合、これは同じパケットに対してBP 0：5およびBP 0：6を設定しないことで行われます。複製が望ましい場合（例：回復力のある伝送）、追加のBP 0:10も追加値をレンダリングしません。
Reuse may also save BPs in larger topologies. Consider the topology shown in Figure 14.
再利用は、より大きなトポロジーでBPSを節約することもできます。図14に示すトポロジを考えてみましょう。
area1
BFR1a BFR1b
/ \
....................................
. Core .
....................................
| / \ / \ |
BFR2a BFR2b BFR3a BFR3b BFR6a BFR6b
/-------\ /---------\ /--------\
| area2 | | area3 | ... | area6 |
| ring | | ring | | ring |
\-------/ \---------/ \--------/
more BFRs more BFRs more BFRs
Figure 14: Reuse of BPs
図14：BPSの再利用
A BFIR/sender (e.g., video headend) is attached to area 1, and the five areas 2...6 contain receivers/BFERs. Assume that each area has a distribution ring, each with two BPs to indicate the direction (as explained before). These two BPs could be reused across the five areas. Packets would be replicated through other BPs from the core to the desired subset of areas, and once a packet copy reaches the ring of the area, the two ring BPs come into play. This reuse is a case of (B), but it limits the topology choices: packets can only flow around the same direction in the rings of all areas. This may or may not be acceptable based on the desired path steering options: if resilient transmission is the path engineering goal, then it is likely a good optimization; however, if the bandwidth of each ring were to be optimized separately, it would not be a good limitation.
BFIR/送信者（ビデオヘッドエンドなど）がエリア1に接続され、5つのエリア2 ... 6にはレシーバー/BFERが含まれています。各領域には配布リングがあり、それぞれが方向を示すために2つのbpsを持つと仮定します（前に説明したように）。これらの2つのBPは、5つの領域で再利用できます。パケットは、コアからエリアの目的のサブセットまで他のBPを介して複製され、パケットコピーがエリアのリングに到達すると、2つのリングBPが作用します。この再利用は（b）の場合ですが、トポロジの選択を制限します。パケットは、すべての領域のリングで同じ方向にのみ流れることができます。これは、目的のパスステアリングオプションに基づいて受け入れられる場合とそうでない場合があります。回復力のある送信がパスエンジニアリングの目標である場合、おそらく最適化である可能性があります。ただし、各リングの帯域幅が個別に最適化される場合、それは良い制限ではありません。
In this section, we reviewed a range of techniques by which a BIER-TE controller can create a BIER-TE topology in a way that minimizes the number of necessary BPs.
このセクションでは、必要なBPの数を最小限に抑える方法でビアテのトポロジを作成できるさまざまな手法を確認しました。
Without any optimization, a BIER-TE controller would attempt to map the network subnet topology 1:1 into the BIER-TE topology, every adjacent neighbor in the subnet would require a forward_connected() BP, and every BFER would require a local_decap() BP.
最適化がなければ、BierTEコントローラーはネットワークサブネットトポロジ1：1をBierTTEトポロジにマッピングしようとします。サブネットのすべての隣接する近隣はForward_Connected（）BPを必要とし、すべてのBFERにはlocal_decap（）が必要になります。BP。
The optimizations described in this document are then as follows:
このドキュメントで説明されている最適化は次のとおりです。
1. P2P links require only one BP (Section 5.1.1).
1. P2Pリンクには1つのBPのみが必要です（セクション5.1.1）。
2. All leaf BFERs can share a single local_decap() BP (Section 5.1.3).
2. すべてのリーフBFERSは、単一のlocal_decap（）bp（セクション5.1.3）を共有できます。
3. A LAN with N BFRs needs at most N BPs (one for each BFR). It only needs one BP for all those BFRs that are not redundantly connected to multiple LANs (Section 5.1.4).
3. N BFRを備えたLANは、ほとんどのN BPS（各BFRに1つ）で必要です。複数のLANに冗長に接続されていないすべてのBFRに対して1つのBPのみが必要です（セクション5.1.4）。
4. A hub with P2P connections to multiple non-leaf BFER spokes can share one BP with all of the spokes if traffic can be flooded to all of those spokes, e.g., because of no bandwidth concerns or dense receiver sets (Section 5.1.5).
4. 複数の非葉のBFERスポークへのP2P接続を備えたハブは、帯域幅の懸念や密度の高いレシーバーセットのために、これらすべてのスポークにトラフィックを浸水させることができる場合、すべてのスポークと1つのBPを共有できます（セクション5.1.5）。
5. Rings of BFRs can be built with just two BPs (one for each direction), except for BFRs with multiple ring connections -- similar to LANs (Section 5.1.6).
5. BFRのリングは、LANと同様の複数のリング接続を持つBFRを除き、2つのBPS（1つの方向に1つ）で構築できます（セクション5.1.6）。
6. ECMP() adjacencies to N neighbors can replace N BPs with one BP. Multihop ECMP can avoid polarization through different seeds of the ECMP algorithm (Section 5.1.7).
6. n nighborsへのecmp（）隣接は、N BPを1つのBPに置き換えることができます。MultiHOP ECMPは、ECMPアルゴリズムのさまざまな種子による偏光を回避できます（セクション5.1.7）。
7. Forward_routed() adjacencies permit "tunneling" across routers that are either BIER-TE capable or not BIER-TE capable where no traffic steering or replications are required (Section 5.1.8).
7. Forward_Routed（）隣接により、トラフィックステアリングや複製が不要な場合、ビアテが能力があるか、biertteではないルーターを横切る「トンネル」が許可されます（セクション5.1.8）。
8. A BP can generally be reused across a set of nodes where it can be guaranteed that no path will ever need to traverse more than one node of the set. Depending on the scenario, this may limit the feasible path steering options (Section 5.1.9).
8. 通常、BPは、セットの複数のノードを通過するパスが必要ないことを保証できる一連のノード全体で再利用できます。シナリオに応じて、これにより、実行可能なパスステアリングオプションが制限される場合があります（セクション5.1.9）。
Note that this list of optimizations is not exhaustive. Further optimizations of BPs are possible, especially when both the set of required path steering choices and the possible subsets of BFERs that should be able to receive traffic are limited. The hub-and-spoke optimization is a simple example of such traffic-pattern-dependent optimizations.
この最適化のリストは網羅的ではないことに注意してください。特に、必要なパスステアリングの選択肢のセットとトラフィックを受け取ることができるBFERの可能なサブセットの両方が限られている場合、BPSのさらなる最適化が可能です。ハブアンドスポークの最適化は、このようなトラフィックパターン依存の最適化の簡単な例です。
Whenever BIER-TE creates a copy of a packet, the BitString of that copy will have all bit positions cleared that are associated with adjacencies on the BFR. This prevents packets from looping. The only exceptions are adjacencies with DNC set.
BierTEがパケットのコピーを作成するたびに、そのコピーのビットストリングには、BFRの隣接に関連するすべてのビットポジションがクリアされます。これにより、パケットがループできなくなります。唯一の例外は、DNCセットの隣接です。
With DNC set, looping can happen. Consider in Figure 15 that link L4 from BFR3 is (inadvertently) plugged into the L1 interface of BFRa (instead of BFR2). This creates a loop where the ring's clockwise bit position is never cleared for copies of the packets traveling clockwise around the ring.
DNCセットを使用すると、ループが発生する可能性があります。図15では、BFR3のL4が（不注意に）BFRAのL1インターフェイス（BFR2の代わりに）に接続されていることを考えてください。これにより、リングの周りを時計回りに移動するパケットのコピーに対して、リングの時計回りのビット位置がクリアされないループが作成されます。
v v
| |
L1 | L2 | L3
/-------- BFRa ---- BFRb ---------------------\
| . |
| ...... Wrong link wiring |
| . |
\- BFR1 - BFR2 BFR3 - ... - BFR29 - BFR30 -/
| | L4 | |
p33| p15|
BFRd BFRc
Figure 15: Miswired Ring Example
図15：配線のリングの例
To inhibit looping in the face of such physical misconfiguration, only forward_connected() adjacencies are permitted to have DNC set, and the link layer port unique unicast destination address of the adjacency (e.g., "Media Access Control" (MAC) address) protects against closing the loop. Link layers without port unique link layer addresses should not be used with the DNC flag set.
このような物理的な誤解に直面してループを阻害するために、forward_connected（）隣接のみがDNCセットを持つことが許可され、リンクレイヤーポート隣接するユニークなユニキャスト宛先アドレス（例：「メディアアクセス制御」（MAC）アドレス）が保護します。ループを閉じます。ポートなしのリンクレイヤー一意のリンクレイヤーアドレスは、DNCフラグセットでは使用しないでください。
Duplicates happen when the graph expressed by a BitString is not a tree but is redundantly connecting BFRs with each other. In Figure 16, a BitString of p2,p3,p4,p5 would result in duplicate packets arriving on BFER4. The BIER-TE controller must therefore ensure that only BitStrings that are trees are created.
複製は、ビットストリングによって表されたグラフが木ではなく、BFRを互いに冗長に接続している場合に発生します。図16では、p2、p3、p4、p5のビットストリングにより、Bfer4に到着するパケットが重複します。したがって、Bierteコントローラーは、木であるビットストリングのみが作成されるようにする必要があります。
BFIR1
/ \
/ p2 \ p3
BFR2 BFR3
\ p4 / p5
\ /
BFER4
Figure 16: Duplicates Example
図16：複製の例
When links are incorrectly physically reconnected before the BIER-TE controller updates BitStrings in BFIRs, duplicates can happen. Like loops, these can be inhibited by link layer addressing in forward_connected() adjacencies.
Bier-TEコントローラーがBFIRSでビットストリングを更新する前に、リンクが誤って物理的に再接続されている場合、重複が発生する可能性があります。ループと同様に、これらは、forward_connected（）隣接する（）隣接するリンクレイヤーアドレス指定によって阻害できます。
If interface or loopback addresses used in forward_routed() adjacencies are moved from one BFR to another, duplicates are equally likely to happen. Such readdressing operations must be coordinated with the BIER-TE controller.
forward_routed（）で使用されているインターフェイスまたはループバックアドレスが、あるbfrから別のbfrに移動される場合、重複が等しく発生する可能性があります。このような再生操作は、Bier-TEコントローラーと調整する必要があります。
When the number of bits required to represent the necessary hops in the topology and BFERs exceeds the supported "BitStringLength" (BSL), multiple SIs and/or subdomains must be used. This section discusses how this is done.
トポロジに必要なホップを表すために必要なビットの数とBFERSがサポートされている「ビットストリングレングス」（BSL）を超える場合、複数のSISおよび/またはサブドメインを使用する必要があります。このセクションでは、これがどのように行われるかについて説明します。
BIER-TE forwarding does not require the concept of BFR-ids, but routing underlay, flow overlay, and BIER headers may. This section also discusses how BFR-ids can be assigned to BFIRs/BFERs for BIER-TE.
Bier-TEの転送では、BFR-IDの概念を必要とせず、ルーティングアンダーレイ、フローオーバーレイ、およびビアヘッダーが可能にします。また、このセクションでは、BIRTTEのBFIRS/BFERSにBFR-IDをどのように割り当てることができるかについても説明します。
For (non-TE) BIER and BIER-TE forwarding, the most important result of using multiple SIs and/or subdomains is the same: multicast flow overlay packets that need to be sent to BFERs in different SIs or subdomains require multiple BIER packets, each one with a BitString for a different (SI,subdomain) combination. Each such BitString uses one BSL-sized SI block in the BIFT of the subdomain. We call this a BIFT:SI (block).
（非）ビアとビアテの転送の場合、複数のSISおよび/またはサブドメインを使用することの最も重要な結果は同じです。異なるSISまたはサブドメインでBFERに送信する必要があるマルチキャストフローオーバーレイパケットは、複数のビアパケットを必要とします。それぞれが別の（SI、サブドメイン）組み合わせのためのビットストリングを備えています。このようなビットストリングはそれぞれ、サブドメインのビフトで1つのBSLサイズのSIブロックを使用します。これをbift：si（block）と呼びます。
SIs and subdomains have different purposes in the BIER architecture and also the BIER-TE architecture. This impacts how operators manage them and especially how flow overlays will likely use them.
sisとサブドメインは、ビアアーキテクチャとビアテアーキテクチャに異なる目的を持っています。これは、オペレーターがそれらをどのように管理するか、特にフローオーバーレイがそれらを使用する可能性が高いことに影響します。
By default, every possible BFIR/BFER in a BIER network would likely be given a BFR-id in subdomain 0 (unless there are > 64k BFIRs/ BFERs).
デフォルトでは、Bierネットワーク内のすべての可能なBFIR/ BFERには、サブドメイン0にBFR-IDが与えられる可能性があります（64K BFIRS/ BFERSがない限り）。
If there are different flow services (or service instances) requiring replication to different subsets of BFERs, then it will likely not be possible to achieve the best replication efficiency for all of these service instances via subdomain 0. Ideal replication efficiency for N BFERs exists in a subdomain if they are split over no more than ceiling(N/BitStringLength) SIs.
さまざまなフローサービス（またはサービスインスタンス）がBFERの異なるサブセットに複製を必要とする場合、サブドメイン0を介してこれらすべてのサービスインスタンスに最適な複製効率を達成することはできない可能性があります。サブドメインは、天井（n/bitstringlength）sis以上に分割されている場合。
If service instances justify additional BIER:SI state in the network, additional subdomains will be used: BFIRs/BFERs are assigned BFR-ids in those subdomains, and each service instance is configured to use the most appropriate subdomain. This results in improved replication efficiency for different services.
サービスインスタンスが追加のビアを正当化する場合：ネットワーク内のSI状態、追加のサブドメインが使用されます：BFIRS/BFERSはそれらのサブドメインにBFR-IDを割り当てられ、各サービスインスタンスは最も適切なサブドメインを使用するように構成されています。これにより、さまざまなサービスの複製効率が向上します。
Even if creation of subdomains and assignment of BFR-ids to BFIRs/ BFERs in those subdomains is automated, it is not expected that individual service instances can deal with BFERs in different subdomains. A service instance may only support configuration of a single subdomain it should rely on.
サブドメインの作成とそれらのサブドメインのBFIRS/ BFERへのBFR-IDの割り当てが自動化されたとしても、個々のサービスインスタンスが異なるサブドメインのBFERに対処できることは予想されません。サービスインスタンスは、依存する必要のある単一のサブドメインの構成のみをサポートする場合があります。
To be able to easily reuse (and modify as little as possible) existing BIER procedures (including flow overlay and routing underlay), when BIER-TE forwarding is added, we therefore reuse SIs and subdomains logically in the same way as they are used in BIER: all necessary BFIRs/BFERs for a service use a single BIER-TE BIFT and are split across as many SIs as necessary (see Section 5.3.2). Different services may use different subdomains that primarily exist to provide more efficient replication (and, for BIER-TE, desirable path steering) for different subsets of BFIRs/BFERs.
既存のビアプロシージャ（フローオーバーレイやルーティングアンダーレイを含む）を簡単に再利用する（可能な限り少ない）できるように、ビアテ転送が追加されたら、sisとサブドメインが使用されるのと同じ方法で論理的に再利用されます。ビア：サービスに必要なすべてのBFIR/BFERSは、単一のビアテビフトを使用し、必要な数のSISに分割されます（セクション5.3.2を参照）。さまざまなサービスが、主に存在する異なるサブドメインを使用して、BFIR/BFERのさまざまなサブセットに、より効率的な複製（およびビアテの場合、望ましいパスステアリング）を提供する場合があります。
In BIER, BitStrings only need to carry bits for BFERs; this leads to the model where BFR-ids map 1:1 to each bit in a BitString.
Bierでは、ビットストリングスはBferにビットを運ぶだけです。これにより、BFR-IDSがビットストリングの各ビットに1：1をマップするモデルにつながります。
In BIER-TE, BitStrings need to carry bits to indicate not only the receiving BFER but also the intermediate hops/links across which the packet must be sent. The maximum number of BFERs that can be supported in a single BitString or BIFT:SI depends on the number of bits necessary to represent the desired topology between them.
BierTeでは、BitStringsは、受信BFERだけでなく、パケットを送信する必要がある中間ホップ/リンクを示すためにビットを運ぶ必要があります。単一のビットストリングまたはビフトでサポートできる最大数のBFER：SIは、それらの間の望ましいトポロジを表すために必要なビットの数に依存します。
"Desired" topology means that it depends on the physical topology and the operator's desire to
「望ましい」トポロジは、それが物理的なトポロジとオペレーターの欲求に依存することを意味します
1. permit explicit path steering across every single hop (which requires more bits), or
1. すべてのホップ（より多くのビットが必要です）を介して明示的なパスステアリングを許可します。
2. reduce the number of required bits by exploiting optimizations such as unicast (forward_routed()), ECMP(), or flood (DNC) over "uninteresting" sub-parts of the topology, e.g., parts where, for path steering reasons, different trees do not need to take different paths.
2. Unicast（Forward_Routed（））、ECMP（）、または洪水（DNC）などの最適化を活用することにより、トポロジーの「面白くない」サブパート、たとえばパスステアリングの理由で、異なるツリーの場合に必要なビットの数を減らすことにより別のパスをとる必要はありません。
The total number of bits to describe the topology vs. the number of BFERs in a BIFT:SI can range widely based on the size of the topology and the amount of alternative paths in it. In a BIER-TE topology crafted by a BIER-TE expert, the higher the percentage of non-BFER bits, the higher the likelihood that those topology bits are not just BIER-TE overhead without additional benefit but instead will allow the expression of desirable path steering alternatives.
トポロジを記述するビットの総数とビフトのbferの数：Siは、トポロジのサイズとその中の代替パスの量に基づいて広く範囲にできます。ビアテの専門家によって作られたビアテポロジーでは、非bファービットの割合が高くなるほど、それらのトポロジービットが追加の利点がないだけでなく、望ましいものの表現を可能にする可能性が高くなりますパスステアリングの代替品。
BIER-TE forwarding does not use BFR-ids, nor does it require that the BFIR-id field of the BIER header be set to a particular value. However, other parts of a BIER-TE deployment may need a BFR-id -- specifically, multicast flow overlay signaling and multicast flow overlay packet disposition; in that case, BFRs need to also have BFR-ids for BIER-TE SDs.
BierTTE転送はBFR-IDを使用しておらず、BierヘッダーのBFIR-IDフィールドを特定の値に設定する必要もありません。ただし、BierTTE展開の他の部分には、BFR-ID、特にマルチキャストフローオーバーレイシグナリングとマルチキャストフローオーバーレイパケット処分が必要になる場合があります。その場合、BFRはBier-TE SDS用のBFR-IDも持っている必要があります。
For example, for BIER overlay signaling, BFIRs need to have a BFR-id, because this BFIR BFR-id is carried in the BFIR-id field of the BIER header to indicate to the overlay signaling on the receiving BFER which BFIR originated the packet.
たとえば、Bier Overlay Signalingの場合、BFIRはBFR-IDを使用する必要があります。これは、BFIRヘッダーのBFIR-IDフィールドに運ばれて、BFIRがパケットを発信した受信BFerのオーバーレイシグナル伝達を示すためです。。
In BIER, BFR-id = SI * BSL + BP, such that the SI and BP of a BFER can be calculated from the BFR-id and vice versa. This also means that every BFR with a BFR-id has a reserved BP in an SI, even if that is not necessary for BIER forwarding, because the BFR may never be a BFER (i.e., will only be a BFIR).
Bierでは、BFR-ID = Si * BSL BPでは、BFREのSiとBPをBFR-IDから計算し、その逆も同様です。これはまた、BFRがBFRではない可能性があるため（つまり、BFIRのみであるため）、BFR-IDを持つすべてのBFRがSIに予約されたBPを持っていることを意味します。
In BIER-TE, for a non-leaf BFER, there is usually a single BP for that BFER with a local_decap() adjacency on the BFER. The BFR-id for such a BFER can therefore be determined using the same procedure as that used for (non-TE) BIER: BFR-id = SI * BSL + BP.
BierTEでは、非葉のBFerの場合、通常、BFERのlocal_decap（）隣接を備えたそのbferには単一のBPがあります。したがって、このようなBFerのBFR-IDは、（非）ビアに使用されるものと同じ手順を使用して決定できます：BFR-ID = SI * BSL BP。
As explained in Section 5.1.3, leaf BFERs do not need such a unique local_decap() adjacency. Likewise, BFIRs that are not also BFERs may not have a unique local_decap() adjacency either. For all those BFIRs and (leaf) BFERs, the controller needs to determine unique BFR-ids that do not collide with the BFR-ids derived from the non-leaf BFER local_decap() BPs.
セクション5.1.3で説明したように、Leaf Bfersはこのような一意のlocal_decap（）隣接を必要としません。同様に、BFERSではないBFIRは、一意のlocal_decap（）隣接も持っていない場合があります。これらすべてのBFIRおよび（葉）BFERについて、コントローラーは、非葉のBFER Local_Decap（）BPSから派生したBFR-IDと衝突しない一意のBFR-IDを決定する必要があります。
While this document defines no requirements on how to allocate such BFR-ids, a simple option is to derive it from the (SI,BP) of an adjacency that is unique to the BFR in question. For a BFIR, this can be the first adjacency that is only populated on this BFIR; for a leaf BFER, this could be the first BP with an adjacency towards that BFER.
このドキュメントでは、このようなBFR-IDを割り当てる方法に関する要件は定義されていませんが、簡単なオプションは、問題のBFRに固有の隣接能力の（SI、BP）から導出することです。BFIRの場合、これはこのBFIRにのみ存在する最初の隣接になる可能性があります。葉のbferの場合、これはそのbferに隣接する最初のBPになる可能性があります。
In BIER, applications of the flow overlay on a BFIR can calculate the (SI,BP) of a BFER from the BFR-id of the BFER and can therefore easily determine the BitStrings for a BIER packet to a set of BFERs with known BFR-ids.
ビアでは、BFIRでのフローオーバーレイのアプリケーションは、BFerのBFR-IDからBFREの（Si、BP）を計算することができ、したがって、既知のBFRを持つBFERのセットへのビアパケットのビットストリングを簡単に決定できます。IDS。
In BIER-TE, this mapping needs to be equally supported for flow overlays. This section outlines two core options, based on what type of Tree Engineering the BIER-TE controller needs to perform for a particular application.
BierTEでは、このマッピングをフローオーバーレイで等しくサポートする必要があります。このセクションでは、特定のアプリケーションで実行するためにビアテコントローラーが必要とするツリーエンジニアリングの種類に基づいて、2つのコアオプションの概要を説明します。
"Independent branches": For a given flow overlay instance, the branches from a BFIR to every BFER are calculated by the BIER-TE controller to be independent of the branches to any other BFER. Shortest path trees are the most common examples of trees with independent branches.
「Independent Branches」：特定のフローオーバーレイインスタンスの場合、BFIRからすべてのBFERへの分岐は、Bier-TEコントローラーによって計算され、他のBFERに分岐から独立しています。最短経路の木は、独立した枝を持つ木の最も一般的な例です。
"Interdependent branches": When a BFER is added to or deleted from a particular distribution tree, the BIER-TE controller has to recalculate the branches to other BFERs, because they may need to change. Steiner trees are examples of interdependent branch trees.
「相互依存の枝」：特定の分布ツリーにBFERが追加または削除された場合、Bier-TEコントローラーは、変更が必要になる可能性があるため、分岐を他のBFERに再計算する必要があります。シュタイナーの木は、相互依存の枝の木の例です。
If "independent branches" are used, the BIER-TE controller can signal to the BFIR flow overlay for every BFER an SI:BitString that represents the branch to that BFER. The flow overlay on the BFIR can then, independently of the controller, calculate the SI:BitString for all desired BFERs by ORing their BitStrings. This allows flow overlay applications to operate independently of the controller whenever they need to determine which subset of BFERs needs to receive a particular packet.
「独立したブランチ」が使用される場合、Bier-TEコントローラーは、そのbferのブランチを表すsi：biTStringのすべてのBfirフローオーバーレイに信号を送信できます。BFIR上のフローオーバーレイは、コントローラーとは無関係に、ビットストリングを削ることにより、すべての望ましいBFERのSI：BitStringを計算できます。これにより、フローオーバーレイアプリケーションは、特定のパケットを受信するために必要なBFERのサブセットを決定する必要がある場合はいつでも、コントローラーとは独立して動作できます。
If "interdependent branches" are required, an application would need to query the SI:BitString for a given set of BFERs whenever the set changes.
「相互依存のブランチ」が必要な場合、アプリケーションは、セットが変更されるたびに、特定のBFERSセットのSI：BitStringを照会する必要があります。
Note that in either case (unlike the scenario for BIER), the bits may need to change upon link/node failure/recovery, network expansion, or network resource consumption by other traffic as part of achieving Traffic Engineering goals (e.g., reoptimization of lower-priority traffic flows). Interactions between such BFIR applications and the BIER-TE controller do therefore need to support dynamic updates to the SIs:BitStrings.
どちらの場合でも（ビアのシナリオとは異なります）、トラフィックエンジニアリングの目標を達成するための一環として、他のトラフィックによるリンク/ノードの障害/回復、ネットワーク拡張、またはネットワークリソースの消費時にビットが変更する必要がある場合があります（例：低いものの再オプチミー化 - プリアリティトラフィックフロー）。したがって、このようなBFIRアプリケーションとBier-TEコントローラー間の相互作用は、SIS：BitStringsの動的な更新をサポートする必要があります。
Communications between the BFIR flow overlay and the BIER-TE controller require some way to identify the BFERs. If BFR-ids are used in the deployment, as outlined in Section 5.3.3, then those are the "natural" BFR-ids. If BFR-ids are not used, then any other unique identifier, such as a BFR's BFR-prefix [RFC8279], could be used.
BFIRフローオーバーレイとBierTTEコントローラーの間の通信には、BFERを識別する何らかの方法が必要です。セクション5.3.3で概説されているように、展開でBFR-IDが使用されている場合、それらは「自然な」BFR-IDです。BFR-IDを使用しない場合、BFRのBFR-Prefix [RFC8279]などの他の一意の識別子を使用できます。
It is not currently determined if a single subdomain could or should be allowed to forward both (non-TE) BIER and BIER-TE packets. If this should be supported, there are two options:
現在、単一のサブドメインが（非）ビアとビアテの両方のパケットの両方を転送できるかどうかは決定されていません。これをサポートする必要がある場合、2つのオプションがあります。
A. BIER and BIER-TE have different BFR-ids in the same subdomain. This allows higher replication efficiency for BIER because the BIER BFR-ids can be assigned sequentially, while the BitStrings for BIER-TE will also have to assign the additional bits for the topology adjacencies. There is no relationship between a BFR BIER BFR-id and its BIER-TE BFR-id.
A.ビアとビアテは、同じサブドメインに異なるBFR-IDを持っています。これにより、Bier BFR-IDを連続的に割り当てることができるため、Bierの複製効率が高くなりますが、BierTeのBitStringsはトポロジ隣接に追加のビットを割り当てる必要があります。BFR Bier BFR-IDとそのビアテBFR-IDの間に関係はありません。
B. BIER and BIER-TE share the same BFR-id. The BFR-ids are assigned as explained above for BIER-TE and simply reused for BIER. The replication efficiency for BIER will be as low as that for BIER-TE in this approach.
B.ビアとビアテは、同じBFR-IDを共有します。BFR-IDは、上記で説明されているようにBierTTEの場合に割り当てられ、Bierのために単純に再利用されます。このアプローチでは、Bierの複製効率と同じくらい低くなります。
Consider a network setup with a BSL of 256 for a network topology as shown in Figure 17. The network has six areas, each with 170 BFERs, connecting via a core with four (core) BFRs. To address all BFERs with BIER, four SIs are required. To send a BIER packet to all BFERs in the network, four copies need to be sent by the BFIR. On the BFIR, it does not matter how the BFR-ids are allocated to BFERs in the network, but it does matter for efficiency further down in the network.
図17に示すように、ネットワークトポロジの256のBSLを備えたネットワークセットアップを検討してください。ネットワークには6つの領域があり、それぞれ170のbferがあり、コアを介して4つ（コア）BFRと接続します。Bierを使用してすべてのbferに対処するには、4つのsisが必要です。ネットワーク内のすべてのBFERにビアパケットを送信するには、BFIRから4つのコピーを送信する必要があります。BFIRでは、BFR-IDがネットワーク内のBFERSにどのように割り当てられるかは関係ありませんが、ネットワークでさらに効率を上げることは重要です。
area1 area2 area3
BFR1a BFR1b BFR2a BFR2b BFR3a BFR3b
| \ / \ / |
................................
. Core .
................................
| / \ / \ |
BFR4a BFR4b BFR5a BFR5b BFR6a BFR6b
area4 area5 area6
Figure 17: Scaling BIER-TE Bits by Reuse
図17：再利用によるスケーリングバイアテビット
With random allocation of BFR-ids to BFERs, each receiving area would (most likely) have to receive all four copies of the BIER packet because there would be BFR-ids for each of the four SIs in each of the areas. Only further towards each BFER would this duplication subside -- when each of the four trees runs out of branches.
BFR-IDをBFERSにランダムに割り当てると、各受信エリアは、各エリアの4つのSISのそれぞれにBFR-IDがあるため、ビアパケットの4つのコピーすべてを（ほとんど）受信する必要があります。各bferに向かってさらにさらに重複が沈むでしょう - 4つの木のそれぞれが枝から駆け落ちするとき。
If BFR-ids are allocated intelligently, then all the BFERs in an area would be given BFR-ids with as few different SIs as possible. Each area would only have to forward one or two packets instead of four.
BFR-IDがインテリジェントに割り当てられている場合、エリア内のすべてのBFERには、可能な限り少ないSISでBFR-IDが与えられます。各領域は、4つではなく1つまたは2つのパケットを転送するだけです。
Given how networks can grow over time, replication efficiency in an area will then also go down over time when BFR-ids are only allocated sequentially, network wide. An area that initially only has BFR-ids in one SI might end up with many SIs over a longer period of growth. Allocating SIs to areas that initially have sufficiently many spare bits for growth can help alleviate this issue. Alternatively, BFERs can be renumbered after network expansion. In this example, one may consider using six SIs and assigning one to each area.
ネットワークが時間の経過とともに成長する方法を考えると、BFR-IDが順次順番に割り当てられている場合に、エリアでの複製効率も時間とともに低下します。最初は1つのSIにBFR-IDのみを持っている領域は、より長い期間の成長にわたって多くのSIになる可能性があります。最初は成長のために十分に多くの予備のビットを持っている地域にSISを割り当てることは、この問題を軽減するのに役立ちます。または、ネットワーク拡張後にBFERを変更することもできます。この例では、6つのSISを使用して各エリアに1つを割り当てることを検討できます。
This example shows that intelligent BFR-id allocation within at least subdomain 0 can be helpful or even necessary in BIER.
この例は、少なくともサブドメイン0内のインテリジェントなBFR-ID割り当てが役立つか、ビアで必要であることを示しています。
In BIER-TE, one needs to determine a subset of the physical topology and attached BFERs so that the "desired" representation of this topology and the BFERs fit into a single BitString. This process needs to be repeated until the whole topology is covered.
BierTEでは、このトポロジーとBFERの「望ましい」表現が単一のビットストリングに適合するように、物理トポロジのサブセットと接続されたBFERを決定する必要があります。このプロセスは、トポロジ全体がカバーされるまで繰り返す必要があります。
Once bits/SIs are assigned to the topology and BFERs, BFR-ids are just a derived set of identifiers from the operator / BIER-TE controller as explained above.
BITS / SISがトポロジとBFERSに割り当てられると、BFR-IDは、上記で説明したように、オペレーター / Bier-TEコントローラーから派生した識別子のセットにすぎません。
Whenever different subtopologies have overlap, bits need to be repeated across the BitStrings, increasing the overall amount of bits required across all BitStrings/SIs. In the worst case, one assigns random subsets of BFERs to different SIs. This will result in an outcome much worse than in (non-TE) BIER: it maximizes the amount of unnecessary topology overlap across SIs and therefore reduces the number of BFERs that can be reached across each individual SI. Intelligent BFER-to-SI assignment and selecting specific "desired" subtopologies can minimize this problem.
異なる亜熱帯が重複するたびに、ビットストリング全体でビットを繰り返す必要があり、すべてのビットストリング/sisで必要なビットの全体的な量を増やします。最悪の場合、BFERのランダムサブセットを異なるSISに割り当てます。これにより、結果が（非）ビアよりもはるかに悪い結果になります。SIS間の不必要なトポロジの重複の量を最大化するため、個々のSIで到達できるBFERの数を減らします。インテリジェントなBFER-SIへの割り当てと特定の「望ましい」亜熱帯を選択すると、この問題を最小限に抑えることができます。
To set up BIER-TE efficiently for the topology shown in Figure 17, the following bit allocation method can be used. This method can easily be expanded to other, similarly structured larger topologies.
図17に示すトポロジのためにBierTEを効率的にセットアップするには、次のビット割り当て方法を使用できます。この方法は、他の、同様の構造化されたより大きなトポロジーに簡単に拡張できます。
Each area is allocated one or more SIs, depending on the number of future expected BFERs and the number of bits required for the topology in the area. In this example, six SIs are used, one per area.
各エリアには、将来の予想されるBFERの数と、その地域のトポロジに必要なビット数に応じて、1つ以上のSISが割り当てられます。この例では、領域ごとに1つのSisが使用されます。
In addition, we use four bits in each SI:
さらに、各SIで4つのビットを使用します。
bia: (b)it (i)ngress (a)
bia：（b）it（i）ngress（a）
bib: (b)it (i)ngress (b)
ビブ：（b）それ（i）ngress（b）
bea: (b)it (e)gress (a)
BEA：（b）it（e）gress（a）
beb: (b)it (e)gress (b)
beb：（b）it（e）gress（b）
These bits will be used to pass BIER packets from any BFIR via any combination of ingress area a/b BFRs and egress area a/b BFRs into a specific target area. These bits are then set up with the right forward_routed() adjacencies on the BFIRs and area edge BFRs as follows.
これらのビットは、イングレスエリアA/B BFRSと出口エリアA/B BFRの任意の組み合わせを介して、任意のBFIRからのビアパケットを特定のターゲットエリアに渡すために使用されます。これらのビットは、次のように、BFIRSおよびエリアエッジBFRの右wordword_routed（）隣接を使用してセットアップされます。
On all BFIRs in an area, j|j=1...6, bia in each BIFT:SI is populated with the same forward_routed(BFRja) and bib with forward_routed(BFRjb). On all area edge BFRs, bea in BIFT:SI=k|k=1...6 is populated with forward_routed(BFRka) and beb in BIFT:SI=k with forward_routed(BFRkb).
エリアのすべてのbfirsでは、j | j = 1 ... 6、各biftのbia：siには同じwordword_routed（bfrja）が入力され、forward_routed（bfrjb）が付いているbibが入力されます。すべてのエリアのBFRSでは、bift：si = k | k = 1 ... 6には、forward_routed（bfrka）とbebが入力され、bift：si = k with forward_routed（bfrkb）が入力されています。
For BIER-TE forwarding of a packet to a subset of BFERs across all areas, a BFIR would create at most six copies, with SI=1...SI=6. In each packet, the BitString includes bits for one area and the BFERs in that area, plus the four bits to indicate whether to pass this packet via the ingress area a or b border BFR and the egress area a or b border BFR, therefore allowing path steering for those two "unicast" legs: 1) BFIR to ingress area edge and 2) core to egress area edge. Replication only happens inside the egress areas. For BFERs that are in the same area as the BFIR, these four bits are not used.
すべての領域にわたってBFERのサブセットへのパケットのビアテ転送の場合、BFIRは最大6コピーを作成し、Si = 1 ... Si = 6で作成します。各パケットには、ビットストリングには1つの領域とそのエリアのBFERのビットに加えて、イングレスエリアAまたはBボーダーBFRと出口エリアAまたはBボーダーBFRを介してこのパケットを通過するかどうかを示す4ビットが含まれているため、これらの2つの「ユニキャスト」脚のパスステアリング：1）エリアエッジを侵入するbfir、2）コアからエリアエッジを出力します。レプリケーションは、出口領域内でのみ発生します。BFIRと同じ領域にあるBFERの場合、これらの4つのビットは使用されません。
BIER-TE can, like BIER, support multiple SIs within a subdomain. This allows application of the mapping BFR-id = SI * BSL + BP. This also permits the reuse of the BIER architecture concept of BFR-ids and, therefore, minimization of BIER-TE-specific functions in possible BIER layer control plane mechanisms with BIER-TE, including flow overlay methods and BIER header fields.
Bier-Teは、Bierと同様に、サブドメイン内の複数のSIをサポートできます。これにより、マッピングBFR-ID = SI * BSL BPを適用できます。これにより、BFR-IDのビアアーキテクチャの概念の再利用が可能になり、したがって、フローオーバーレイ法やビアヘッダーフィールドを含むビアテを使用したビア層制御プレーンメカニズムのビアテク固有の機能の最小化が可能になります。
The number of BFIRs/BFERs possible in a subdomain is smaller than in BIER because BIER-TE uses additional bits for the topology.
サブドメインで可能なBFIRS/BFERの数は、トポロジに追加のビットを使用するため、ビアよりも小さくなります。
Subdomains in BIER-TE can be used as they are in BIER to create more efficient replication to known subsets of BFERs.
Bier-TEのサブドメインは、BIERにあるため、BFERの既知のサブセットに対してより効率的な複製を作成するために使用できます。
Assigning bits for BFERs intelligently into the right SI is more important in BIER-TE than in BIER because of replication efficiency and the overall amount of bits required.
Bferのビットを右SIにインテリジェントに割り当てることは、複製効率と必要なビットの全体量が多いため、ビアよりもビアテの方が重要です。
If "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks" [RFC8296] is used, its security considerations also apply to BIER-TE.
「MPLSおよびNon-MPLSネットワークのBITインデックス明示的複製（BIER）のカプセル化[RFC8296]が使用されている場合、そのセキュリティに関する考慮事項はBierTTEにも適用されます。
The security considerations of "Multicast Using Bit Index Explicit Replication (BIER)" [RFC8279] also apply to BIER-TE, with the following overriding or additional considerations.
「BITインデックス明示的複製（BIER）を使用したマルチキャスト」のセキュリティ上の考慮事項[RFC8279]も、以下のオーバーライドまたは追加の考慮事項があるBier-TEに適用されます。
BIER-TE forwarding explicitly supports unicast "tunneling" of BIER packets via forward_routed() adjacencies. The BIER domain security model is based on a subset of interfaces on a BFR that connect to other BFRs of the same BIER domain. For BIER-TE, this security model equally applies to such unicast "tunneled" BIER packets. This not only includes the need to filter received unicast "tunneled" BIER packets to prohibit the injection of such "tunneled" BIER packets from outside the BIER domain but also the need to prohibit forward_routed() adjacencies from leaking BIER packets from the BIER domain. It SHOULD be possible to configure interfaces to be part of a BIER domain solely for sending and receiving unicast "tunneled" BIER packets even if the interface cannot send/receive BIER encapsulated packets.
BierTTE転送は、Forward_Routed（）隣接を介してBierパケットのユニキャスト「トンネル」を明示的にサポートしています。Bierドメインセキュリティモデルは、同じBierドメインの他のBFRに接続するBFRのインターフェイスのサブセットに基づいています。BierTEの場合、このセキュリティモデルは、このようなユニキャストの「トンネル付き」ビアパケットに等しく適用されます。これには、受信したユニキャストの「トンネル化された」ビアパケットをフィルタリングする必要があるだけでなく、ビアドメインの外側からのそのような「トンネル化された」ビアパケットの注入を禁止するだけでなく、BierドメインからのBierパケットの漏れを隣接する必要性も含まれます。インターフェイスがビアカプセル化されたパケットを送信/受信できない場合でも、ユニキャストの「トンネル化された」ビアパケットを送信および受信するためだけに、インターフェイスをビアドメインの一部にするように構成することができるはずです。
In BIER, the standardized methods for the routing underlays are IGPs with extensions to distribute BFR-ids and BFR-prefixes. [RFC8401] specifies the extensions for IS-IS, and [RFC8444] specifies the extensions for OSPF. Attacking the protocols for the BIER routing underlay or (non-TE) BIER layer control plane, or the impairment of any BFRs in a domain, may lead to successful attacks against the information that BIER-TE learns from the routing protocol (routes, next hops, BFR-ids, ...), enabling DoS attacks against paths or the addressing (BFR-ids, BFR-prefixes) used by BIER.
Bierでは、ルーティングアンダーレイの標準化されたメソッドは、BFR-IDとBFR-PREFIXを分布するための拡張機能を備えたIGPSです。[RFC8401] IS-ISの拡張機能を指定し、[RFC8444]はOSPFの拡張機能を指定します。Bierルーティングアンダーレイまたは（非）ビア層制御プレーン、またはドメイン内のBFRの障害のプロトコルを攻撃すると、BierTEがルーティングプロトコルから学習する情報に対する攻撃の成功につながる可能性があります（ルート、次のルート、次のものHOPS、BFR-ID、...）、BIERが使用するPATHまたはアドレス指定（BFR-ID、BFR-Prefixes）に対するDOS攻撃を可能にします。
The reference model for the BIER-TE layer control plane is a BIER-TE controller. When such a controller is used, the impairment of an individual BFR in a domain causes no impairment of the BIER-TE control plane on other BFRs. If a routing protocol is used to support forward_routed() adjacencies, then this is still an attack vector as in BIER, but only for BIER-TE forward_routed() adjacencies and not other adjacencies.
Bier-TEレイヤーコントロールプレーンの参照モデルは、Bier-TEコントローラーです。このようなコントローラーを使用すると、ドメイン内の個々のBFRの障害は、他のBFRのビアテコントロールプレーンの障害を引き起こしません。ルーティングプロトコルがForward_Routed（）の隣接をサポートするために使用される場合、これはまだBierのように攻撃ベクトルですが、Bier-Te worward_routed（）隣接のみであり、他の隣接ではありません。
Whereas IGP routing protocols are most often not well secured through cryptographic authentication and confidentiality, communications between controllers and routers such as those to be considered for the BIER-TE controller / control plane can be, and are, much more commonly secured with those security properties -- for example, by using "Secure Shell" (SSH) [RFC4253] for NETCONF [RFC6242]; or via "Transport Layer Security" (TLS), such as [RFC8253] for PCEP [RFC5440] or [RFC7589] for NETCONF. BIER-TE controllers SHOULD use security equal to or better than these mechanisms.
IGPルーティングプロトコルは、暗号化認証と機密性を通じて最もよく保護されていませんが、コントローラーとBier-TEコントローラー /コントロールプレーンのために考慮されるようなルーターとの間の通信は、それらのセキュリティプロパティでより一般的に保護される可能性があり、より一般的に保護されています。 - たとえば、NetConf [RFC6242]に「Secure Shell」（SSH）[RFC4253]を使用して。または、NetConfのPCEP [RFC5440]の[RFC8253]または[RFC7589]の[RFC8253]などの「輸送層セキュリティ」（TLS）を介して。Bier-TEコントローラーは、これらのメカニズムと同等以上のセキュリティを使用する必要があります。
When any of these security mechanisms/protocols are used for communications between a BIER-TE controller and BFRs, their security considerations apply to BIER-TE. In addition, the security considerations of "A Path Computation Element (PCE)-Based Architecture" [RFC4655] apply.
これらのセキュリティメカニズム/プロトコルのいずれかがBier-TEコントローラーとBFRS間の通信に使用される場合、それらのセキュリティに関する考慮事項はBierTEに適用されます。さらに、「パス計算要素（PCE）ベースのアーキテクチャ」[RFC4655]のセキュリティに関する考慮事項が適用されます。
The most important attack vector in BIER-TE is misconfiguration, either on the BFRs themselves or via the BIER-TE controller. Forwarding entries with DNC could be set up to create persistent loops, in which packets only expire because of TTL. To minimize the impact of such attacks (or, more likely, unintentional misconfiguration by operators and/or bad BIER-TE controller software), the BIER-TE forwarding rules are defined to be as strict in clearing bits as possible. The clearing of all bits with an adjacency on a BFR prohibits a looping packet from creating additional packet amplification through the misconfigured loop on the packet's second time or subsequent times around the loop, because all relevant adjacency bits would have been cleared on the first round through the loop. As a result, looping packets can occur in BIER-TE to the same degree as is possible with unintentional or malicious loops in the routing underlay with BIER, or even with unicast traffic.
BierTTEの最も重要な攻撃ベクトルは、BFR自体またはBier-TEコントローラーを介して、誤った構成です。DNCを使用した転送エントリをセットアップして、パケットがTTLのためにのみ期限切れになる永続的なループを作成することができます。このような攻撃の影響を最小限に抑えるため（または、オペレーターおよび/または不良なビアーコントローラーソフトウェアによる意図しない誤解）、Bier-TE転送ルールは、BITを可能な限り厳格にすると定義されています。BFRに隣接するすべてのビットのクリアは、すべての関連する隣接ビットが最初のラウンドでクリアされていたため、ループの2回目またはその後のループの周りの誤解されたループを介して追加のパケット増幅を作成することをループパケットの作成を禁止します。ループ。その結果、ルーピングパケットは、BierTTEまたは悪意のあるループを使用して、Bierを使用して、またはユニキャストトラフィックを使用したルーティングアンダーレイで可能なものと同じ程度まで発生する可能性があります。
Deployments where BIER-TE would likely be beneficial may include operational models where actual configuration changes from the controller are only required during non-production phases of the network's life cycle, e.g., in embedded networks or in manufacturing networks during such activities as plant reworking or repairs. In these types of deployments, configuration changes could be locked out when the network is in production state and could only be (re-)enabled through reverting the network/installation to non-production state. Such security designs would not only allow a deployment to provide additional layers of protection against configuration attacks but would, first and foremost, protect the active production process from such configuration attacks.
BierTEが有益である可能性が高い展開には、ネットワークのライフサイクルの非生産段階でのみコントローラーからの実際の構成の変更が必要な運用モデルが含まれる場合があります。修理。これらのタイプの展開では、ネットワークが生産状態にあり、ネットワーク/インストールを非生産状態に戻すことで（再）有効にすることができるときに、構成の変更がロックアウトされる可能性があります。このようなセキュリティ設計により、展開が構成攻撃に対する追加の保護層を提供できるだけでなく、何よりもまず、そのような構成攻撃からアクティブな生産プロセスを保護します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>。
[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。、ed。、Rosen、E.、ed。、Dolganow、A.、Przygienda、T.、およびS. Aldrin、「Bit Index Expricit Replication（Bier）を使用したマルチキャスト」、RFC 8279、Doi10.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。、ed。、Rosen、E.、ed。、Dolganow、A.、Tantsura、J.、Aldrin、S.、およびI. Meilik、「ビットインデックスの明示的複製（Bier）のカプセル化MPLSおよびNON-MPLSネットワーク」、RFC 8296、DOI 10.17487/RFC8296、2018年1月、<https://www.rfc-editor.org/info/rfc8296>。
[BIER-MCAST-OVERLAY] Trossen, D., Rahman, A., Wang, C., and T. Eckert, "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Work in Progress, Internet-Draft, draft-ietf-bier-multicast-http-response-06, 10 July 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-bier-multicast-http-response-06>.
[Bier-Mcast-Overlay] Trossen、D.、Rahman、A.、Wang、C。、およびT. Eckert、「適応ストリーミングサービス向けのビアマルチキャストオーバーレイの適用-bier-multicast-http-response-06、2021年7月10日、<https://datatracker.ietf.org/doc/html/draft-ietf-bier-multicast-http-response-06>。
[BIER-TE-PROTECTION] Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Protection Methods for BIER-TE", Work in Progress, Internet-Draft, draft-eckert-bier-te-frr-03, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-eckert-bier-te-frr-03>.
[Bierte-stection] Eckert、T.、Cauchie、G.、Braun、W。、およびM. Menth、「Bier-Teの保護方法」、進行中の作業、インターネットドラフト、Draft-Ceckert-Bier-Te-frr-03、2018年3月5日、<https://datatracker.ietf.org/doc/html/draft-eckert-bier-te-frr-03>。
[BIER-TE-YANG] Zhang, Z., Wang, C., Chen, R., Hu, F., Sivakumar, M., and H. Chen, "A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Work in Progress, Internet-Draft, draft-ietf-bier-te-yang-05, 1 May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-bier-te-yang-05>.
[Bier-Te-Yang] Zhang、Z.、Wang、C.、Chen、R.、Hu、F.、Sivakumar、M。、およびH. Chen、「ビットインデックスのツリーエンジニアリングのヤンデータモデル明示的複製（bier-te） "、作業中の作業、インターネットドラフト、ドラフト - ビアテヤン-05、2022年5月1日、<https://datatracker.ietf.org/doc/html/draft-ietf-Bier-Te-Yang-05>。
[Bloom70] Bloom, B. H., "Space/time trade-offs in hash coding with allowable errors", Comm. ACM 13(7):422-6, DOI 10.1145/362686.362692, July 1970, <https://dl.acm.org/doi/10.1145/362686.362692>.
[Bloom70] Bloom、B。H.、「許容エラーを伴うハッシュコーディングにおける空間/タイムトレードオフ」、Comm。ACM 13（7）：422-6、DOI 10.1145/362686.362692、1970年7月、<https://dl.acm.org/doi/10.1145/362686.362692>。
[CONSTRAINED-CAST] Bergmann, O., Bormann, C., Gerdes, S., and H. Chen, "Constrained-Cast: Source-Routed Multicast for RPL", Work in Progress, Internet-Draft, draft-ietf-roll-ccast-01, 30 October 2017, <https://datatracker.ietf.org/doc/html/ draft-ietf-roll-ccast-01>.
[Constrained-Cast] Bergmann、O.、Bormann、C.、Gerdes、S。、およびH. Chen、「Constrained-Cast：Source-Routed Multicast for RPL」、Work in Progress、Internet-Draft、Draft-ITF-Roll-ccast-01、2017年10月30日、<https://datatracker.ietf.org/doc/html/ draft-ietf-roll-ccast-01>。
[ICC] Reed, M. J., Al-Naday, M., Thomos, N., Trossen, D., Petropoulos, G., and S. Spirou, "Stateless multicast switching in software defined networks", IEEE International Conference on Communications (ICC), Kuala Lumpur, Malaysia, DOI 10.1109/ICC.2016.7511036, May 2016, <https://ieeexplore.ieee.org/document/7511036>.
[ICC] Reed、M。J.、Al-Naday、M.、Thomos、N.、Trossen、D.、Petropoulos、G。、およびS. Spirou、「ソフトウェア定義ネットワークのステートレスマルチキャストスイッチング」、IEEE国際通信会議（ICC）、マレーシア、クアラルンプール、DOI 10.1109/ICC.2016.7511036、2016年5月、<https://ieeexplore.ieee.org/document/7511036>。
[NON-MPLS-BIER-ENCODING] Wijnands, IJ., Mishra, M., Xu, X., and H. Bidgoli, "An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation", Work in Progress, Internet-Draft, draft-ietf-bier-non-mpls-bift-encoding-04, 30 May 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-bier-non-mpls-bift-encoding-04>.
[Non-Mpls-Bier-Encoding] Wijnands、IJ。、Mishra、M.、Xu、X。、およびH. Bidgoli、「非MPLSビアカプセル化におけるBift-IDフィールドのオプションのエンコード」は、作業中進行状況、インターネットドラフト、ドラフト-ITF-BIER-MPLS-BIFT-ENCODING-04、2021年5月30日、<https://datatracker.ietf.org/doc/html/draft-ietf-bier-non-mpls-bift-Encoding-04>。
[RCSD94] Zhang, H. and D. Ferrari, "Rate-Controlled Service Disciplines", Journal of High Speed Networks, Volume 3, Issue 4, pp. 389-412, DOI 10.3233/JHS-1994-3405, October 1994, <https://content.iospress.com/articles/journal-of-high-speed-networks/jhs3-4-05>.
[RCSD94] Zhang、H。およびD. Ferrari、「レート制御されたサービス分野」、Journal of High Speed Networks、Volume 3、Issue 4、pp。389-412、DOI 10.3233/JHS-1994-3405、1994年10月、<https://content.iospress.com/articles/journal-of-high-speed-networks/jhs3-4-05>。
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253] Ylonen、T。およびC. Lonvick、ed。、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、DOI 10.17487/RFC4253、2006年1月、<https：//www.rfc-editor.org/info/rfc4253>。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/info/rfc4456>.
[RFC4456] Bates、T.、Chen、E。、およびR. Chandra、「BGPルートリフレクション：フルメッシュ内部BGP（IBGP）の代替」、RFC 4456、DOI 10.17487/RFC4456、2006年4月、<https：//www.rfc-editor.org/info/rfc4456>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P.、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、DOI 10.17487/RFC4655、2006年8月、<https：//www.rfc-editor.org/info/rfc4655>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、jp。、ed。とjl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、DOI 10.17487/RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc540>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R.、ed。、ed。、Bjorklund、M.、ed。、Schoenwaelder、J.、ed。、およびA. Bierman、ed。、 "Network Configuration Protocol（NetConf）"、RFC 6241、doi 10.17487/RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman、M。、「セキュアシェル（SSH）を介してNetConfプロトコルを使用」、RFC 6242、DOI 10.17487/RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015, <https://www.rfc-editor.org/info/rfc7589>.
[RFC7589] Badra、M.、Luchuk、A。、およびJ. Schoenwaelder、「相互X.509認証を備えた輸送層セキュリティ（TLS）を介したNetConfプロトコルを使用」、RFC 7589、DOI 10.17487/RFC7589、2015年6月、<<<<https://www.rfc-editor.org/info/rfc7589>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A。、およびS. Ray、「BGPを使用したリンク状態および交通工学の北行き分布（TE）情報」、RFC 7752、DOI 10.17487/RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ed。、「Yang 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487/RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress Replication Tunnels in Multicast VPN", RFC 7988, DOI 10.17487/RFC7988, October 2016, <https://www.rfc-editor.org/info/rfc7988>.
[RFC7988] Rosen、E.、Ed。、ed。、Subramanian、K。、およびZ. Zhang、「マルチキャストVPNのイングレス複製トンネル」、RFC 7988、DOI 10.17487/RFC7988、2016年10月、<https：//ww.rfc-editor.org/info/rfc7988>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RestConf Protocol」、RFC 8040、DOI 10.17487/RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040>。
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253] Lopez、D.、Gonzalez de Dios、O.、Wu、Q.、およびD. Dhody、「PCEPS：TLSの使用パス計算要素通信プロトコル（PCEP）の安全な輸送を提供する」、RFC 8253、doi 10.17487/rfc8253、2017年10月、<https://www.rfc-editor.org/info/rfc8253>。
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8345] CLEMM、A.、Medved、J.、Varga、R.、Bahadur、N.、Ananthakrishnan、H。、およびX. Liu、「ネットワークトポロジーのヤンデータモデル」、RFC 8345、DOI 10.17487/RFC8345555555555555555、2018年3月、<https://www.rfc-editor.org/info/rfc8345>。
[RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. Zhang, "Bit Index Explicit Replication (BIER) Support via IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, <https://www.rfc-editor.org/info/rfc8401>.
[RFC8401] Ginsberg、L.、Ed。、Przygienda、T.、Aldrin、S。、およびZ. Zhang、「IS-IS経由のビットインデックス明示的複製サポート」、RFC 8401、DOI 10.17487/RFC8401、6月2018、<https://www.rfc-editor.org/info/rfc8401>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C.、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 Extensions for Bit Index Explicit Replication (BIER)", RFC 8444, DOI 10.17487/RFC8444, November 2018, <https://www.rfc-editor.org/info/rfc8444>.
[RFC8444] Psenak、P.、Ed。、Kumar、N.、Wijnands、IJ。、Dolganow、A.、Przygienda、T.、Zhang、J。、およびS. Aldrin、 "Ospfv2拡張ビットインデックス明示的複製（bier） "、rfc 8444、doi 10.17487/rfc8444、2018年11月、<https://www.rfc-editor.org/info/rfc844>。
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., and A. Dolganow, "Multicast VPN Using Bit Index Explicit Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 2019, <https://www.rfc-editor.org/info/rfc8556>.
[RFC8556] Rosen、E.、Ed。、ed。、Sivakumar、M.、Przygienda、T.、Aldrin、S.、およびA. Dolganow、「Bit Index expricit Replication（Bier）を使用したマルチキャストVPN」、RFC 8556、DOI 10.17487/RFC8556、2019年4月、<https://www.rfc-editor.org/info/rfc8556>。
[TE-OVERVIEW] Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", Work in Progress, Internet-Draft, draft-ietf-teas-rfc3272bis-21, 11 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc3272bis-21>.
[TE-Overview] Farrel、A.、ed。、「インターネットトラフィックエンジニアリングの概要と原則」、進行中の作業、インターネットドラフト、ドラフト-ITEAS-RFC3272BIS-21、2022年9月11日、<https：//datatracker.ietf.org/doc/html/draft-ietf-teas-rfc3272bis-21>。
Appendix A. BIER-TE and Segment Routing (SR)
付録A. ビアテとセグメントルーティング（SR）
SR [RFC8402] aims to enable lightweight path steering via loose source routing. For example, compared to its more heavyweight predecessor, RSVP-TE, SR does not require per-path signaling to each of these hops.
SR [RFC8402]は、ルーズソースルーティングを介して軽量パスステアリングを有効にすることを目指しています。たとえば、よりヘビー級の前任者であるRSVP-TEと比較して、SRはこれらの各ホップにパスごとの信号を必要としません。
BIER-TE supports the same design philosophy for multicast. Like SR, BIER-TE
Bierteは、マルチキャストと同じデザイン哲学をサポートしています。srのように、ビアテ
* relies on source routing (via a BitString), and
* ソースルーティングに依存しています（ビットストリングを介して）、
* only requires consideration of the "hops" either (1) on which replication has to happen or (2) across which the traffic should be steered (even without replication).
* （1）レプリケーションが発生する必要がある（1）（2）トラフィックを操縦する必要がある（2）（複製がなくても）のいずれかを考慮する必要があります。
Any other hops can be skipped via the use of routed adjacencies.
他のホップは、ルーティングされた隣接を使用してスキップできます。
BIER-TE "bit positions" (BPs) can be understood as the BIER-TE equivalent of "forwarding segments" in SR, but they have a different scope than do forwarding segments in SR. Whereas forwarding segments in SR are global or local, BPs in BIER-TE have a scope that is comprised of one or more BFRs that have adjacencies for the BPs in their BIFTs. These segments can be called "adjacency-scoped" forwarding segments.
ビアテの「ビット位置」（BPS）は、SRの「転送セグメント」に相当するビアテと同等のものとして理解できますが、SRの転送セグメントとは異なる範囲を持っています。SRの転送セグメントはグローバルまたはローカルであるのに対し、BierTEのBPSには、BPSのBPSの隣接がある1つ以上のBFRで構成されるスコープがあります。これらのセグメントは、「隣接する」転送セグメントと呼ばれます。
Adjacency scope could be global, but then every BFR would need an adjacency for a given BP -- for example, a forward_routed() adjacency with encapsulation to the global SR "Segment Identifier" (SID) of the destination. Such a BP would always result in ingress replication, though (as in [RFC7988]). The first BFR encountering this BP would directly replicate traffic on it. Only by using non-global adjacency scope for BPs can traffic be steered and replicated on a non-BFIR.
隣接範囲はグローバルかもしれませんが、すべてのBFRは、特定のBPの隣接を必要とします。たとえば、宛先のグローバルSR「セグメント識別子」（SID）へのカプセル化を伴うForward_Routed（）隣接が必要です。ただし、このようなBPは、[RFC7988]のように、常に侵入の複製をもたらします。このBPに遭遇した最初のBFRは、その上のトラフィックを直接複製します。BPSに非グローバル隣接範囲を使用することによってのみ、トラフィックを操縦および非BFIRで複製できます。
SR can naturally be combined with BIER-TE and can help optimize it. For example, instead of defining bit positions for non-replicating hops, it is equally possible to use SR encapsulations (e.g., SR-MPLS label stacks) for the encapsulation of "forward_routed()" adjacencies.
SRは自然にBierTEと組み合わせることができ、最適化するのに役立ちます。たとえば、非複製ホップのビット位置を定義する代わりに、「Forward_Routed（）」隣接のカプセル化には、SRカプセル（SR-MPLSラベルスタックなど）を使用することも同様に可能です。
Note that (non-TE) BIER itself can also be seen as being similar to SR. BIER BPs act as global destination Node-SIDs, and the BIER BitString is simply a highly optimized mechanism to indicate multiple such SIDs and let the network take care of effectively replicating the packet hop by hop to each destination Node-SID. BIER does not allow the indication of intermediate hops or, in terms of SR, the ability to indicate a sequence of SIDs to reach the destination. On the other hand, BIER-TE and its adjacency-scoped BPs provide these capabilities.
（非）ビア自体は、SRに似ていると見なすこともできます。Bier BPSはグローバル宛先ノードSIDSとして機能し、Bier BitStringは単にそのような複数のSIDを示すための高度に最適化されたメカニズムであり、各宛先ノードSIDにホップでパケットホップを効果的に複製するようにします。Bierは、中間ホップの兆候、またはSRの観点から、目的地に到達するために一連のSIDを示す能力を許可していません。一方、BierTEとその隣接するBPSはこれらの機能を提供します。
Acknowledgements
謝辞
The authors would like to thank Greg Shepherd, IJsbrand Wijnands, Neale Ranns, Dirk Trossen, Sandy Zheng, Lou Berger, Jeffrey Zhang, Carsten Bormann, and Wolfgang Braun for their reviews and suggestions.
著者は、グレッグ・シェパード、イジスブランド・ウィジュナンズ、ニール・ランズ、ダーク・トロッセン、サンディ・チャン、ルー・バーガー、ジェフリー・チャン、カルステン・ボーマン、ウォルフガング・ブラウンにレビューと提案に感謝します。
Special thanks to Xuesong Geng for shepherding this document. Special thanks also for IESG review/suggestions by Alvaro Retana (responsible AD/RTG), Benjamin Kaduk (SEC), Tommy Pauly (TSV), Zaheduzzaman Sarker (TSV), Éric Vyncke (INT), Martin Vigoureux (RTG), Robert Wilton (OPS), Erik Kline (INT), Lars Eggert (GEN), Roman Danyliw (SEC), Ines Robles (RTGDIR), Robert Sparks (Gen-ART), Yingzhen Qu (RTGDIR), and Martin Duke (TSV).
この文書を羊飼いしてくれたXuesong Gengに感謝します。Alvaro Retana（責任あるAD/RTG）、Benjamin Kaduk（SEC）、Tommy Pauly（TSV）、Zaheduzzaman Sarker（TSV）、Eric Vyncke（int）、Martin Vigoureux（RTG）、Robert Wilttonton（Ops）、Erik Kline（int）、Lars Eggert（gen）、Roman Danyliw（Sec）、Ines Robles（RTGDIR）、Robert Sparks（Gen-Art）、Yingzhen QU（RTGDIR）、Martin Duke（TSV）。
Authors' Addresses
著者のアドレス
Toerless Eckert (editor) Futurewei Technologies Inc. 2330 Central Expy Santa Clara, CA 95050 United States of America Email: tte@cs.fau.de
Toerless Eckert（編集者）FutureWei Technologies Inc. 2330 Central Expy Santa Clara、CA 95050アメリカ合衆国電子メール：tte@cs.fau.de
Michael Menth University of Tuebingen Germany Email: menth@uni-tuebingen.de
マイケル・メンタ・ユニバーシティ・ドイツ・ドイツ・メール・メール：menth@uni-tuebingen.de
Gregory Cauchie KOEVOO France Email: gregory@koevoo.tech
Gregory Cauchie Koevoo Franceメール：gregory@koevoo.tech