Zenn
📑

RFC 8296: MPLSと非MPLSネットワークでのBit Index Explicit Replication(BIER)のカプセル化

2024/05/07に公開
RFC
multicast
bier
tech

要旨

Bit Index Explicit Replication (BIER)は、「マルチキャスト・ドメイン」を介した最適なマルチキャスト・フォワーディングを提供するアーキテクチャであり、中間ルータがフローごとの状態を維持したり、明示的なツリー構築プロトコルに関与したりする必要はない。マルチキャスト・データ・パケットがドメインに入ると、イングレス・ルータはパケットの送信先となるエグレス・ルータ・セットを決定する。次に、イングレス・ルータはパケットをBIERヘッダにカプセル化する。BIERヘッダにはビット列が含まれ、各ビットはドメイン内の1つのエグレス・ルータを正確に表す。特定のエグレス・ルータ・セットにパケットをフォワードするには、それらのルータに対応するビットがBIERヘッダに設定される。カプセル化の詳細は、マルチキャスト・ドメインの実現に使用されるネットワークのタイプに依存する。本文書は、MPLSネットワークでも、若干の違いはあるが、非MPLSネットワークでも使用できるBIERカプセル化を規定する。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではなく、検討、実験的実装、評価のために公開する。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc8296 で入手できる。

著作権表示

Copyright (c) 2017 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

[RFC8279]は、マルチキャスト・データ・パケットをフォワーディングするための新しいアーキテクチャを説明する。「Bit Index Explicit Replication」(BIER)として知られるこのアーキテクチャは、「マルチキャスト・ドメイン」を介したマルチキャスト・データ・パケットの最適なフォワーディングを提供する。これは、明示的なツリー構築プロトコルを必要とせず、中間ノードがフローごとの状態を維持する必要もない。

本文書では、[RFC8279]で定義された用語を使用する。

BIERをサポートするルータは、「ビット・フォワーディング・ルータ」(BFR)と呼ばれる。「BIERドメイン」とは、接続されたBFRの集合であり、各BFRにはBFRプレフィックスが割り当てられる。BFRプレフィックスは、BFRのルーティング可能なIPアドレスで、BIERがBFRを識別するために使用する。パケットは、ビット・フォワーディング・イングレス・ルータ(BFIR)でBIERドメインに入り、1つ以上のビット・フォワーディング・エグレス・ルータ(BFER)でBIERドメインから出る。[RFC8279]で規定しているように、特定のBIERドメインの各BFRは1つ以上の「サブドメイン」(SD)にあるようにプロビジョニングされる。指定されたSDの文脈では、各BFIRおよびBFERは、そのSD内でユニークなBFR-idが必要である。BFR-idは、BIER SDに関連して、BFRをユニークに識別する[1,65535]の範囲内の数値である。

[RFC8279]で説明されているように、BIERは、BIERはマルチキャスト・データ・パケットを、BIERフォワーディング手順をサポートするために必要な情報を提供するヘッダでカプセル化することを要求する。この情報には、パケットが割り当てられたSD、セット識別子(SI)、BitString、およびBitStringLength (BSL)が含まれる。これらの値を組み合わせて、パケットの配信先となるBFERセットを識別するために使用される。

本文書は、MPLSネットワークでも非MPLS ネットワークでも使用できるカプセル化を定義する。ただし、BIERヘッダの構築と処理は、MPLSネットワークと非MPLSネットワークでは若干異なる。特に:

  • カプセル化ヘッダ(「BIERヘッダ」)の特定のフィールドの処理は、基盤となるネットワークがMPLSネットワークかどうかによって異なる。

  • MPLSネットワークでは、BIERヘッダの最初の4オクテットは、MPLSラベルスタックの最下位エントリ(最後の4オクテット)でもある。

MPLSベースのカプセル化については、セクション2.1で詳しく説明する。MPLSベースのカプセル化と非MPLSカプセル化の違いは、セクション2.2で説明する。

BIERヘッダの後には「ペイロード」が続く。ペイロードは、IPv4パケット、IPv6パケット、イーサネット・フレーム、MPLSパケット、またはOperations, Administration, and Maintenance (OAM)パケットである。(BIERを他のペイロード・タイプで使用することも可能だが、本文書ではこれ以上説明しない。) BIERヘッダには、ペイロードのタイプを識別する情報(Next Protocolフィールド)が含まれる。

ペイロードがMPLSパケットの場合、MPLSラベルスタックはBIERヘッダの直後に続く。このMPLSラベルスタックの最上位ラベルは、ダウンストリームに割り当てられたラベル[RFC3031]またはアップストリームに割り当てられたラベル[RFC5331]のいずれかとなる。

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

2. BIERヘッダ

BIERヘッダを図1に示す。

fig1
図1: BIERヘッダ

BIFT-idは、特定のBit Index Forwarding Table (BIFT)を表す。[RFC8279]のセクション6.4を参照のこと。[RFC8279]で説明するように、各BIFTはSD、BSL、SIの特定の組み合わせに対応する。

セクション2.1では、カプセル化ヘッダのフィールドがMPLSネットワークでどのように使用されるかについて説明している。非MPLSネットワークで使用方法が異なるフィールドについては、セクション2.2でその違いを説明する。

本文書で定義されているカプセル化のデフォルトのBitStringLength値は256である。デフォルトのBitStringLength値については、[RFC8279]のセクション3を参照のこと。

2.1. MPLSネットワーク内

2.1.1. カプセル化の最初の4オクテット

2.1.1.1. BIER-MPLSラベル

[RFC8279]に記載されているように、BIERドメインがIGPドメインでもある場合、各BFRはBFR-idとBFR-prefixを広告するためにIGP拡張を使用できる。OSPFの拡張は [OSPF_BIER_EXTENSIONS]に記載されている。IS-ISの拡張は[ISIS_BIER_EXTENSIONS]に記載されている。

特定のBIERドメインがIGPドメインとMPLSネットワークの両方である場合、各BFRもIGP拡張を使用して、1つ以上の「BIER-MPLS」ラベルセットを広告することを想定している。ドメインに1つのSDが含まれる場合、指定されたBFRは、SIとBSLの組み合わせごとに、そのようなラベルを1つ広告する必要がある。ドメインに複数のSDが含まれている場合、BFRは各SDのBSLごとSIごとに1つずつ、そのようなラベルを広告する必要がある。

環境によっては、BIERドメインの唯一のルーティング・プロトコルがBGPだけかも知れない。この場合、[BGP_BIER_EXTENSIONS]に記載されているBGP拡張を使用して、必要なBIER-MPLSラベルセットを広告できる。

BIER-MPLSラベルはローカルで重要な(つまり、ラベルを広告するBFRにのみユニークな) ダウンストリーム割り当てMPLSラベルである。最後から2番目のホップ・ポッピング[RFC3031]をBIER-MPLSラベルに適用してはならない(MUST NOT)。

例えば、1つのSD(デフォルトSD)があり、ネットワークが256のBSLを使用し、SD内のすべてのBFERのBFR-idが[1,512]の範囲内であると仮定する。各BIERのBitStringは256ビット長であるため、2つのSI(SI=0とSI=1)を使用する必要がある。したがって、各BFRは、IGP拡張を介して、BIERの2つのMPLSラベル(SI=0に対応する1つと、SI=1に対応する1つ)を広告する。これらのラベルの広告は、各ラベルをデフォルトのSDとBSL 256にバインドする。

もう一つの例として、あるBIERドメインに2つのSD(SD 0とSD 1)が含まれ、2つのBSL(256と512)をサポートし、1024台のBFRが含まれているとする。両方のSDにプロビジョニングされ、両方のBSLをサポートするBFRは、次のBIER-MPLSラベルセットを広告する必要がある。

L1: SD 0、BSL 256、SI 0に対応。

L2: SD 0、BSL 256、SI 1に対応。

L3: SD 0、BSL 256、SI 2に対応。

L4: SD 0、BSL 256、SI 3に対応。

L5: SD 0、BSL 512、SI 0に対応。

L6: SD 0、BSL 512、SI 1に対応。

L7: SD 1、BSL 256、SI 0に対応。

L8: SD1、BSL256、SI1に対応。

L9: SD 1、BSL 256、SI 2に対応。

L10: SD 1、BSL 256、SI 3に対応。

L11: SD 1、BSL 512、SI 0に対応。

L12: SD 1、BSL 512、SI 1に対応。

上記の例は、BFRが12の個別ラベルを広告する必要があることを示唆していると解釈すべきではない。例えば、<SD 1, BSL 512, SI 0>のラベルと<SD 1, BSL 512, SI 1>のラベルを広告する代わりに、BFRは<SD 1, BSL 512>に対応するラベルの連続した範囲(この場合、正確に2つのラベルを含む範囲)を広告することができる。範囲の最初のラベルはSI 0に対応し、2番目のラベルはSI 1に対応する。広告を生成し、形成するための正確なメカニズムは、本文書の範囲外である。[OSPF_BIER_EXTENSIONS]と[ISIS_BIER_EXTENSIONS]を参照のこと。

SD、SI、BSLの特定の組み合わせに対応するBIER-MPLSラベルは、SD、SI、BSLの同じ組み合わせに対応するBIFTを表すものとして解釈される。つまり、BIER-MPLSラベルはBIFT-idの機能を実行する。このラベル値は、BIERカプセル化のBIFT-idフィールドで運ばれる。

MPLSネットワークでは、BIERカプセル化ヘッダの最初の4オクテットがMPLSヘッダの最後の4オクテットでもあることを理解することが重要である。したがって、以前のMPLSラベル・スタック・エントリは、Sビット([RFC3032]を参照)をクリアしなければならない(つまり、Sビットは0でなければならない(MUST))(MUST)。

BFRがMPLSパケットを受信し、次に処理されるラベルがそのBIER-MPLSラベルの1つである場合、BFRはBIERヘッダの残りの部分(セクション2.1.2を参照)がスタックの直後に続くものと想定する。

実際には、ラベルは使用される場合にのみ割り当てる必要があることに留意すること。特定のBIERドメインがBSL 256と512をサポートしているが、一部のSD(SD 1など)がBSL 256のみを使用している場合、SD 1とBSL 512の組み合わせに対応するラベルを割り当てる必要はない。

2.1.1.2. 最初の4オクテットの他のフィールド

TC: 「Traffic Class」フィールド[RFC5462]は、MPLSラベル・スタック・エントリの通常の意味を持つ。

Sビット: BIERパケットがMPLSネットワークを通過するとき、BIERカプセル化の最初の4オクテットの上位20ビットには、BIFT-idフィールドのMPLSラベルが含まれる。これらの4オクテットは、パケットのMPLSラベル・スタックの最終エントリとして扱う。したがって、Sビット([RFC3032]を参照)は1に設定しなければならない(MUST)。BIERカプセル化の直前にMPLSラベル・スタック・エントリがある場合、それらのラベル・スタック・エントリのSビットは0に設定しなければならない(MUST)。

TTL: これは通常のMPLSの「Time to Live」フィールド[RFC3032]である。BIERパケットを受信すると、その「受信TTL」(以下を参照)をこのTTLフィールドから取得する。

BIERパケットが1つ以上のBFR隣接先にフォワードされる場合、フォワードされたパケットによって伝送されるBIER-MPLSラベルには、パケットの受信TTLより1小さい値のTTLフィールドがなければならない(MUST)。

BIERパケットの受信TTLが1以上で、そのBitString内のビットの1つが現在のBFRを識別する場合、現在のBFRはパケットのBFERである。したがって、現在のBFRは、例えばBIERカプセル化を解除し、プロトコル(Next Protocol)フィールドの内容に基づいてペイロードを処理するなど、BFERとしてパケットを処理しなければならない(MUST)。

受信TTLが0の場合、パケットは「期限切れ」とみなされる。受信TTLが1で、BitStringに現在のBFRを識別しないビットセットが設定されている場合、パケットは期限切れとみなされる。期限切れのパケットはエラー処理手順に渡す必要がある(SHOULD)。(パケットがエラー処理手順に渡されるレートを制御するために、オプションの実装固有のレート制限が適用されるかも知れない。) エラー処理手順の仕様は、本文書の範囲外である。

受信したBIERパケットの受信TTLが1で、そのBitStringに現在のBFRを識別するビットセットが設定されている場合、ペイロードは現在のBFRで処理しなければならない(MUST)。ただし、そのパケットはそれ以上フォワードされてはならず(MUST NOT)、そのパケットは(実装固有のレート制限に依存する)期限切れパケットのエラー処理手順に渡す必要がある(SHOULD)。

2.1.2. カプセル化の残り

ニブル: このフィールドはバイナリ値0101に設定される。これにより、MPLS ECMPロジックがBIERヘッダの残りの部分をIPヘッダや疑似ワイヤ・パケットのヘッダと混同しないようにする。MPLSネットワークでは、BFRがラベル・スタック後の最初のニブルに他の値を持つBIERパケットを受信した場合、そのパケットを破棄してエラーを記録する必要がある(SHOULD)。

Ver: この4ビットのフィールドは、BIERヘッダのバージョンを識別する。本文書では、BIERヘッダのバージョン0を指定する。特定のBFRがパケットを受信し、そのBFRが指定されたバージョンのBIERヘッダをサポートしていない場合、BFRはパケットを破棄し、エラーを記録しなければならない(MUST)。

値0xFは実験用に予約されている。この値は、将来のIETF文書またはIANAによって割り当てられてはならない(MUST NOT)。

BSL: この4ビット・フィールドは、BitStringの長さをビット単位で符号化する。

注: BIERヘッダを解析するとき、BFRはBIFT-idからBitStringの長さを推測しなければならず(MUST)、このフィールドの値から推測してはならない(MUST NOT)。このフィールドは、オフライン・ツール(LANアナライザなど)がBIERヘッダを解析できるようにするためだけに存在する。

kをBitStringの長さとすると、このフィールドの値はlog2(k)-5となる。ただし、特定の値飲みがサポートされる。

1: 64ビット

2: 128ビット

3: 256ビット

4: 512ビット

5: 1024ビット

6: 2048ビット

7: 4096ビット

このフィールドの値には、上記以外の値を設定してはならない。このフィールドに別の値を含む受信パケットは破棄され、エラーが記録されるべきである(SHOULD)。このフィールドの値がBIER-MPLSラベルに基づいて予想される値と異なる場合、パケットは破棄され、エラーが記録されるべきである(SHOULD)。

エントロピー: この20ビットのフィールドは、負荷分散の目的で使用できる「エントロピー」値を指定する。BIERフォワーディング・プロセスは等コストの負荷分散を実行することができる。この場合、負荷分散手順は、同じエントロピー値と同じBitStringを持つ2つのパケットに対して、同じパスを選択しなければならない(MUST)。BIER負荷分散手順の詳細については、[RFC8279]のセクション6.7(「等コスト・マルチパス・フォワーディング」)を参照のこと。

BFIRがエントロピ・ラベルを持つMPLSパケットを(ペイロードとして)カプセル化する場合、BFIRは、そのような2つのパケットが同じMPLSエントロピ・ラベルを持つ場合、BIERエントロピ・フィールドの値も同じであることを保証しなければならない(MUST)。

OAM: デフォルトでは、これらの2ビットはBFIRによって0に設定され、他のBFRによって変更されることはない。これらの2ビットは、BIERパケットが通過するパスには影響せず、BIERパケットに適用されるサービス品質にも影響を与えない。

デフォルト以外の方法でこれらのビットを使用することはオプションである。これらのビットのデフォルト以外の使用または使用方法の仕様は、本文書の範囲外である。このような仕様の例については、[BIER-PMM]を参照のこと。

Rsv: この2ビットは現在未使用である。送信時には0に設定すべきであり(SHOULD)、受信時には無視しなければならない(MUST)。

DSCP: デフォルトでは、この6ビットフィールドはMPLSネットワークでは使用されない。デフォルトの動作では、送信時には6ビットすべてを0に設定すべきであり(SHOULD)、受信時には無視しなければならない(MUST)。

MPLSネットワークでこのフィールドのデフォルト以外の使用することは、本文書の範囲外である。

プロトコル: この6ビットの「Next Protocol」フィールドは、ペイロードのタイプを識別する。(「ペイロード」は、BIERヘッダの直後に続くパケットまたはフレームである。) IANAは、「BIER Next Protocol Identifiers」というレジストリを作成した。このフィールドには、そのレジストリから適切なエントリを入力する。

BFERがBIERパケットを受信したが、Next Protocolフィールドの値を認識しない(またはサポートしない)場合、BFERはパケットを破棄し、エラーをログに記録すべきである(SHOULD)。

BFIR-id: デフォルトでは、これはパケットが割り当てられているSD内のBFIRのBFR-idである。BFR-idは16ビットフィールドで、[1,65535]の範囲の符号なし整数として に符号化される。

アプリケーションによっては、BFIR-idフィールドにBFIR以外のBFRのBFR-idを含メル必要がある。しかし、BFIR-idフィールドのそのような使用法は、本文書の範囲外である。

BitString: このフィールドは、パケットのSIとSDとともに、このパケットの宛先BFERを識別するBitStringを保持する。特定のBIFT-id は常に特定のSIとSDに対応するため、パケットのSIとSDはBIERヘッダで明示的に伝送されないことに留意する。

2.1.3. BIERパケットのさらなるカプセル化

BIERパケットをあるBFRから別のBFRに送信するには、パケットをさらにカプセル化しなければならない場合がある。例えば、シナリオによっては、BIERパケットをイーサネット・フレームでカプセル化しなければならない場合がある。他のシナリオでは、BIERパケットをUDPパケットでカプセル化しなければならない場合がある。このような場合、BIERパケット自体が「外側の(outer)」カプセル化のペイロードとなる。

本文書では、BIERパケットをペイロードとして伝送するフレームまたはパケットがユニキャスト・フレームまたはパケットであると仮定する。つまり、BIERパケットはマルチキャスト・パケットだが、BIERパケットをペイロードとして伝送するフレームまたはパケットは、あるBFRから次のBFRへユニキャストされると仮定する。

一般的に、外側のカプセル化には、「Next Protocol」を識別するコードポイントがある。MPLSの外側のカプセル化の「Next Protocol」コードポイントを使用しなければならない(MUST)。特定の外部カプセル化に「MPLS with downstream-assigned label」用のコードポイントと「MPLS with upstream-assigned label」用のコードポイントがある場合、「MPLS with downstream-assigned label」のコードポイントを使用しなければならない(MUST)。

例えば、BIERパケットがイーサネット・フレームにカプセル化されている場合、イーサタイプは0x8847[RFC5332]でなければならない(MUST)。これは、ラベル・スタックがダウンストリームに割り当てられたラベルで始まるMPLSパケットを伝送するユニキャスト・イーサネット・フレームのEthertypeである。

外側のカプセル化がMPLSである特別なケースでは、外側のカプセル化には「Next Protocol」コードポイントはない。BIERパケットをカプセル化するために必要なのは、BIERパケットのラベル・スタックにさらにMPLSラベル・スタック・エントリ(Sビットがクリアされた状態)をプッシュすることだけである。

2つのBIERパケットがそれぞれのBIERヘッダのエントロピ・フィールドに同じ値を持ち、両方が外側のカプセル化に配置される場合、外側のカプセル化では2つのパケットが同じエントロピを持つという事実を保持することが望ましい。外部カプセル化がMPLSで、MPLSエントロピ・ラベル[RFC6790]が特定の展開で使用されている場合、これを行う1つの方法は、BIERヘッダのエントロピ・フィールドの値をMPLSエントロピ・ラベルにコピーすることである。

2.2. 非MPLSネットワークの場合

2.2.1. カプセル化の最初の4オクテット

2.2.1.1. BIFT-id

非MPLSネットワークでは、そのネットワークで使用される<SD, SI, BSL>の組み合わせに対してBIFT-idを割り当てなければならない(MUST)。BIFT-idと特定の<SD, SI, BSL>トリプルの対応は、BIERドメイン全体でユニークであり、BIERドメイン内のすべてのBFRが知っている。

BIFT-idを割り当てる手段や、これらの割り当てをBFRに知らせる手段は、本文書の範囲外である。

MPLSネットワークでは、BIFT-idはMPLSラベルであるため、BIERパケットがBFRからBFRに移動するときにその値が変更される可能性がある。非MPLSネットワークでは、BIFT-idはドメイン全体でユニークであるため、BIERパケットが移動しても変更されることはない。

2.2.1.2. 最初の4オクテットのその他のフィールド

TC: デフォルトでは、TC フィールドは非MPLSネットワークでは意味を持たない。デフォルトの動作として、このフィールドは送信時にバイナリ値000に設定すべきであり(SHOULD)、受信時には無視しなければならない(MUST)。

非MPLSネットワークにおけるこのフィールドのデフォルト以外の使用は、本文書の範囲外である。

Sビット: Sビットは、非MPLSネットワークでは意味を持たない。送信時には1に設定する必要があるが(SHOULD)、受信時には無視しなければならない(MUST)。

TTL: これはBIERの「Time to Live」フィールドである。このフィールドの目的は、コントロール・プレーンが不適切に動作した場合に、BIERパケットが無限にループするのを防ぐことである。BIERパケットを受信すると、その「受信TTL」(以下を参照)がこのTTLフィールドから取得される。

BIERパケットの処理に対するこのフィールドの影響については、セクション2.1.1.2で説明する。

2.2.2. カプセル化の残り

ニブル: このフィールドは、送信時には0000に設定される必要がある(SHOULD)が、受信時には無視しなければならない(MUST)。

Ver: セクション2.1.2を参照のこと。

BSL: セクション2.1.2を参照のこと。

エントロピー: セクション2.1.2を参照のこと。

OAM: セクション2.1.2を参照のこと。

Rsv: セクション2.1.2を参照のこと。

DSCP: この6ビットのフィールドは、DiffServ (Differentiated Services)コードポイント[RFC2474]を保持するために使用してもよい(MAY)。このフィールドの重要性は、本文書の範囲外である。

プロトコル: セクション2.1.2を参照のこと。

BFIR-id: セクション2.1.2を参照のこと。

BitString: セクション2.1.2を参照のこと。

2.2.3. BIERパケットのさらなるカプセル化

あるBFRから別のBFRにBIER パケットを送信するには、パケットをさらにカプセル化する必要がある可能性がある。例えば、シナリオによっては、BIERパケットをイーサネット・フレームにカプセル化する必要がある。他のシナリオでは、BIERパケットをUDPパケットにカプセル化する必要がある。このような場合、BIERパケット自体は「アウター」カプセル化のペイロードとなる。

本文書では、BIERパケットをペイロードとして伝送するフレームまたはパケットは、ユニキャスト・フレームまたはパケットであると仮定する。つまり、BIERパケットはマルチキャスト・パケットだが、BIERパケットをペイロードとして伝送するフレームまたはパケットは、あるBFRから次のBFRへユニキャストされると仮定する。

一般的に、アウターのカプセル化には、「Next Protocol」を識別するコードポイントがある。このコードポイントには、「非MPLS BIER」を意味する値を設定しなければならない(MUST)。特に、「MPLS」(アップストリーム割り当て、またはダウンストリーム割り当てのラベルを持つ)を意味するコードポイントは使用してはならない(MUST NOT)。

「非MPLS BIER」に対して個別のコードポイントの使用を要求することで、非MPLS BIERが非BIER MPLSと共存できる展開シナリオが可能になる。前者が使用するBIFT-id値は、後者で使用するMPLSラベル値と衝突しない。

したがって、非MPLS BIERパケットがイーサネット・ヘッダにカプセル化する場合、Ethertypeは0x8847または0x8848であってはならない[RFC5332]。IEEEは、非MPLS BIERパケットにEthertype 0xAB37を割り当てた。

アウターのカプセル化がMPLSである特殊な場合、アウターのカプセル化には「Next Protocol」コードポイントがない。BIERパケットのアウターのカプセル化としてMPLSを使用する必要がある場合、BIERにMPLSカプセル化を使用することが推奨される(RECOMMENDED)。非MPLS BIERパケットをMPLSでカプセル化する手順は、本文書の範囲外である。

2つのBIERパケットがそれぞれのBIERヘッダのエントロピー・フィールドに同じ値を持ち、両方がアウターのカプセル化に配置されている場合、アウターのカプセル化では2つのパケットが同じエントロピーを持つという事実を保持することが望ましい。

3. BIERカプセル化の強制と処理

各BFIRは、BIERドメインの最大送信単位(MTU)を認識していることが期待される。これは、プロビジョニングによって、または本文書の範囲外の他の方法によって知ることができる。各BFIRは、BIERカプセル化のサイズも認識している。したがって、各BFIRは、BIERパケットにカプセル化できるペイロードの最大サイズを推定できる。このペイロード・サイズをBIER-MTUと呼ぶ。

BFIRがBIERドメインの外側からマルチキャスト・パケットを受信し、そのパケット・サイズがBIER-MTUを超える場合、BFIRは、すべてのネクストホップに転送するには大き過ぎるマルチキャスト・パケットを受信したときに取るべき適切なアクションを実行する。適切なアクションがパケットをドロップし、送信元にMTUを広告することなら、BFIRはパケットをドロップし、BIER-MTUを広告する。適切なアクションがパケットをフラグメント化なら、このセクションの手順が各フラグメントに順番に適用される。

BFIRがBIERドメインの外からのマルチキャスト・パケット(またはそのフラグメント)を処理する場合、BFIRは以下の手順を実行する。

  1. 「マルチキャスト・フロー・オーバーレイ」[RFC8279]を参照して、プロトコル・フィールドの値を決定する。

  2. マルチキャスト・フロー・オーバーレイを参照して、パケットを受信しなければならないBFERセットを決定する。

  3. 複数のSDがサポートされている場合、BFIRはパケットを特定のSDに割り当てる。パケットに割り当てるSDを決定する手順は、本文書の範囲外である。

  4. BFIRは、それぞれのBFERについて、所定のSDのBFR-idを検索する。

  5. BFIRは、[RFC8279]に記載しているように、そのような各BFR-idを「SI:BitString」形式に変換する。

  6. 同じSIを持つこのようなBFR-idはすべて、同じBitStringにエンコードできる。このエンコーディングの詳細は[RFC8279]を参照のこと。パケットの宛先BFERのリストにある個別のSIごとに対して、次のようになる:

    1. BFIRはマルチキャスト・データパケットのコピーを作成し、そのコピーをBIERヘッダでカプセル化する(セクション2を参照)。BIERヘッダには、(指定されたSD内の)BFR-idが指定されたSIに対応するすべての宛先BFERを表すBitStringを含む。また、パケットが割り当てられたSD内のBFIRのBFR-idも含む。

      ある種のアプリケーションでは、BFIR-idフィールドにヘッダを作成しているBFIR以外のBFRのBFR-idを含める必要があるかも知れないことに留意すること。このような使用法は、本文書の範囲外である。

    2. 次に、BFIRはそのコピーに[RFC8279]のフォワーディング手順を適用する。その結果、パケット(おそらく変更されたBitStringを含む)の1つ以上のコピーが隣接するBFRに送信される可能性がある。

    3. 非 MPLS BIERカプセル化が使用されている場合、BIFT-idフィールドはパケットの<SD, SI, BSL>に対応するBIFT-idに設定される。TTLはポリシーに従って設定される。

      MPLS BIERカプセル化が使用されている場合、BFIRは指定された<SD, SI, BSL>に対応するものとしてネイバーから広告されたBIER-MPLSラベルを見つける。次に、MPLSラベル・スタックがパケットの先頭に追加する。このラベル・スタック[RFC3032]は、前述のBIER-MPLSラベルという1つのラベルを含む。SビットをMPLS ラベル・スタックの終わりを示すために設定されなければならない(MUST)。このラベル・スタック・エントリのTTLフィールドは、ポリシーに従って設定される。

    4. その後、パケットは隣接するBFRに送信される。(MPLSネットワークでは、これにより追加のMPLSラベルがスタックにプッシュされる結果になるかも知れない。例えば、RSVP-TEトンネルが隣接ノードにパケットを送信する場合、そのトンネルを表すラベルがスタックにプッシュされる。)

中間BFRが受信したMPLSパケットを処理しているときに、BFR自身のBIER-MPLSラベルの1つがラベル・スタックの最上位に上がると、BFRはラベルからBSLを推測する。SIとSDもラベルによって暗黙的に識別される。その後、BFRは[RFC8279]の転送手順に従う。隣接するBFRにパケットのコピーをフォワードする場合、BFRはまず、ラベル・スタックの最上位にあるラベルを、同じ<SD, SI, BSL>に対応する、その隣接 BFRによって広告されたBIER-MPLSラベルと交換する。このスワップ操作が行われるとき、送信パケットのBIER-MPLSラベルのTTLフィールドは、セクション2.1.1.2で定義されているように、パケットの「受信TTL」より1つ小さくなければならない(MUST)ことに留意すること。

中間BFRが受信した非MPLS BIERパケットを処理するとき、BFRはBIFT-idからBSLを推測する。SIとSDもBIFT-idによって暗黙的に識別される。その後、BFRは[RFC8279]のフォワーディング手順に従う。

BIERペイロードがMPLSパケットの場合、BIERヘッダの後にMPLSラベル・スタックが続く。このスタックは、BIERヘッダの前に置くMPLS スタックとは別のものである。BIERペイロードとしてMPLSパケットを伝送すると便利なアプリケーションの例については、[BIER_MVPN]を参照すること。BIERカプセル化のプロトコル・フィールドが、ペイロードがスタックの先頭にアップストリーム割り当てラベルを持つMPLSパケットであることを示す場合、アップストリーム割り当てラベルは<BFIR-id, sub-domain-id>の文脈で解釈される。sub-domain-idはBIFT-idから推測しなければならないことに留意する。

4. IANAに関する考慮事項

IANAは「BIER Next Protocol Identifiers」というレジストリを設定した。このレジストリの登録ポリシーは「IETF Review」[RFC8126] [RFC7120] である。

「BIER Next Protocol Identifiers」レジストリの初期値は以下の通りである:

0: 予約済み

1: スタックの一番上にダウンストリーム割り当てラベルを持つMPLSパケット

2: スタックの一番上にアップストリーム割り当てラベルを持つMPLSパケット

3: イーサネット・フレーム

4: IPv4パケット

5: OAMパケット(参照: [BIER_PING])

6: IPv6パケット

63: 予約済み

⚠️ BIER Next Protocol Identifiers (2024.5)
値 説明 参照先
0 予約済み [RFC8296]
1 スタックの一番上にダウンストリーム割り当て
ラベルを持つMPLSパケット		 [RFC8296]
2 スタックの一番上にアップストリーム割り当て
ラベルを持つMPLSパケット		 [RFC8296]
3 イーサネット・フレーム [RFC8296]
4 IPv4パケット [RFC8296]
5 OAMパケット [draft-ietf-bier-ping]
6 IPv6パケット [RFC8296]
7 ペイロードはVXLANでカプセル化されている
(IP/UDPヘッダはない)		 [RFC-ietf-bier-evpn-14]
8 ペイロードはNVGREでカプセル化されている
(IPヘッダはない)		 [RFC-ietf-bier-evpn-14]
9 ペイロードはGENEVEでカプセル化されている
(IP/UDPヘッダはない)		 [RFC-ietf-bier-evpn-14]
10-62 未割り当て
63 予約済み [RFC8296]

5. IEEE の考慮事項

IEEEは、非MPLS BIERパケットにEthertype 0xAB37を割り当てた。

6. セキュリティに関する考慮事項

本文書がMPLSを使用する限り、MPLSデータ・プレーンの使用に適用されるセキュリティの考慮事項はすべて継承する。

BIERカプセル化ヘッダが[RFC8279]および本文書で指定されている以外の方法で変更された場合、パケットは紛失、盗難、または誤配信される可能性がある。BIERカプセル化は暗号化整合性保護を提供しないため、このような変更は検出されない可能性が高い。

レイヤ2暗号化を使用すると、隣接するBFR間の転送中にBIERカプセル化パケットが変更されないようにできる。BFR自体が侵害された場合、侵害されたBFRがBIERヘッダに不正な変更を加えたり、BIERがカプセル化されたパケットを誤転送や誤配信を防ぐ方法はない。

ルーティング・アンダーレイ([RFC8279]のセクション4.1を参照)がユニキャスト・ルーティング・プロトコルに基づいている場合、BIERはユニキャスト・ルーティング・プロトコルに参加しているルータがセキュリティ侵害されていないと仮定する。BIERは、ユニキャスト・ルーティングの隣接関係がセキュリティ侵害されていないことを保証する手順を持たない。これは、どのようなユニキャスト・ルーティング・プロトコルが使われていても、その範囲内に収まる。

BIERカプセル化パケットは、一般に、信頼されていないインタフェースまたはトンネルから受け入れるべきではない。例えば、オペレータは、BIERカプセル化パケットを信頼されたルータへのインタフェースからのみ受け入れ、顧客向けインタフェースからは受け入れないというポリシーを設定することができる。

アプリケーションによっては、ネットワーク・オペレータが制御していないシステムへのインタフェースからBIERカプセル化パケットを受け入れるために、BFRを必要とする場合がある。例えば、データセンターの仮想マシンがBIERカプセル化パケットをルータに送信するアプリケーションが考えられる。このような場合、パケットが正当な送信元からのものであること、そのBitStringがその送信元が送信を許可されているシステムのみを示していることを検証することが望ましい。しかし、BIERカプセル化自体は、送信もとが (1) 正当であるか、(2) 本当にBFIR-idで示されるシステムであるか、(3) BitStringの特定のビットセットを設定することが許可されていることを検証する方法を提供していない。

本文書がIGP拡張に依存している限り、IGPに適用されるセキュリティに関する考慮事項をすべて継承する。

[RFC8279]のセキュリティに関する考慮事項も適用される。

7. 参考文献

7.1. 引用規格

[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>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.

[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>.

[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.

[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[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>.

[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>.

7.2. 参考規格

[BGP_BIER_EXTENSIONS] Xu, X., Ed., Chen, M., Patel, K., Wijnands, IJ., and A. Przygienda, "BGP Extensions for BIER", Work in Progress, draft-ietf-bier-idr-extensions-04, January 2018.

[BIER-PMM] Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Work in Progress, draft-ietf-bier-pmmm-oam-03, October 2017.

[BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Przygienda, "Multicast VPN Using BIER", Work in Progress, draft-ietf-bier-mvpn-09, November 2017.

[BIER_PING] Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", Work in Progress, draft-ietf-bier-ping-02, July 2017.

[ISIS_BIER_EXTENSIONS] Ginsberg, L., Ed., Przygienda, A., Aldrin, S., and J. Zhang, "BIER support via ISIS", Work in Progress, draft-ietf-bier-isis-extensions-06, October 2017.

[OSPF_BIER_EXTENSIONS] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions for BIER", Work in Progress, draft-ietf-bier-ospf-bier- extensions-10, December 2017.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.

謝辞

ラジブ・アサティ、ジョン・ベティンク、ナゲンドラ・クマール、クリスチャン・マーティン、ニール・ランズ、グレッグ・シェパード、ラムジ・ヴァイティアナタン、シャオウ・シュウ、ジェフリー・チャンの、この研究に対するアイデアと貢献に感謝する。

貢献者

次の人物(アルファベット順にリストされている)は、本文書の内容に大きく貢献しており、共著者とみなされるべきである。

マッハ(グオイー)・チェン
Huawei
メール: mach.chen@huawei.com

アルカディ・グルコ
Thomson Reuters
195 Broadway
New York, NY 10007
アメリカ合衆国
メール: arkadiy.gulko@thomsonreuters.com

ヴィム・ヘンデリクス
Nokia
Copernicuslaan 50
Antwerp 2018
ベルギー
メール: wim.henderickx@nokia.com

マーティン・ホーネファー
Deutsche Telekom
Hammer Str. 216-226
Muenster 48153
ドイツ
メール: Martin.Horneffer@telekom.de

ウーヴェ・ジョルデ
Deutsche Telekom
Hammer Str. 216-226
Muenster D-48153
ドイツ
メール: Uwe.Joorde@telekom.de

トニー・プジジエンダ
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, California 94089
アメリカ合衆国
メール: prz@juniper.net

著者のアドレス

イースブランド・ワイナンズ (編集者)
Cisco Systems, Inc.
De Kleetlaan 6a
Diegem 1831
ベルギー
メール:ice@cisco.com

エリック・C・ローゼン (編集者)
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
アメリカ合衆国
メール: erosen@juniper.net

アンドリュー・ドルガノウ
Nokia
438B Alexandra Rd #08-07/10
Alexandra Technopark
Singapore 119968
シンガポール
メール: andrew.dolganow@nokia.com

ジェフ・タンツラ
個人
メール: jefftant.ietf@gmail.com

サム・K・オルドリン
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, California 94043
アメリカ合衆国
メール: aldrin.ietf@gmail.com

イスラエル・メイリク
Broadcom
メール: israel@broadcom.com

更新履歴

  • 2024.4.28
  • 2024.5.7
GitHubで編集を提案

Discussion