Zenn
🦔

RFC 8279: Bit Index Explicit Replication(BIER)を使用したマルチキャスト

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

要旨

本文書は、マルチキャスト・データ・パケットのフォワーディングのための新しいアーキテクチャを規定する。これは、「マルチキャスト・ドメイン」を介したマルチキャスト・パケットの最適なフォワーディングを提供する。しかしながら、明示的にマルチキャスト配信ツリーを構築するプロトコルを必要とせず、中間ノードがフローごとの状態を保持する必要もない。このアーキテクチャは、「Bit Index Explicit Replication」(BIER)として知られている。マルチキャスト・データ・パケットがドメインに入ると、イングレス・ルータはパケットの送信先となるエグレス・ルータを決定する。次に、イングレス・ルータはパケットをBIERヘッダにカプセル化する。BIERヘッダには、各ビットがドメイン内のエグレス・ルータを正確に表すビット列が含まれる。あるエグレス・ルータにパケットをフォワードするには、それらのルータに対応するビットがBIERヘッダに設定される。BIERヘッダに基づいてパケットをフォワーディングする手順を本文書で規定する。フローごとの状態と明示的なツリー構築プロトコルを排除することで、大幅に簡素化される。

⚠️ マルチキャストについて

マルチキャストは、特定の複数の受信者に対して同時にパケットを配信する技術。送信者から複数のコピーを送る必要がない点で、ネットワーク全体の負荷を軽減できる点で優れている。現行のマルチキャスト・プロトコルは、送信元から受信者への配信ツリーを、さまざまなシグナリング・プロトコルを介して構成する。

もし、10,000チャンネルのマルチキャスト・フローをサポートする必要があれば、10,000の配信ツリーの状態を各ツリーノードで維持しなければならない。BIERは、この問題に対処する目的で開発された。BIERは、配信ツリーという概念が削除されており、収束が大幅に向上し、効率的にパケットの複製が可能になる。

BIERは、マルチキャスト技術のブレークスルーとして、IETFで迅速に(2017年11月)標準化されたが、実際の展開はかなり遅れている。ルータは新しいカプセル化やフォワーディングのアルゴリズムをサポートする必要があり、それにはBIER機能を組み込んだASICが必要となるため、既存ルータの多くはBIERをサポートできない。

最近になって、BroadcomがJericho2 ASICでBIERをサポートし、大手ベンダーでもBIERの実装が進められている。テスト中も含め、BIERを実装しているベンダーは以下のとおり。

  • ノキア
  • ファーウェイ
  • ジュニパーネットワークス
  • FreeRtr (オープンソース)

ジュニパーネットワークスがノキア、ファーウェイと共に、BIERの相互接続検証を行ったレポートを投稿している。(2024.5.18)

本文書の位置付け

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

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

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

著作権表示

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

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

1. はじめに

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

BIERをサポートするルータは、「Bit-Forwarding Router」(BFR)と呼ばれる。BIERコントロール・プレーン・プロトコル (セクション4.2参照)が「BIERドメイン」内で実行され、そのドメイン内のBFRがBIERを使用して互いにパケットをフォワーディングするために必要な情報が交換できるようになる。

マルチキャスト・データ・パケットは、「Bit-Forwarding Ingress Router」(BFIR)で BIERドメインに入り、1つ以上の「Bit-Forwarding Egress Router」(BFER)でBIERドメインを出る。同じBIERドメイン内の別のBFRからマルチキャスト・データ・パケットを受信し、同じBIERドメイン内の別のBFRにパケットをフォワーディングするBFRは、そのパケットの「トランジットBFR」と呼ばれる。1つのBFRは、マルチキャスト・トラフィックのBFIRであると同時に、マルチキャスト・トラフィックのBFERでもあり、トランジットBFRでもある。実際、あるパケットに対して、BFRは、そのパケットの BFIRおよび/またはトランジット BFRおよび/またはBFER(の1つ)である可能性がある。

⚠️ BIERネットワーク

bier-domain

BIERドメインには1つ以上のサブドメインを含めることができる。各BIERドメインには、「デフォルト・サブドメイン」(「サブドメイン0」とも表記される)というサブドメインを少なくとも1つ持たなければならない(MUST)。BIERドメインに複数のサブドメインが含まれる場合、ドメイン内の各BFRは、属するサブドメインが分かるように、プロビジョニングしなければならない(MUST)。各サブドメインは、[0,255]の範囲のサブドメインIDで識別する。

BFRがBFIRまたはBFERとして動作可能な場合、あるBFRが属する各サブドメインに対して、そのサブドメイン内でユニークな「BFR-id」をプロビジョニングしなければならない(MUST)。BFR-idは構造化されていない小さな正の整数である。例えば、特定のBIERサブドメインに1,374個のBFRが含まれる場合、各BFRには[1,1374]の範囲のBFR-idを与えることができる。

⚠️ BFR-idについて

BFR-idは、BIERサブドメインのエッジルータのIDである。BFIRあるいはBEFRに割り当てるもので、トランジットBFRの役割しかなければ、BFR-idを割り当てる必要はない。

あるBFRが複数のサブドメインに属する場合、(その必要はないが)サブドメインごとに異なるBFR-idを持つことができる。

マルチキャスト・パケットがドメイン外からBFIRに到着すると、BFIRはそのパケットの送信先となるBFERを決定する。BFIRはパケットを送信するサブドメインも決定する。あるパケットを送信するサブドメインを決定することは、「パケットをサブドメインに割り当てること」と呼ぶ。パケットを割り当てるサブドメインを選択する手順は、本文書の範囲外である。ただし、あるパケットがあるサブドメインに割り当てられると、BIERドメインを出るまで、そのサブドメインに割り当てられたままになる。つまり、パケットがBIERドメインを通過中は、パケットが割り当てられているサブドメインを変更してはならない(MUST NOT)。

BFIRがパケットのサブドメインとBFERを決定すると、BFIRはパケットを「BIERヘッダ」でカプセル化する。BIERヘッダはビット列を含み、各ビットは1つのBFR-idを表す。特定のBFERがあるパケットを受信することを示すために、BFIRは、パケットが割り当てられているサブドメインのそのBFERのBFR-idに対応するビットを設定する。BIERヘッダのビット列フィールドを指すために、「BitString」という用語を使用する。「ペイロード」という用語は、カプセル化されたパケットを指すために使用する。したがって、「BIERカプセル化」パケットは、「BIERヘッダ」とそれに続く「ペイロード」で構成される。

⚠️ BIERヘッダとカプセル化について

BIERヘッダは、RFC 8296で規定されている。

bier-header

⚠️ BIERルータとBitString

bier-domain

パケットをフォワーディングできるBFERの数は、BIERヘッダ内のBitStringの長さで制限される。異なる展開では異なるBitString長を使用できる。「BitStringLength」という用語は、BitStringのビット数を指すために使用する。展開によっては、BitStringのビット数よりも多くのBFERがサブドメインに存在する可能性がある。このケースに対応するため、BIERカプセル化にはBitStringと「Set Identfier(セット識別子)」(SI)の両方が含まれる。BitStringとSIの両方が、パケットを配信するBFERを決定する。

⚠️ セット識別子について

BitStringLengthのスケーラビリティを高めるためにあるが、ルータをBIERセット識別子を使ってグループ化し、論理ドメインのような役割を担っているともいえる。1つのセットには、BitStringLengthの長さと同じ数のルータを含む。

一方、BIERサブドメインは、物理的に分離する場合に用いる単位である。

bier-domain

  • 慣例によって、BitStringの最下位(右端)ビットは「ビット1」であり、最上位(左端)ビットは「ビットBitStringLength」である。

  • BIERでカプセル化されたパケットがnのSIを持ち、ビットkが設定されたBitStringを持つ場合、そのパケットは、(そのパケットが割り当てられたサブドメイン内の)BFR-idが「n * BitStringLength + k」であるBFERに配信されなければならない。

例えば、BIERカプセル化が256ビットのBitStringLengthを使用するとする。慣行により、最下位(右端)ビットはビット1、最上位(左端)ビットはビット256である。あるパケットがサブドメイン0に割り当てられ、3つのBFERに配信する必要があるとする。これらのBFERのサブドメイン0のBFR-idは、それぞれ13、126、235である。BFIRは、SIをゼロに設定し、BitStringのビット13、126、235が設定されたBIERカプセル化を作成する。(BitString の他のビットはすべてクリアされる。) BFR-idが257のBFERにもパケットを送信する必要がある場合、BFIRはパケットの2つ目のコピーを作成しなければならず、BIERカプセル化はSIを1、BitStringをビット1に設定し、他のすべてのビットがクリアされたものを指定する。

できるだけ多くのBFERを1つのビット列で表現できるように、サブドメインのBFR-idを割り当てるのが一般的に都合が良い。

あるBFR(「BFR-A」と呼ぶ)が、BIERカプセル化でSIが0、ビット13、26、235が設定されたBitStringを指定するパケットを受信したとする。BFR-AにBFR-BとBFR-Cという2つのBFRネイバーがあり、BFER 13と26への最適パスはBFR-B経由だが、BFER 235への最適なパスはBFR-C経由だとする。次に、BFR-Aはパケットを複製し、1つのコピーをBFR-Bに送信し、もう1つのコピーをBFR-Cに送信する。しかし、BFR-Aは、BFR-Bに送信するパケットコピーのBitStringのビット235をクリアし、BFR-Cに送信するパケットコピーのBitStringのビット13と26をクリアする。その結果、BFR-BはBFER 13と26に向けてのみパケットをフォワーディングし、BFR-Cは BFER 235にのみパケットをフォワーディングする。これにより、各BFERはパケットのコピーを1つだけ受信することが保証される。

BIERでカプセル化されたパケットをBIERドメインにフォワーディングするための詳細な手順は、セクション6を参照のこと。

このフォワーディング手順により、マルチキャスト・データ・パケットは、BFIRから各BFERまで最適なパスをたどることができる。さらに、パケットのBFERはBIERヘッダに明示的に符号化されるため、パケットは受信する必要のないBFERには送信されない。これにより、マルチキャスト・トラフィックの最適なフォワーディングが可能になる。この最適なフォワーディングは、トランジットBFRがフローごとの状態を維持したり、マルチキャスト・ツリー構築プロトコルを実行する必要がなく、実現できる。

マルチキャスト・パケットのヘッダにエグレス・ノードを符号化するというアイデアは新しいものではない。例えば、[Boivie_Feldman]は、エグレス・ノードをIPアドレスとして符号化することを提案しており、現在の文書で説明されているものと似たメカニズムや手順を提案している。ただし、BIERは各BFR-idをビット列の1ビットとして符号化するため、1つのBFERのIPv6アドレスを伝送するのに必要なビット数と同じビット数で、最大128のBFERを表すことができる。そのため、BIERはパケットあたりのエグレス・ノード数を大幅に増やすことができる。

BIERでは、各トランジットBFRがBIERヘッダで識別される各BFERへの最適パスを検索する必要はない。1つのパケットのフォワーディング・パスに必要な検索数は、隣接するBFRの数で制限できる。これはBFERの数よりもはるかに少なくできる。詳細は、セクション6(特にセクション6.5)を参照のこと。

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

2. BFR-idとBFRプレフィックス

各BFRは、属するサブドメインごとに1つの「BFRプレフィックス(BFR-prefix)」を割り当てなければならない(MUST)。BFRのBFRプレフィックスは、BFRのIPアドレス(IPv4またはIPv6のいずれか)でなければならない。BFRプレフィックスはBFRのループバック・アドレスであることが推奨される(RECOMMENDED)。

BFRが複数のサブドメインに属する場合、各サブドメインで異なるBFRプレフィックスを持つことができる(必須ではないが)。

あるサブドメイン内で使用されるすべてのBFRプレフィックスは、同じアドレスファミリ(IPv4またはIPv6のいずれか)に属さなければならない(MUST)。

あるサブドメイン内のあるBFRのBFRプレフィックスは、そのサブドメインでルーティング可能でなければならない(MUST)。あるBFRプレフィックスが与えられたサブドメインでルーティング可能かどうかは、そのサブドメインに関連付けられた「ルーティング・アンダーレイ」によって決まる。「ルーティング・アンダーレイ」の概念については、セクション4.1で説明する。

⚠️ BFR-idの広告

各BFRは、BFR-idとBFRプレフィックスのマッピングを、OSPF/IS-IS/BGPなどを使って、ドメイン内のノードにフラッディングする(セクション5の「BFR-idとBFRプレフィックスの広告」参照)。

「BFR識別子」(BFR-id)は、[1,65535]の範囲の数値である。サブドメイン内で、BFIRまたはBFERとして機能するすべてのBFRは、そのサブドメイン内でユニークに識別する1つのBFR-idを持たなければならない(MUST)。サブドメイン内でBFIRまたはBFERとして機能しないBFRは、そのサブドメインでBFR-idを持つ必要はない。

値0は有効なBFR-idではない。

BFRにBFR-idを割り当てる手順は、本文書の範囲外である。しかし、各サブドメインのBFR-idは、番号空間から「密に(densely)」割り当てることが推奨される(RECOMMENDED)。そうすることで、より効率的な符号化が可能になる(セクション3を参照)。つまり、BFERの数が256以下の場合、すべてのBFR-idを[1,256]の範囲から割り当てることが推奨される(RECOMMENDED)。BFERの数が256を超えて512未満の場合、[1,512]の範囲からすべてのBFR-idを、それ以前の範囲に、できるだけ「穴」を作らないことが推奨される(RECOMMENDED)。しかし、展開によっては、この推奨事項から逸脱した方が有利な場合がある。これについてはセクション3で詳しく説明する。

展開によっては、(サブドメインで)65,535個のBFR-idの全範囲をサポートできない場合がある。例えば、サブドメイン内のBFRが16個のSIしかサポートせず、BFRが256以下のBitStringLengthしかサポートしない場合、そのサブドメインでは16 * 256 = 4,096個のBFR-id しかサポートできない。

3. BitStringでのBFR-idの符号化

BIERデータパケットでBFR-idを符号化するには、BFR-idをSIとBitStringに変換する必要がある。この変換は、「BitStringLength」と呼ぶパラメータに依存する。変換は次のように行われる。BFR-idがNの場合、

  • SIは、(N-1)/BitStringLengthの整数部である。

  • BitStringには1つのビット位置が設定されている。下位ビットがビット1、上位ビットがビットBitStringLengthの場合、BFR-id Nを表すビット位置は((N-1) modulo BitStringLength)+1となる。

⚠️ 符号化の簡単な例

BFR-idが12、BitStringLengthが4の場合、

  • SI = (12-1)/4 = 2
  • N = ((12-1) mod 4)+1 = 3 (0100)

複数の異なるBFR-idをすべて同じSIにする場合、それらのBFR-idはBitStringだけで表すことができる。すべてのBFRのBFR-idのBitStringを表すには、ビット論理OR演算を使用して結合する。

BIERドメイン内(またはBIERサブドメイン内でも)で、異なるBitStringLength値を使用することができる。各BFRは、以下のことを知るためにプロビジョニングしなければならない(MUST)。

  • (BFIRとして)パケットにBIERカプセル化を課すときに使用するBitStringLength (Imposition BitStringLength)とサブドメイン(Imposition sub-domain)、そして、

  • (BFRまたはBFERとして)サブドメインからパケットを受信したときに処理するBitStringLengths (Disposition BitStringLengths)。

BFIRはBIERカプセル化を課すすべてのパケットに対して、同じImposition BitStringLengthまたは同じImposition sub-domainを使用する必要はない。ただし、BFIRがパケットにカプセル化を課すとき、Imposition BitStringLengthとImposition sub-domainを使用するようにプロビジョニングされている場合、そのサブドメイン内のBFR-idを持つ他のすべてのBFRは、受信したBIERパケットを処理するためにプロビジョニングする必要がある(SHOULD)。そのBitStringLengthを持つBIERパケット (つまり、そのサブドメイン内のBFR-idを持つ他のすべてのBFRは、そのサブドメインのDisposition BitStringLengthとして、BitStringLengthをプロビジョニングする必要がある(SHOULD))。特定の条件下では、このルールに対する例外が認められる場合がある。これについてはセクション6.10で説明する。

BIERカプセル化が指定される場合、その仕様はカプセル化のデフォルトBitStringLengthを定義しなければならない(MUST)。そのカプセル化をサポートするすべてのBFIRは、そのデフォルトのBitStringLengthをImposition BitStringLengthとしてプロビジョニングしなければならない(MUST)。そのカプセル化をサポートするすべてのBFRとBFERは、そのデフォルトのBitStringLengthをDisposition BitStringLengthとしてプロビジョニングしなければならない(MUST)。

BIERカプセル化の仕様は、他のBitStringLengthの使用を許可してもよい(MAY)。

BFRが、BitStringLengthの値をImposition BitStringLengthとしてプロビジョニングできる場合、BFRは同じ値をDisposition BitStringLengthの1つとしてプロビジョニングできなければならない(MUST)。それは、(a) Imposition BitStringLengthとして、(b) そのDisposition BitStringLengthの1 つとして、BitStringLengthのそれぞれ適切かつ小さい値でプロビジョニングする必要がある(SHOULD)。

あるBitStringLengthから別のBitStringLengthへの移行をサポートするために、すべてのBFRが2つの異なるDisposition BitStringLengthを同時に使用できるようにプロビジョニングしなければならない(MUST)。

BFRは[0,15]の範囲のSI値をサポートしなければならず(MUST)、[0,255]の範囲のSI値をサポートしてもよい(MAY)。 (この文脈で、「指定された範囲の値をサポートする」とは、指定された範囲内のどの値も正当であり、適切に解釈されることを意味する。) 指定されたBitStringLengthについて、表現できるBFR-idの総数は、BitStringLengthとサポートされるSIの数の積であることに留意すること。例えば、ある展開において(特定のサブドメインで)64のBitStringLengthを使用し、256のSIをサポートする場合、その展開はサブドメインで16,384個のBFR-idしかサポートできない。256個のSIをサポートする展開であっても、少なくとも256のBitStringLengthを使用しない限り、65,535個のBFR-idをサポートすることはできない。

あるサブドメインに割り当てられたマルチキャスト・データ・パケットを特定の宛先BFERセットにフォワーディングする必要があるとBFIRが判断すると、そのBFIRはそのBFERをサブセットに分割し、各サブセットはサブドメインのBFR-idがすべて同じSIになるターゲットBFERとなる。これらをパケットの「SIサブセット」と呼ぶ。各SIサブセットは1つのBitStringで表すことができる。BFIRは、SIサブセットごとにパケットのコピーを作成する。次に、BIERカプセル化が各パケットに適用される。カプセル化では、パケットごとに1つのSIを指定し、対応するSIサブセット内のすべてのBFR-idを表すBitStringを含む。もちろん、BitStringを適切に解釈するには、カプセル化からサブドメインidを推測できなければならない。

例えば、あるBFIRが、あるパケットを3つのBFERにフォワーディングする必要があると判断し、そのBFR-id(適切なサブドメイン内で)が27、235、497であると判断したとする。BFIRは、パケットのコピーを次の2つにフォワーディングしなければならない。SI=0に関連付けられた1つのコピーは、ビット27と235が設定されたBitStringを持つ。SI=1に関連付けられたもう1つのコピーは、ビット241が設定されたBitStringを持つ。

マルチキャスト・パケットから作成するコピー数を最小に抑えるために、サブドメインで使用されるBFR-idを番号空間から「密に」(セクション2を参照)割り当てることが推奨される(RECOMMENDED)。これにより、そのサブドメインで使用する必要があるSIの数を最小限に抑えることができる。しかし、特定の展開の詳細によって、他の割り当て方法の方が有利な場合がある。例えば、ある展開では、すべてのマルチキャスト・フローが「東海岸」または「西海岸」のいずれかに向けられており、両海岸向けではないとする。このような展開では、すべての「西海岸」の BFR-idが同じSIサブセットに分類され、すべての「東海岸」のBFR-idが同じSI-サブセットに分類されるように、BFR-idを割り当てる方が都合がよい。

BFRがBIERデータパケットを受信すると、カプセル化からSIを推測する。次に、パケットのフォワーディング先となるBFERは、SIとBitStringから推測できる。

本文書で後述するいくつかの例では、BitStringLengthを4とし、BFR-idを「SI:xyzw」の形式で表す。ここで、SIはBFR-idのセット識別子(BitStringLengthは4と仮定)、xyzwは4ビットの文字列である。BitStringLength値が4の例でのみ使用する。実際の展開では、BitStringLengthがこれほど小さくなることはない。

複数のさまざまな形式のBIERカプセル化が開発される可能性がある。その場合、特定の展開で使用されるカプセル化は、BIERドメインを実現するために使用されるネットワーク・インフラのタイプによって異なる。BIERカプセル化の詳細については、関連文書で説明する。MPLSネットワークで使用するカプセル化については、[MPLS_BIER_ENCAPS]で説明している。本文書では、非MPLSネットワークで使用できる非常によく似たカプセル化についても説明する。

4. レイヤリング

BIERアーキテクチャは、「ルーティング・アンダーレイ」、「BIER層」、「マルチキャスト層」の3つの層で構成されていると考えると分かり易い。

⚠️ オーバーレイとアンダーレイ

オーバーレイとアンダーレイを視覚化すると次のようになる。

overlay-underlay

基本的にアンダーレイはルーティングを行う実際の物理トポロジ。オーバーレイは、オーバーレイ・プロトコルが設定されたエンド・デバイス間を相互接続する仮想ネットワークである。パケットを見ると、青のフレーム(オーバーレイ)と赤+青のフレーム(アンダーレイ)のように見える。

⚠️ BIERのレイヤリング

bier-layer

4.1. ルーティング・アンダーレイ

「ルーティング・アンダーレイ」は、BFRのペア間の「隣接関係」を確立し、あるBFRからあるBFRへの1つ以上の「最適パス」を決定する。このような各パスは、BFR(k+j)がBFR(k+j+1)に「隣接」するようなBFRのシーケンス「<BFR(k), BFR(k+1), ..., BFR(k+n)>」(0<=j<nの場合)である。

あるBFR(BFR-Aなど)では、BIERドメイン内のBFRのアドレスであるすべてのIPアドレスについて、ルーティング・アンダーレイがそのIPアドレスを1つ以上の「等コスト」隣接セットにマッピングする。BIERデータパケットをBFR-AからあるBFER(例えばBFER-B)にフォワーディングする必要がある場合、パケットはルーティング・アンダーレイによって決定されるBFR-AからBFER-Bへのパスをたどる。

典型的な展開では、ルーティング・アンダーレイは、OSPFのような内部ゲートウェイ・プロトコル(IGP)がユニキャスト・ルーティングに使用するデフォルトのトポロジになることが想定される。この場合、アンダーレイの隣接関係は「単なるOSPF隣接関係」となる。BFR-AからBFER-Bに移動するBIERデータパケットは、OSPFがBFR-AからBFER-Bへのユニキャスト・トラフィックのために選択したパスをたどる。

BFR-AからBFER-Bへのマルチキャスト・トラフィックを、BFR-AからBFER-Bへのユニキャスト・トラフィックが使用するパスとは異なるパスを通過させたい場合は、別のアンダーレイを使用することができる。例えば、マルチトポロジのOSPFを使用する場合、一方のOSPFトポロジをユニキャスト・トラフィックに使用し、もう一方のOSPFトポロジをマルチキャスト・トラフィックに使用することができる。(各トポロジは異なるアンダーレイとみなされる。) もう一つの方法として、ある種のマルチキャスト専用ツリーを作成するルーティング・アンダーレイを展開することもできる。その後、BIERを使用してマルチキャスト・データパケットをマルチキャスト専用ツリーに沿ってフォワーディングし、ユニキャスト・パケットは「通常の」 OSPF最適パスに従う。(このような場合、多くのマルチキャスト・フローが1つのツリーに沿って伝わる可能性があり、特定のパケットによって伝送されるBitStringは、そのパケットを受信する必要があるツリーのノードを識別する。) データパケットのBIERカプセル化から、そのパケットにどのアンダーレイが使用されているかを推測できる限り、BIERが使用する複数のルーティング・アンダーレイを持つことも可能である。

1つのBIERドメインで複数のルーティング・アンダーレイを使用する場合、各BIERサブドメインは1つのルーティング・アンダーレイに関連付けなければならない(MUST)(ただし、複数のサブドメインを同じルーティング・アンダーレイに関連付けることができる)。複数のサブドメインに属するBFRは、各サブドメインでどのルーティング・アンダーレイが使用されているかを分かるようにプロビジョニングしなければならない(MUST)。デフォルトでは(つまり、プロビジョニングとは反対の場合)、各サブドメインはルーティング・アンダーレイとして、ユニキャストIGPのデフォルト・トポロジを使用する。

外部BGP(EBGP)をIGPとして使用するシナリオでは、アンダーレイ隣接関係はデフォルトでBGP隣接関係となる。

ルーティング・アンダーレイのプロトコルと手順の仕様は、本文書の範囲外である。

4.2. BIER層

BIER層は、BIERドメインを横断してマルチキャスト・データパケットをBFIRからBFERに送信するために使用されるプロトコルと手順で構成される。これには以下のコンポーネントが含まれる:

  • あるBFRが同じBIERドメイン内の他のすべてのBFRに広告するために使用するプロトコルと手順:

    • そのBFRプレフィックス;

    • BFR-idがプロビジョニングされている各サブドメインのBFR-id;

    • 各サブドメインで使用するためにプロビジョニングされたDisposition BitStringLengthセット;

    • オプションで、各サブドメインに関連付けられたルーティング・アンダーレイに関する情報。

  • BFIRが、マルチキャスト・データパケットにBIERヘッダを付加するための手順。

  • BIERがカプセル化されたパケットをフォワーディングし、フォワーディング中にBIERヘッダを変更する手順。

  • BFERが、BIERパケットのカプセル化を解除し、適切にディスパッチするために使用する手順。

4.3. マルチキャスト・フロー・オーバーレイ

「マルチキャスト・フロー・オーバーレイ」は、以下の一連の機能を実現するプロトコルと手順で構成される。

  • BFIRがBIERドメイン外からマルチキャスト・データパケットを受信した場合、そのパケットに対するBFERを決定しなければならない。この情報は、マルチキャスト・フロー・オーバーレイによって提供される。

  • BFERがBIERドメイン内からBIERでカプセル化されたパケットを受信した場合、そのパケットをどのようにフォワーディングするかを決定しなければならない。この情報は、マルチキャスト・フロー・オーバーレイによって提供される。

例えば、BFIRとBFERがマルチキャスト仮想プライベート・ネットワーク(MVPN)サービスを提供するプロバイダ・エッジ(PE)ルータだと仮定する。マルチキャスト・フロー・オーバーレイは、[RFC6513]と[RFC6514]で説明するプロトコルと手順で構成されている。これらのRFCで説明しているMVPNシグナリングにより、イングレスPEは、与えられたマルチキャスト・フロー(またはフローセット)のエグレスPEセットを決定することができる。また、バックボーン・ネットワークからのマルチキャスト・パケットの送信先となる「仮想ルーティングとフォワーディング・テーブル」(VRFs)をエグレスPEが決定できるようになる。MVPNシグナリングには、ネットワークを通じてマルチキャスト・データを伝送するために使用される「トンネリング技術」のタイプに応じたいくつかのコンポーネントもある。BIERは事実上、新しいタイプの「トンネリング技術」であるため、マルチキャスト・フロー・オーバーレイとBIER層を適切につなぎ合わせるには、MVPNシグナリングのいくつかの拡張が必要である。これらは[BIER_MVPN]で規定する。

MVPNは、マルチキャスト・フロー・オーバーレイの一例に過ぎない。他のオーバーレイのプロトコルと手順は、関連文書で提供する。「ソフトウェア定義ネットワーク」(SDN)コントローラによってマルチキャスト・フロー・オーバーレイを実装することも可能である。マルチキャスト・フロー・オーバーレイのプロトコルと手順の仕様は、本文書の範囲外である。

5. BFR-idとBFRプレフィックスの広告

セクション2で述べたように、各BFERには(プロビジョニングによって)BFR-idが(与えられたBIERサブドメインに対して)割り当てられる。各BFERは、ドメイン内の他のすべてのBFRにこれらの割り当てを広告する必要がある。同様に、各BFRは(プロビジョニングによって)BFRプレフィックスが(BIERドメインに対して)割り当てられ、この割り当てをドメイン内の他のすべてのBFRに広告しなければならない。最後に、各BFRは、各サブドメインに対して特定のDisposition BitStringLengthセットを使用するようプロビジョニングされており、ドメイン内の他のすべてのBFRにこれらを広告しなければならない。

BIERドメインがリンクステート・ルーティングIGPドメイン(OSPFまたはIS-ISドメイン)でもある場合、BFRプレフィックス、<sub-domain-id, BFR-id>、BitStringLengthの広告は、IGPの広告機能を使用して行うことができる。例えば、BIERドメインがOSPFドメインでもある場合、これらの広告はOSPFの「Opaque Link State Advertising」(Opaque LSA)メカニズムを使用して行うことができる。OSPFとIS-ISに必要な拡張の詳細は、関連文書で提供する。([OSPF_BIER_EXTENSIONS] と[ISIS_BIER_EXTENSIONS]を参照のこと。)

展開によっては、BIERドメインがOSPFまたはIS-ISドメインではない場合、展開に適した手順を使用して、この情報を広告しなければならない。必要な手順の詳細は、関連文書で提供する。例えば、BIERドメインで使用される唯一のルーティング・アルゴリズムがBGPのみなら、[BGP_BIER_EXTENSIONS]の手順を使用することができる。

これらの広告によって、各BFRは<sub-domain-id, BFR-id>をBFRプレフィックスに関連付けることができる。本文書の後続のセクションで説明するように、この関連付けの知識は、フォワーディング・プロセスの重要な部分となる。

各BFRは(各サブドメイン内で)ユニークなBFR-idを持つ必要があるため、プロビジョニング・エラーが発生しない限り、2つの異なるBFRは同じ<sub-domain-id, BFR-id>を広告することはない。

  • BFR-BとBFR-Cの両方が、同じサブドメインに対して同じBFR-idを広告していると、BFR-Aが判断した場合、BFR-Aはエラーをログに記録しなければならない(MUST)。重複するBFR-idが「N」だとする。BFR-AがBFIRとして機能している場合、たとえそのパケットをBFR-Bおよび/またはBFR-Cが受信する必要があると判断した場合でも、与えられたサブドメインに割り当てられたパケットのBIERカプセル化でBFR-id値Nを符号化してはならない(MUST NOT)。

    これは、BFR-BとBFR-Cが、プロビジョニング・エラーが修正されるまで、所定のサブドメインでマルチキャスト・トラフィックをまったく受信できないことを意味する。しかし、この状態は相互にトラフィックを受信するよりも望ましいと考えられる。

  • BFR-Aは特定のサブドメインのBFR-id Nでプロビジョニングされているが、そのサブドメインのBFR-id Nの所有をまだ広告していないとする。また、同じサブドメインのBFR-id Nの所有を広告している別のBFR(例えば、BFR-B)から広告を受信したとする。このような場合、BFR-Aはエラーをログに記録すべきであり(SHOULD)、BFR-Bからの広告が存在する限り、そのサブドメインに対するBFR-id Nの所有を広告してはならない(MUST NOT)。

    この手順により、新しいBFRの偶発的な設定ミスが既存のBFRに影響を与えるのを防げるかも知れない。

BFRが特定のサブドメインでBFR-idが0を持つことを広告する場合、広告を受信する他のBFRは、広告するBFRがそのサブドメインでBFR-idを持たないことを意味するものとして、解釈しなければならない(MUST)。

6. BIERドメイン内のフォワーディング手順

このセクションでは、BIERでカプセル化されたデータパケットをBIERドメイン内でフォワーディングするためのルールを規定する。これらのルールは、実装戦略を規定することを目的としたものではない。この仕様に準拠するには、実装はこれらのルールが生み出す結果と同じ結果を生み出せばよい。

6.1. 概要

このセクションでは、BIERフォワーディング手順の概要を説明する。後続のサブセクションでは、手順を詳細に説明する。

BIERカプセル化パケットをフォワードするには:

  1. パケットのサブドメインを決定する。

  2. パケットのBitStringLengthとBitStringを決定する。

  3. パケットのSIを決定する。

  4. サブドメイン、SI、BitStringから、パケットの宛先BFERセットを決定する。

  5. パケットのサブドメインに関連するルーティング・アンダーレイが提供する情報を使って、各宛先BFERのネクストホップの隣接関係(next-hop adjacency)を決定する。

  6. パケットのBitStringには、使用されていないBFR-idに対応する1つ以上のビットを持つ可能性がある。また、パケットのBitStringが、到達不可能なBFERに対応する1つ以上のビットを持つ可能性もある。つまり、ネクストホップの隣接関係を持たない可能性もある。以下では、そのようなすべてのビット位置の「ネクストホップの隣接関係」を「Null」ネクストホップと考える。

  7. 宛先BFERセットを、1つのパーティション内のすべてのBFERが同じネクストホップを持つようにパーティション化する。各パーティションはネクストホップに関連付けられている。

  8. 各パーティションにおいて:

    a. パケットのコピーを作成する。

    b. パケットのBitStringのうち、パーティションにないBFERを識別するビットをすべてクリアする。

    c. 関連するネクストホップにパケットを送信する。(ネクストホップがNullネクストホップの場合、パケットは破棄される。)

BFRが、<sub-domain, SI, BitString>トリプルがそのBFR自体と認識するBIERカプセル化パケットを受信した場合、そのBFRはそのパケットのBFERでもある。そして、BFERとして、ペイロードをマルチキャスト・フロー・オーバーレイに渡さなければならない。BitStringに他のBFR用のビットが設定されている場合、そのパケットはBIERドメイン内でさらにフォワーディングする必要がある。BF(E)RもBIERドメイン内でパケットの1つ以上のコピーをフォワーディングする場合、BFR自身のBFR-idを表すビットは、すべてのコピーでクリアしなければならない(MUST)。

BFER上のBIER層がパケットをマルチキャスト・フロー・オーバーレイに渡す場合、当然ながら、BIERヘッダを削除してパケットのカプセル化を解除する。ただし、BIERカプセル化から得られるコンテキスト情報をマルチキャスト・フロー・オーバーレイに提供する必要がある場合もある。BIER層とマルチキャスト・フロー・オーバーレイの間で受け渡す必要のある情報は、マルチキャスト・フロー・オーバーレイに固有である。BIER層とマルチキャスト・フロー・オーバーレイ間のインタラクションの仕様は、本仕様の範囲外である。

BIERカプセル化に「Time to Live」(TTL)値が含まれている場合、デフォルトでは、この値はペイロードに継承されない。特定のマルチキャスト・フロー・オーバーレイがTTL値を知る必要がある場合、BIERとそのマルチキャスト・フロー・オーバーレイとの間のインタラクションを定義する何らかの仕様で、TTL値を指定する必要がある。

BIERカプセル化にTraffic Classフィールド、Type of Serviceフィールド、DiffServ(Differentiated Services)フィールド、またはその種のフィールドが含まれている場合、デフォルトでは、そのフィールドの値はマルチキャスト・フロー・オーバーレイに渡さない。特定のマルチキャスト・フロー・オーバーレイがそのようなフィールドの値を知る必要がある場合、BIERとそのマルチキャスト・フロー・オーバーレイの間のインタラクションを定義する仕様にこの事実を指定する必要がある。

BFER上のBIER層がパケットをマルチキャスト・フロー・オーバーレイに渡すと、オーバーレイはパケットをさらにどのようにディスパッチするかを決定する。パケットを別のBIERドメインにフォワードする必要がある場合、BFRは、あるBIERドメインではBFERとして動作し、別のBIERドメインではBFIRとして動作する。

BIERでカプセル化されたパケットは、あるBIERドメインから別のBIERドメインに直接渡すことはできない。BIERドメイン間の境界では、パケットはカプセル化を解除され、マルチキャスト・フロー・オーバーレイに渡さなければならない。

BFRがBIERドメイン内でパケットの複数のコピーを送信する場合、BFERに送信されるコピーは1つだけであることに留意すること。したがって、BIERでカプセル化されたパケットを任意のBFERに複数回配信することはできない。

6.2. BFRネイバー

あるBFR、例えばBFR-Aの「BFRネイバー」(BFR-NBR)は、ルーティング・アンダーレイによれば、BFR-Aの隣接関係にあるBFRである。各BFR-NBRはBFRプレフィックスを持つ。

BIERでカプセル化されたパケットがBFR-Aに到着したとする。BFR-Aはパケットのカプセル化から、(a) パケットのサブドメイン、(b) パケットの宛先となるBFERの(サブドメイン内の)BFR-idを知る。次に、セクション5に従って広告された情報を使用して、BFR-Aは各宛先BFERのBFRプレフィックスを見つけることができる。特定の宛先BFER、例えばBFER-DのBFRプレフィックスが与えられると、BFR-Aは、(パケットのサブドメインに関連付けられた)ルーティング・アンダーレイから、BFR-AからBFER-Dまでのパス上のネクストホップであるBFRのIPアドレスを学習する。このネクストホップを「BFR-B」と呼ぶ。次に、BFR-AはBFR-BのBFRプレフィックスを決定しなければならない。(この決定は、セクション5に従って広告された情報から行うことができる。) このBFRプレフィックスは、BFR-AからBFER-Dへのパス上のBFR-AのBFR-NBRである。

ルーティング・アンダーレイがBFR-AからBFER-Dへの複数の等コストパスを提供する場合、BFR-AはBFER-Dに対して複数のBFR-NBRを持つ可能性があることに留意する。

特定の状況下では、BFRに(特定のルーティング・アンダーレイ内で)BFRではない隣接関係が存在することがある。そのような状況の対処方法については、セクション6.9を参照のこと。

6.3. ビット・インデックス・ルーティング・テーブル(BIRT)

「ビット・インデックス・ルーティング・テーブル」(BIRT)は、BFERのBFR-id(サブドメイン内)とBFERのBFRプレフィックスとそのBFERへのパス上のBFR-NBRに、マッピングするテーブルである。例として、図1に示すトポロジーを考える。この図では、各BFRのBFR-idをセクション3で説明したSI:xyzw形式で表している。

fig1
図1: BIERトポロジ1

このトポロジの結果、BFR-Bでは図2のBIRTが形成される。最初の列には、BFR-idを数値として表示し、BitStringLength 4に対応するSI:BitString形式でも(括弧内に)表示する(実際の最小BitStringLengthは64だが、例では4を使用する)。

BIRTはBIERサブドメインに固有であることに留意すること。

BFR-id
(SI:BitString)		 送信先BFERの
BFRプレフィックス		 BFR-NBR
4 (0:1000) A A
1 (0:0001) D C
3 (0:0100) E E
2 (0:0010) F C

図2: BFR-Bのビット・インデックス・ルーティング・テーブル(BIRT)

6.4. ビット・インデックス・フォワーディング・テーブル(BIFT)

「ビット・インデックス・フォワーディング・テーブル」(BIFT)は、以下のようにBIRTから導出する。(BIFTはサブドメインに固有であることに留意する。)

BIRTの複数の行が同じSIと同じBFR-NBRを持つと仮定する。すると、これらの行のBitStringの論理ORをとることにより、SIとBFR-NBRの組み合わせに対応するビットマスクを取得する。このビットマスクを、<SI, BFR-NBR>の組み合わせに対する「フォワーディング・ビットマスク」(F-BM)と呼ぶ。

⚠️ フォワーディング・ビットマスク

簡単に言えば、F-BMはBFRネイバーの先にある全BIERルータ(全BFR-idのOR演算)である。

bitmask

例えば、図2では、行のうち2つが同じSI(0)と同じBFR-NBR(C)を持っていることが分かる。<SI=0, BFR-NBR-C>に対応するビットマスクは0011 (「0001」と「0010」の論理OR)である。

BIFTは、BFERのBFR-idに対応するF-BMとBFR-NBRへのマッピングに使用する。例えば、図3は、図2のBIRTから導出されるBIFTを示している。BFR-id 1と2は同じSIと同じBFR-NBRを持っていることに留意する。したがって、同じF-BMを持つ。

BFR-id
(SI:BitString)		 F-BM BFR-NBR
1 (0:0001) 0011 C
2 (0:0010) 0011 C
3 (0:0100) 0100 E
4 (0:1000) 1000 A

図 3: ビット・インデックス・フォワーディング・テーブル(BIFT)

このBIFTはデータプレーンにプログラムされ、セクション6.5で後述するルールを適用してパケットをフォワードするために使用される。

6.5. BIERフォワーディング手順

以下は、BFRがBIERカプセル化パケットをフォワーディングするためにBFRが使用する手順である。

  1. パケットのSI、BitStringLength、サブドメインを確認する。
  2. BitStringが完全にゼロの場合、パケットを破棄する。フォワーディング・プロセスの完了とする。それ以外の場合は、手順3に進む。
  3. パケットのBitStringに設定されている最下位ビット(つまり、右端)の位置(「k」と呼ぶ)を見つける。(ビットは1から番号が付けられ、最下位ビットから順に始まることを覚えておくこと。)
  4. ビットkがBFR自体であれば、パケットをコピーし、そのコピーをマルチキャスト・フロー・オーバーレイに送信する。次に、元のパケットのビットkをクリアし、ステップ2に進む。そうでなければ、ステップ5に進む。
  5. 値kを、SI、サブドメイン、BitStringLengthとともに、BIFTへの「インデックス」として使用する。
  6. BIFTからF-BMとBFR-NBRを抽出する。
  7. パケットをコピーする。コピーのBitStringをF-BMとAND演算して更新する(つまり、PacketCopy->BitString &= F-BM)。次に、コピーをBFR-NBRにフォワードする。(BFR-NBRがNullの場合、コピーは破棄される。) パケットがBFR-NBRにフォワードされるとき、そのBitStringは、そのBFR-NBR経由で到達するBFERのみを識別することに留意すること。
  8. ここで、元のパケットのBitStringをF-BMのINVERSE(補数)とAND演算して更新する(つまり、Packet->BitString &= ~F-BM)。(これにより、パケットのコピーがフォワードされたばかりのBFERを識別するビットをクリアする。) ステップ2に進む。
⚠️ BIERフォワーディング

フォワーディング手順例として、BFR-Bの動きを見る。

bier-fowarding

  1. コピーしたパケットのBitStringの最初のビットを見て、1ビット目であることから、id=1のBIFTを検索する。
  2. BFR-idとF-BMのAND演算する(0101 AND 0011 = 0001)。
  3. 演算した結果(0001)をBFR-idとして、NBRのCにフォワードする。
  4. 元のパケットのBitStringとF-BMの補数をAND演算する(0101 AND ~0011 = 0100)
  5. 演算結果(0100)を元のパケットのコピーのBFR-idを更新する
  6. 更新したパケットのBitStringの最初のビットを見て、3ビット目であることから、id-3のBIFTを検索する。
  7. BFR-idとF-BMのAND演算する(0100 AND 0100 = 0100)。
  8. 演算した結果(0100)をBFR-idとして、NBRのEにフォワードする。
  9. 元のパケットのBitStringとF-BMの補数をAND演算する(0100 AND ~0100 = 0000)
  10. BitStringがゼロ(0000)なので、フォワーディング・プロセスを完了する。

この手順により、パケットは特定のBFR-NBRに一度だけフォワードされる。BIFTでの検索数は、パケットをフォワードしなければならないBFR-NBRの数と同じである。宛先BFERごとに個別の検索を行う必要はない。

パケットがBFR-NBRに送信されるとき、変更が必要なBIERヘッダの部分はBitStringだけではない。BIERヘッダにTTLフィールドがある場合、それをデクリメントする必要がある。さらに、[MPLS_BIER_ENCAPS]のカプセル化のいずれかを使用する場合、パケットの送信先となるBFR-NBRからのシグナリングに基づいて、BIFT-idフィールドの変更が必要になる可能性が高い。受信BIERパケットのBIFT-idフィールドは、SI、サブドメイン、BitStringLengthを暗黙的に識別する。パケットが特定のBFR-NBRに送信される場合、BIFT-idフィールドは、そのBFR-NBRが同じ SI、サブドメイン、BitStringLengthに対して広告した値に変更しなければならない。([MPLS_BIER_ENCAPS]のセクション2.1のカプセル化が使用されている場合、これは本質的にMPLSラベルのスワップ操作である。)

BFR-NBRにパケットを送信することが、(上記のルールによって)決定されたとする。そのBFR-NBRが複数の並列インタフェースを介して接続されている場合は、何らかの負荷分散を適用することが望ましい場合もある。負荷分散アルゴリズムは本文書の範囲外である。ただし、パケットのカプセル化にエントロピー・フィールドが含まれている場合、そのエントロピー・フィールドを尊重する必要がある(SHOULD)。エントロピー・フィールドの値が同じ2つのパケットは、(可能であれば)同じインタフェースで送信するべきである(SHOULD)。

場合によっては、ルーティング・アンダーレイは、(異なるBFR-NBRを介して)BFERへの複数の等コストパスを提供することがある。これは「等コストマルチパス」(ECMP)として知られている。ECMPを介した負荷分散をサポートするには、このセクションで説明する手順を拡張(augmented)しなければならない。必要な拡張はセクション6.7を参照のこと。

BFR-NBRへのユニキャスト・トラフィックが何らかの「バイパス・トンネル」を経由して送信される場合、BFR-NBRに送信されるBIERカプセル化されたマルチキャスト・トラフィックもそのトンネルを経由して送信するべきである(SHOULD)。これにより、既存の「高速リルート」スキームをユニキャスト・トラフィックだけでなくマルチキャスト・トラフィックにも適用できる。

これらのフォワーディング手順の例はセクション6.6にある。

このセクションで示されるルールは、以下の疑似コードで表すことができる。

void ForwardBitMaskPacket (Packet)
{
    SI=GetPacketSI(Packet);
    Offset=SI*BitStringLength;
    for (Index = GetFirstBitPosition(Packet->BitString); Index ;
         Index = GetNextBitPosition(Packet->BitString, Index)) {
        F-BM = BIFT[Index+Offset]->F-BM;
        if (!F-BM) continue;
        BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
        PacketCopy = Copy(Packet);
        PacketCopy->BitString &= F-BM;
        PacketSend(PacketCopy, BFR-NBR);
        Packet->BitString &= ~F-BM;
    }
}

図 4: 疑似コード

この疑似コードは、与えられたBFERで、BFER自体のBFR-idに対応するBFR-NBRエントリがBFER自体のBFRプレフィックスになると仮定している。また、対応するF-BMにはBFER自体を表すビットが1つだけ設定されていると仮定する。この場合、「PacketSend」関数はパケットをマルチキャスト・フロー・オーバーレイに送る。

また、この擬似コードは、NullネクストホップのF-BMが、そのビット位置が未使用のBFR-idまたは到達不可能なBFERのいずれかの場合に限り、指定されたビット位置に1を含むと仮定する。BFR-NBRがNullの場合、「PacketSend」関数はパケットを破棄する。

6.6. BIERフォワーディングの例

このセクションでは、図1のトポロジに基づく、BIERフォワーディングの2つの例を示す。これらの例では、すべてのパケットがデフォルトのサブドメインに割り当てられており、すべてのパケットはSI=0が設定されており、BitStringLengthは4である。図5は、SI=0のBIFTエントリのみを示している。簡潔にするために、BIFTの最初の列であるBFR-idを整数で示す。

fig5
図5:フォワーディング例で使用されるBIFT

6.6.1. 例1

BFR-D、BFR-E、BFR-FはBFERである。BFR-AはBFIRである。BFIR-Aがマルチキャスト・フロー・オーバーレイから、BFER-Dが特定のマルチキャスト・フローに関心を持っていることを学習したとする。BFIR-AがBIERドメイン外部からそのフローのパケットを受信すると、BFIR-AはパケットにBIERカプセル化を適用する。カプセル化は、SIがゼロになるようなものでなければならない。カプセル化には、ビット1だけが設定され、他のすべてのビットがクリア(つまり、0001)された BitStringも含まれる。これは、BFER-Dがパケットを受信する必要がある唯一のBFERであることを示す。次に、BFIR-Aはセクション6.5の手順に従う。

  • パケットのBitStringが0001であるため、BFIR-Aは文字列の最初のビットがビット1であることを検出する。BFIR-Aは、そのBIFTのエントリ1を見て、ビットマスクF-BMが0111で、BFR-NBRがBFR-Bであると判断する。

  • 次に、BFR-Aはパケットのコピーを作成し、そのコピーにF-BMを適用する(Copy->BitString &= 0111)。コピーのBitStringは0001になる(0001 & 0111)。

  • コピーがBFR-Bに送信される。

  • BFR-Aは次に、F-BMの補数を適用してパケットのBitStringを更新する(Packet->BitString &= ~F-BM)。その結果、パケットのBitStringは0000 (0001 & 1000)になる。

  • パケットのBitStringがゼロになったので、フォワーディング手順は完了した。

⚠️ 図示

6-6-1-fig1

BFR-BがBFR-Aからマルチキャスト・パケットを受信すると、同じ手順に従う。その結果、BitStringが0001のパケットのコピーがBFR-Cに送信される。BFR-Cは同じ手順を適用し、その結果、BitStringが0001のパケットのコピーをBFR-Dに送信する。

BFER-Dでは、BFR-id 1のBIFTエントリ(図示されていない)は、0001のF-BMとBFR-D自体のBFR-NBRを指定する。これにより、パケットのコピーがBFR-Dのマルチキャスト・フロー・オーバーレイに配信される。パケットのBitStringは0000に設定され、パケットはそれ以上フォワードされない。

6.6.2. 例2

この例は、BFIR-Aがマルチキャスト・フロー・オーバーレイから、BFER-DとBFER-Eがマルチキャスト・フローに関心を持っていることを学習したことを除けば、例1と似ている。BFIR-AがBIERドメインの外部からそのフローのパケットを受信すると、BFIR-AはパケットにBIERカプセル化を適用する。カプセル化は、SIがゼロになるようなものでなければならない。カプセル化には、2つのビットが設定されたBitStringも含まれる。BFR-DがこのパケットのBFERであることを示すために(例1のように)ビット1が設定され、BFR-EがこのパケットのBFERであることを示すためにビット3が設定される。つまり、BitString(BitStringLengthが4であると仮定する)は 0101となる。このパケットをフォワードするため、BFIR-Aはセクション6.5の手順に従う:

  • パケットのBitStringが0101なので、BFIR-Aは文字列の最初のビットがビット1であることを検出する。BIFTのエントリ1を見て、BFR-AはビットマスクF-BMが0111であり、BFR-NBRがBFR-Bだと判断する。

  • BFR-Aはパケットのコピーを作成し、そのコピーにF-BMを適用する: Copy->BitString &= 0111。コピーのBitStringは現在0101(0101 & 0111)となる。

  • コピーがBFR-Bに送られる。

  • BFR-Aは、F-BMの補数を適用してパケットのBitStringを更新する: Packet->BitString &= ~F-BM。その結果、パケットのBitStringは0000(0101 & 1000)となる。

  • パケットのBitStringがゼロになったので、フォワーディング手順は完了した。

BFR-Bは、BFR-Aからマルチキャスト・パケットを受信すると、セクション6.5の手順に従う:

  • パケットのBitStringが0101なので、BFR-Bは文字列の最初のビットがビット1であることを検出する。BIFTのエントリ1を見ると、BFR-BはビットマスクF-BMが0011であり、BFR-NBRがBFR-Cだと判断する。

  • BFR-Bはパケットのコピーを作成し、そのコピーにF-BMを適用する: Copy->BitString &= 0011。コピーのBitStringは現在0001(0101 & 0011)となる。

  • コピーがBFR-Cに送られる。

  • BFR-Bは、F-BMの補数を適用してパケットのBitStringを更新する: Packet->BitString &= ~F-BM。その結果、パケットのBitStringは0100(0101 & 1100)となる。

  • ここで、BFR-Bはパケットの(変更された)BitString内の次のビットを検出する。これはビット3である。BIFTのエントリ3を見ると、BFR-BはF-BMが0100であり、BFR-NBRがBFR-Eだと判断する。

  • BFR-Bはパケットのコピーを作成し、そのコピーにF-BMを適用する: Copy->BitString &= 0100。コピーのBitStringは現在0100(0100 & 0100)となる。

  • コピーがBFR-Eに送られる。

  • BFR-Bは、F-BMの補数を適用してパケットのBitStringを更新する: Packet->BitString &= ~F-BM。その結果、パケットのBitStringは0000(0100 & 1011)となる。

  • パケットのBitStringがゼロになったので、フォワーディング手順は完了した。

⚠️ 図示

BFR-DとBFR-Eに送るケース。

6-6-2-fig1

BFR-DとBFR-EとBFR-Fに送るケース。

6-6-2-fig2

このように、BFR-Bはパケットのコピーを2つフォワードする。BitStringが0001のパケットのコピーが1つ、 BFR-BからBFR-Cに送られた。同じ手順に従って、BFR-CはパケットをBFER-Dにフォワードする。

BFER-Dでは、BFR-id 1のBIFTエントリ(図示されていない)は、0001のF-BMとBFR-D自体のBFR-NBRを指定する。これにより、パケットのコピーがBFR-Dのマルチキャスト・フロー・オーバーレイに配信される。パケットのBitStringは0000に設定され、パケットはそれ以上フォワードされない。

パケットのもう1つのコピーは、BitStringが0100で、BFR-BからBFER-Eに送られる。

BFER-Eでは、BFR-id 3のBIFTエントリ(図示されていない)が0100のF-BMとBFR-E自体のBFR-NBRを指定する。これにより、パケットのコピーがBFR-Eのマルチキャスト・フロー・オーバーレイに配信される。パケットのBitStringは0000に設定され、パケットはそれ以上フォワードされない。

6.7. 等コスト・マルチパス・フォワーディング

多くのネットワークでは、ルーティング・アンダーレイは、BFRからBFERへの複数の等コストパスを提供する。マルチキャスト・パケットをネットワーク経由でフォワーディングする場合、これらのパス間で負荷分散を行うことができれば、これは有益となる。この機能は、「等コスト・マルチパス(ECMP)フォワーディング」と呼ばれる。

BIERはECMPフォワーディングをサポートするが、セクション6.5の手順を若干修正する必要がある。2つのECMP手順が定義されている。1つ目(セクション6.7.1で説明)では、BFRからBFERへのパケットが通過する等コスト・パスの選択は、(a) ルーティング、(b) パケットのエントロピー、および (c) そのパケットの向かう他のBFERに依存する。2つ目の方法(セクション6.7.2で説明)は、選択はパケットのエントロピーのみに依存する。

ここで説明する2つのフォワーディング手順にはトレードオフがある。セクション6.7.1の手順では、パケットの複製数が最小限に抑えられ、BFRのメモリ使用量も少なくなる。セクション6.7.2の手順では、パケットがBFRからBFERへ移動するパスは、そのパケットの宛先である他のBFERから独立している。セクション6.7.2の手順はより多くの複製が発生するかも知れないが、予測可能な動作を提供する。

ここで説明する2つの手順は、同じパケット・フォーマットで動作させても、適切に相互運用できる。ただし、決定論的な動作が必要な場合は、すべてのBFRがセクション6.7.2の手順を使用する必要がある。

6.7.1. 非決定論的ECMP

図6は、BIERにおける非決定論的ECMPの動作を示している。

fig6
図6: 非決定論的ECMPの例

この例では、BFR-BにはBFER-Fに到達するために、BFR-C経由とBFR-E経由の2つの等コスト・パスがある。BFER-FのBFR-idは2なので、これはBFR-BのBIFTのエントリ2に反映される。エントリ2には、BFR-BがBFER-Bに対して、2つのBFR-NBRの選択肢を持ち、各選択肢に異なるF-BMが関連付けられている。BFR-BがBIFTでエントリ2を検索するときに、BFR-NBRのどちらかを選択できる。ただし、セクション6.5の手順に従うと、BFR-Bは選択したBFR-NBRに対応するF-BMを使用しなければならない(MUST)。

どちらを選択するかは実装の問題である。しかしながら、ECMPに関する通常のルールが適用される。あるフローのパケットは2つのパスに分割すべきではなく(SHOULD NOT)、パケットのカプセル化におけるエントロピー・フィールドは尊重すべきである(SHOULD)。

ただし、セクション6.5の規則では、BFER-DとBFER-Fの両方を宛先とするパケットはBFR-C経由で送られることに留意すると。

6.7.2. 決定論的ECMP

ECMPパスが存在するセクション6.7.1の手順では、パケットがBFERに到達するためにたどるパスは、ルーティングとパケットのエントロピーだけでなく、そのパケットの宛先である他のBFERセットにも依存する。

例えば、図6のネットワークにおける以下のシナリオを考える。

  • BFR-Aによって送信されるパケットのシーケンスがあり、そのうちのいくつかはDとFの両方に宛てて送信され、いくつかはFだけに宛てて送信される。

  • このシーケンスのパケットはすべて同じエントロピー値(「Q」と呼ぶ)を持つ。

  • BFR-Bでは、エントロピー値Qを持つパケットがBIFTのエントリ2を経由してフォワードされると、そのパケットはEに送信される。

セクション6.7.1のフォワーディング手順を使用すると、DとFの両方を宛先とするこのシーケンスのパケットは、BIFTのエントリ1に従ってフォワードされ、パスA-B-C-Fを介してFに到達する。しかし、Fのみを宛先とするこのシーケンスのパケットは、BIFTのエントリ2に従ってフォワードされるため、パスA-B-E-Fを経由してFに到達する。

この手順は、BFR-Bが送信するパケット数が最小限に抑えられる。ただし、次のシナリオを考えてみる:

  • 時刻t0以降、問題のマルチキャスト・フローはBFER-Fによってのみ受信する必要がある。

  • その後の時刻t1から、そのフローはBFER-DとBFER-Fの両方で受信する必要がある。

  • より遅い時刻t2から、フローはもはやDによって受信される必要はないが、まだFによって受信する必要がある。

その後、t0からt1まで、フローはパスA-B-E-Fを経由してFに向かう。t1からt2まで、フローはパスA-B-C-Fを経由してFに向かう。そして、t2から、フローは再びA-B-E-Fのパスを経由してFに向かう。

問題は、Dがフローへの参加と離脱を繰り返すと、BからFへのフローのパスが切り替わり続けることである。これにより、Fはパケットを順番通りに受け取れなくなる可能性がある。また、トラブルシューティングも困難になる。例えば、E-Fリンクに何らかの問題が発生した場合、Fの受信者は、フローがDにも向かっているときは(E-Fリンクを避けて)、良好なサービスを受けるが、フローがDに向かっていないときは悪いサービスを受けることになる。ある時点でどのパスが使用されているかを知ることは、トラブルシューティングが困難になる可能性がある。また、任意の時点でフローが通ったパスをたどることが分かるtracerouteを実行するのは非常に難しい。

この難しさの原因は、セクション6.7.1の手順では、フローが特定のBFERに通るパスは、そのフローを受信しているより低い番号のBFERが存在するかどうかに依存することである。したがって、ECMPパスの選択は基本的に非決定論的である。

決定論的フォワーディングは、BIFTの各行には各宛先へのパスが1つだけあるが、特定の宛先への複数のECMPパスが複数のテーブルに拡散するように、複数のBIFTを使用することで実現できる。BIERカプセル化されたパケットがフォワードされるために到着すると、BFRはBIERエントロピー・フィールドのハッシュを使用して、どのBIFTを使用するかを決定し、選択されたBIFTで通常のBIERフォワーディング・アルゴリズム(セクション6.5と6.6で説明)が使用される。

例として、宛先Xへの2つのパスがあり(「X1」と「X2」と呼ぶ)、宛先Yへの4つのパスがあるとする(これらを「Y1」、「Y2」、「Y3」、「Y4」と呼ぶ)。例えば、4つのBIFTがあるとすると、1つのBIFTにはパスX1とY1があり、1つのBIFTにはX1とY2があり、1つのBIFTにはX2とY3があり、もう1つのBIFTにはX2とY4がある。Xへのトラフィックが、これら4つのBIFT間で均等に分割される場合、トラフィックはXへの2つのパス間で均等に分割される。Yへのトラフィックがこれら4つのBIFT間で均等に分割される場合、トラフィックはYへの4つのパス間で均等に分割される。

ある宛先に3つのパスがあり、別の宛先に4つのパスがある場合、これら2つの宛先それぞれへの負荷を均等に分割するためには、12のBIFTが必要になることに留意する。もちろん、各BIFTはある程度のメモリを使用するため、BIFTの数を減らすために最適な分割を少なくしても構わないかも知れない。このトレードオフをどのように行うかは、実装や展開の判断によって決まる。

6.8. ループと重複の防止

BIERカプセル化パケットのBitStringは、そのパケットのフォワード先となるBFERセットを指定する。BIERでカプセル化されたパケットが複製されるとき、そのパケットの2つのコピーが共通のBFERを持つことはない。パケットのBFERの1つがパケットをさらにフォワードする場合、そのBFERはまず自身を識別するビットをクリアする。その結果、BIERではパケットの重複配信は不可能になる。

ルーティング・アンダーレイがBFRの各ペア間にループのないパスを提供している限り、BIERでカプセル化されたパケットはループしない。BIER層はそれ自身のパスを作成しないため、セクション6.5で指定されたフォワーディング手順以外にBIER固有のループ防止技術は必要ない。

ある時点で、ルーティング・アンダーレイがBFIR-AとBFER-Bの間にループのないパスを提供していない場合、BIERでカプセル化されたパケットがBFIR-AからBFER-Bへの移動中にループするかも知れない。ただし、このようなループによってBFER-Bに重複パケットが配信されることはない。

BIERのこれらの特性により、従来のIPマルチキャスト・フォワーディングで使用される「リバースパス・フォワーディング」(RPF)チェックが不要になる。

6.9. 一部のノードがBIERをサポートしていない場合

セクション6.2の手順は、BIERドメイン内で、ルーティング・アンダーレイ内のBFRに隣接するすべてのノードもBFRであることを前提としている。ただし、そうでない場合でも、イングレス・ノードとエグレス・ノードがBFRである限り、BIERを使用することができる。このセクションでは、ルーティング・アンダーレイがSPFベースのIGPで、各ノードからドメイン内の他のすべてのノードへの最短パスツリーを計算する場合に使用できる手順について説明する。

あるBFR(例えば「BFR-B」)で、BFR-Bからドメイン内の各ルータへの、IGPが計算した最短パスツリーのコピーから開始する。(このツリーはIGPのSPFアルゴリズムによって計算される。) このコピーを「BFR-Bをルート(root)とするBIER-SPFツリー」と呼ぶことにする。次に、BFR-BはこのBIER-SPFツリーを以下のように修正する。

  1. BFR-Bは、BIER-SPFツリー上の各子ノードを順番に調べる。

  2. 子ノードの1つがBIERをサポートしていない場合、BFR-Bはそのノードをツリーから削除する。削除されたばかりのノードの子ノードは、ツリー上で再び親になり、BFR-Bがその親ノードになる。

  3. BFR-Bは、前のステップの結果として、BFR-Bの親になったノードを含め、引き続き、その子ノード(すべてのノードを含む)を調べる。

すべての子ノード(元の子ノードと新しい子ノード)が調べられたとき、BIER-SPFツリー上のBFR-Bの子はすべてBFRとなる。

BIFTが構築されると、BIER-SPFツリー上のBFR-Bの子ノードはBFR-NBRとみなされる。F-BMは、BFR-NBRに基づいて適切に計算しなければならない。

BFR-Bには、レイヤ2経由でBFR-Bに「直接接続」されていないBFR-NBRが存在する可能性がある。これらのBFR-NBRのいずれかにパケットを送信するには、BFR-Bはユニキャスト・トンネル経由でパケットを送らなければならない。MPLSネットワークでは、これは子ノードへのIGPユニキャスト・ネクストホップを見つけ、IGPネクストホップが子ノードのアドレスにバインドしたMPLSラベルを(BIERカプセル化ヘッダの上に)プッシュするのと同じくらい簡単かも知れない。(これは、パケットが[MPLS_BIER_ENCAPS]のセクション2.1で指定されているようなMPLSベースのBIERカプセル化を使用していることを前提としている。) もちろん、BIERカプセル化ヘッダ内のBIFT-idは、 パケットのSI、サブドメイン、BitStringLengthの子ノードに対して、子ノードが広告するBIFT-idでなければならない。

何らかの理由でユニキャスト・トンネルをMPLSトンネルにできない場合は、そのトンネル・タイプのカプセル化にペイロードがBIERカプセル化パケットであることを示す方法があれば、他の種類のトンネルを使用できる。

BIERでカプセル化されたパケットがMPLSベースのBIERカプセル化を使用していない場合、そのトンネルがBIERパケットのみを伝送することが分かっていない限り、そのパケットをMPLSトンネルを通して送信することはできないことに留意する。これは、MPLSには「Next Protocol Type (次のプロトコル・タイプ)」フィールドがないためである。MPLSベースのBIERカプセル化が使用されている場合、BIERカプセル化はパケットをBIERカプセル化パケットとして識別するMPLSラベルで始まるため、これは問題にはならない。

もちろん、上記は実装技術を意味するものではなく、単なる機能の説明である。

上記の説明は、ルーティング・アンダーレイがSPFツリーを提供することを前提としているが、他のタイプのルーティング・アンダーレイにも適用できるかも知れない。

上記の技術は、「ノード保護」(つまり、障害が発生したと考えられるノードを高速に迂回する)を提供するために使用することもできる。BFR-Bに障害のあるBFR-NBRがある場合、BFR-Bは障害のあるBFR-NBRをBIER-SPFツリーから削除し、障害のあるBFR-NBRの子BFR-NBRをツリー上のBFR-B自体の子ノードに見える(つまり、BFR-BのBFR-NBRのように見える)ように、再び親になることができる。その後、通常のBIERフォワーディング手順が適用される。ただし、BFR-Bから障害が発生したBFR-NBRの子ノードへのパケットを送信することは、ユニキャスト・バイパス・トンネルを使用して障害が発生したノードを回避する必要があるため、少し複雑になる。

上記のステップ2のより単純な変形は以下のようになる:

子ノードの1つがBIERをサポートしていない場合、BFR-Bはそのノードをツリーから削除する。その子ノードを経由して到達したすべてのBFERはツリー上で再び親になり、BFR-Bがその親になる。

この変形例は、BFR-Bの特定の子ノードを通して到達可能なBFERセットは、BIFTのF-BMから決定できるため、より単純である。しかし、この変形を使用した場合、パケットがBFR-Bから非BIER子ノード経由で到達可能なBFERに直接ユニキャストされるため、結果は最適ではなくなる。

ユニキャストMPLSトンネルを使用してパケットをBFR-NBRに送信する場合:

  • トンネルを表すMPLSラベルエントリのTTLは、BIERカプセル化ヘッダのTTL値からコピーされるのではなく、大きな値に設定すべきである(SHOULD)。

  • トンネルラベルがポップオフされるとき、トンネルラベルのTTLをBIERカプセル化ヘッダにコピーすべきではない(SHOULD NOT)。

言い換えると、トンネルのTTL処理は、「パイプ・モデル」と「ショート・パイプ・モデル」のラベル交換パス(LSP)について[RFC3443]で規定するとおりにすべきである(SHOULD)。トンネルがMPLSトンネルでない場合も、同じ原則が適用される。BIERパケットは、トンネルのカプセル化からTTLを継承すべきではない(SHOULD NOT)。このように、BIERカプセル化ヘッダのTTLは、パケットが通過できるBFRの数だけを制限し、総ホップ数は制限しない。

⚠️ パイプ・モデルとショート・パイプ・モデル

pipe-model

RFC 3443で、MPLSネットワークにおけるMPLSヘッダ(TTL)の振る舞いをパイプ・モデルとショート・パイプ・モデルに大別して規定している。パイプ・モデルはイングレスでのパケット処理時に、IPヘッダのTTLをマッピングせず、MPLSなネットワークから出る際に、元のIPヘッダのTTLに戻る。ショート・パイプ・モデルは、パイプ・モデルを拡張したもので、イングレスでのパケット処理は、パイプ・モードと同じ。エグレスで、ラベルがポップされる。

2つのBIERパケットがそれぞれのBIERヘッダのエントロピー・フィールドに同じ値を持ち、両方が特定のトンネルを経由して送信される場合、トンネルのカプセル化によって2つのパケットが同じエントロピーを持つという事実が保持されることが望ましい。

このセクションの内容は、ルータがBFRの場合、そのすべてのインタフェースでBIERをサポートすることを前提としている。しかし、ルータにはBIERをサポートするラインカードとサポートしないラインカードが搭載されている可能性がある。このような場合、ルータは一部のインタフェースでのみBIERをサポートする「パーシャルBFR」と考えることができる。このような部分的なBFRを展開する必要がある場合は、IGPのマルチトポロジ機能を使用して、BIER固有のトポロジを設定することができる。このトポロジでは、BFRに接続するBIER非対応インタフェースはすべてて除外される。その場合、BIERは、このトポロジにバインドされたサブドメインで実行する必要がある。ユニキャスト・トンネルを使用して非BFRをバイパスする場合、(a) トンネルをこのトポロジに制限するか、(b) トンネルのエンドポイントをBIER非対応インタフェースを持たないBFRにする必要がある。

6.10. ドメイン内で異なるBitStringLengthを使用

このセクションの手順は、BIERドメイン全体で同じカプセル化が使用される場合にのみ適用される。BIERドメインで複数のカプセル化と複数のBitStringLengthの両方が使用されるシナリオの検討は、本文書の範囲外である。

BIERドメイン内の異なるBFRが異なるImpositionおよび/またはDisposition BitStringLengthを使用する可能性がある。セクション3で述べたように:

「BFIRが、特定のパケットセットにカプセル化を適用するときに、特定のImposition BitStringLengthと特定の Impositionサブドメインを使用するようにプロビジョニングされている場合、そのサブドメイン内のBFR-idを持つ他のすべてのBFRは、そのBitStringLengthで受信したBIERパケットを処理するためにプロビジョニングする必要がある(SHOULD)(つまり、そのサブドメイン内のBFR-idを持つ他のすべての BFRは、そのサブドメインのDisposition BitStringLengthとしてそのBitStringLengthをプロビジョニングする必要がある(SHOULD))。

誤ったプロビジョニングは「ブラックホール」になる可能性があることに留意すること。BFIRがBitStringLengthを持つBIERパケットを作成し、そのパケットがそのBitStringLengthを持つ受信BIERパケットを処理できないBFRを通過する必要がある場合、そのBIERヘッダで識別されるすべてのBFERにパケットをフォワードできない可能性がある。セクション6.10.1では、このようなブラックホールの可能性を検出するために使用できる「BitStringLength互換性チェック」という手順を定義している。

ただし、BitStringLengthの互換性チェックに失敗しても、必ずしもブラックホールが生み出されるわけではない。セクション6.10.2では、BitStringLength互換性チェックが失敗しても、ブラックホールなしでBIERフォワーディングを続行できるようにするオプションの手順を規定する。

セクション6.10.2の手順が展開されていないにもかかわらず、BitStringLength 互換性チェックが一部のBFIRで失敗した場合、BFIRには2つの選択肢がある。

  • パケットがそのBitStringで識別されたすべてのBFERに到達できない場合でも、プロビジョニングされたImposition BitStringLengthを使用してBIERパケットを作成する。

  • たとえそれがプロビジョニングされたImposition BitStringLengthでなくても、互換性チェック(互換性チェックがあると仮定して)に合格したImposition BitStringLengthを使用する。

セクション6.10.1では、これらの選択を行った場合の影響について説明する。

オペレータが特定のBIERドメインで使用されるBitStringLengthを変更したい場合がある。セクション6.10.3では、BIERドメインをあるBitStringLengthから別のBitStringLengthに移行するために使用できる簡単な手順を規定している。

6.10.1. BitStringLengthの互換性チェック

BFIRがパケットをカプセル化する必要があるとき、BFIRはまずパケットをサブドメインに割り当てる。次に、BFIRはパケットのImposition BitStringLength Lを選択する。Imposition BitStringLengthの選択は、プロビジョニングによって決定される。ただし、BFIRは、以下に定義するBitStringLengthの互換性チェックも実行する必要がある。

サブドメインSとImposition BitStringLength Lの組み合わせが、BitStringLength互換性チェックに合格するのは、以下の条件が成立する場合のみである:

サブドメインSのメンバーシップを広告したすべてのBFRは、そのサブドメインでDisposition BitStringLength L(場合によっては他のBitStringLengthsも)を使用していることも広告している。(MPLSカプセル化([MPLS_BIER_ENCAPS]のセクション2.1)が使用されている場合、これは、サブドメインSのラベルを広告しているすべてのBFRが、サブドメインSとDisposition BitStringLength Lの組み合わせのラベルを広告していることを意味する。)

BFIRが、あるパケットセットに対して特定のImposition BitStringLengthと特定のサブドメインを使用するようにプロビジョニングされており、そのImposition BitStringLengthとサブドメインの組み合わせがBitStringLength互換性チェックに合格しない場合、BFIRはこの事実をエラーとしてログに記録すべきである(SHOULD)。次に、BFIRはパケットをどうするかについて次の2つの選択肢を持つ:

  1. BFIRはいずれにせよ、プロビジョニングされたImposition BitStringLengthを使用してもよい(MAY)。セクション6.10.2のオプション2またはオプション3の手順が展開された場合、ブラックホールは発生せず、実際には最適な結果かも知れない。しかし、BFIRは、それらの手順が展開されたかどうかをシグナリングで判断できないことを理解する必要がある。

  2. BFIRが、特定のサブドメインのBitStringLength互換性チェックに合格するImposition BitStringLengthを使用できる場合、BFIRは代わりにそのImposition BitStringLengthを使用してもよい(MAY)。

これら2つの選択肢のどちらか選ぶかは、プロビジョニングによって決定する。

パケットを破棄することは許容される選択肢の1つではないことに留意する。例えば、すべてのBFIRが特定のサブドメインSに対してImposition BitStringLength Lを使用するようにプロビジョニングされているが、1つのBFRがサブドメインSに対してDisposition BitStringLength Lを使用するようにプロビジョニングされていないとする。これにより、BitStringLengthの互換性チェックは失敗する。BFIRがBitStringLength LとサブドメインSを持つパケットを送信する場合、誤ってプロビジョニングされたBFRはそれらのパケットをフォワードすることができず、したがって、そのパケットは宛先であるBFERのサブセットにしか到達できないかも知れない。しかし、これはBFIRがパケットを廃棄するよりはまだましである。BFIRがパケットを廃棄した場合、パケットは宛先のBFERのいずれにもまったく到達しない。

セクション6.10.2の手順が導入されていない場合、上記の選択肢2の方が良い選択肢のように思えるかも知れない。しかし、BitStringLength互換性チェックにも合格する、BFIRが使用できるImposition BitStringLengthが存在しないかも知れない。展開で選択肢2を使用することが望まれる場合、そのような「Fallback Disposition BitStringLength」(「F」と呼ぶ)が存在すべきである。

  • すべてのBFRは、すべてのサブドメインのDisposition BitStringLengthとしてBitStringLength Fを使用することを広告する。

  • BFIRが、特定のパケットクラスに対してImposition BitStringLength Xと ImpositionサブドメインSを使用するようにプロビジョニングされているが、BitStringLength XとサブドメインSの組み合わせに対してBitStringLength互換性チェックが失敗した場合、BFIRは、 Impositionサブドメインが Sである場合はいつでも、Imposition BitStringLengthとしてBitStringLength Fを使用するようにフォールバックする。

Fの値が、使用するカプセル化のデフォルトのBitStringLengthにすることが推奨される(RECOMMENDED)。

6.10.2. BitStringLengthの不一致の処理

パケットがBitStringLength値XでBIERカプセル化され、BFR-Aに到着したとする。ここで、ルーティング・アンダーレイによると、ネクストホップはBFR-Bだが、BFR-BはそのDisposition BitStringLengthsの1つとしてXを使っていないと仮定する。BFR-Aはこのパケットをどう処理すべきか? BFR-Aには3つのオプションがある。BFR-Aは3つのうちの1つを実行しなければならないが(MUST)、どの手順に従うかはローカルの問題である。3つのオプションは以下のとおりである:

  1. BFR-Aはパケットを破棄してもよい(MAY)。

  2. BFR-Aは、BFR-BがサポートするBitStringLength値のBIERヘッダを使用して、パケットを再カプセル化してもよい(MAY)。

    BFR-BがパケットのBitStringLength値よりも小さいDisposition BitStringLength値しか使わない場合、パケットの追加コピーの作成する必要があるかも知れないことに留意すること。実際に追加のコピーを作成する必要があるかどうかは、元のパケットのBitStringに実際に設定されているビットによって決まる。

  3. BFR-Aは、BFR-BがBIERをまったくサポートしていないものとしてBFR-Bを扱ってもよい(MAY)。その場合、BFR-Aはセクション6.9のルールを適用する。

BFRが3つのオプションのどれを使用するかを広告できるシグナリングは存在しないことに留意する。

オプション2は、BFRが長いBitStringLengthを使用できるBIERドメインの領域と、短いBitStringLengthしか使用できないBFRの領域が存在する場合に有用である。

6.10.3. あるBitStringLengthから別のBitStringLengthへの移行

BIERドメインで使用されるBitStringLengthを、ある値(X)から別の値(Y)に移行したいとする。次の移行手順を使用できる。この手順では、BFRを一度に1つずつ再プロビジョニングでき、「フラグデイ」を必要としない。

  1. ドメイン内のすべてのBFRをアップグレードし、Disposition BitStringLengthとして値Xと値Yの両方を使用するようにする。

  2. BFIRを、BitStringLength値YをImposition BitStringLengthとして使用するように再プロビジョニングする。

  3. その後、オプションとして、すべてのBFRを再プロビジョニング化し、Disposition BitStringLength Xを使用しないようにすることができる。

7. 運用上の考慮事項

BIERは、ツリー構築コントロール・プレーン、フローごとのフォワーディング状態、リバース・パス・フォワーディング(RPF)、ランデブーポイント(RP)などがないため、現在のIPマルチキャスト運用を大幅に簡素化している。BIERパケットのフォワーディング/複製は、パケットに設定された各ビット位置へのユニキャスト・パスに沿って行われ、カプセル化されたマルチキャスト・パケットがヘッダ内の各設定ビットへのユニキャストと同じパスをたどることを保証する。BIER FIBは、SPFで計算されたユニキャストFIB、または帯域内外の他のフォワーディング・パス計算から導出できる。各ビットは、BIERドメインのエントリポイントから、そのビットが割り当てられたエッジ・デバイスまで、このユニキャスト・パスをたどる。

これらの違いにより、従来のマルチキャスト・ソリューションで期待される運用は、BIERドメインには当てはまらない。ツリーを定義する各ノードには、フローごとの詳細な状態はない。フォワーディング・プレーン・レベル((S,G)エントリ)でのフローの監視は、BIERノードでは提供しない。BIER FIBパケットカウンタは、BFR-idまたはネクストホップ・ネイバーに対して維持されることがある。フローベースのメトリクスは、より深いパケット検査が必要になる。このトピックは本文書の範囲外である。このように、BIERは重ねていうがユニキャストに似ている。

BIERの主要な運用上の利点の1つである決定論的な収束を可能にするのは、この状態の削減である。BIER FIBは、リンクを通過するマルチキャスト・フローの数に関係なく、ユニキャストFIBの直後に収束できる。BIERドメイン内では、(S,G)利用率を注意深く監視する必要はない。

7.1. 設定

BIERドメインでは、各エッジノード(BFER)にBIERマスクのユニークなビット位置(BFR-id) を与える必要がある。BFR-idは各BFERに設定し、そのBFERのユニークなIPアドレスと関連付ける必要がある。既存の手動または自動設定ツールは、BIER固有の設定へのアクセスを提供しなければならない。BFR-idと、それが割り当てられたBFERのユニークなアドレスとの関連付けも、BIERドメインのIGPに広告しなければならない。これは、BIER構成から暗黙的に指定される場合もあれば、IGP固有の設定を必要とする場合もある。本文書は特定の設定方法を規定するものではない。

8. IANA に関する考慮事項

本文書はIANAのアクションを必要としない。

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

BIERが特定のマルチキャスト・フロー・オーバーレイとペアになるとき、そのレイヤのセキュリティ上の考慮事項を継承する。同様に、BIERが特定のルーティング・アンダーレイとペアになると、BIERはそのレイヤのセキュリティ上の考慮事項を継承する。

あるパケットのBIERカプセル化が、BFIRが意図するものとは異なるSIまたはBitStringを指定する場合、そのパケットは誤配信される可能性が高い。パケットのBIERカプセル化が(エラーまたは不正行為によって) 本文書で指定された以外の方法で変更された場合、そのパケットは誤配信される可能性がある。BIERカプセル化の一部の変更(例えば、BitStringのすべてのビットを設定)は、(意図的、意図的でないにかかわらず)サービス拒否(DoS)攻撃を引き起こす可能性がある。

BFIRがセキュリティ侵害された場合、BitStringのすべてのビットが設定されたBIERカプセル化を課す可能性がある。これはDoS攻撃にもつながる可能性がある。

すべてのBFRは、そのインタフェースのどれがBIERドメインにつながり、どれがつながらないかを分かるようにプロビジョニングしなければならない(MUST)。BIERでカプセル化されたパケットをBIERドメインの外部から受け入れてはならない(MUST NOT)。(BIERドメインの外部からBIERでカプセル化されたパケットを受信すると、攻撃者が BitStringのすべてのビットを設定する可能性があるため、DoS攻撃の攻撃ベクトルが作成される。)

2つのインタフェースが異なるBIERドメインにつながる場合、BFRはその2つのインタフェースが異なるBIERドメインにつながることを認識できるようにプロビジョニングしなければならない(MUST)。プロビジョニングが正しくない場合、あるBIERドメインからのBIERカプセル化パケットが別のBIERドメインに「漏洩」する可能性がある。これは、パケットの誤配信が発生する可能性が高い。

DoS攻撃は、BFRの不正なプロビジョニング(エラーまたは不正行為による)からも発生する可能性がある。

BFR-idとBFRプレフィックスの広告に使用される手順が安全でない場合、その手順を攻撃すると、BIERでカプセル化されたパケットが誤配信する可能性がある。

10. 参考文献

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

[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.

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

10.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-03, August 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.

[Boivie_Feldman] Boivie, R. and N. Feldman, "Small Group Multicast", Work in Progress, draft-boivie-sgm-02, February 2001.

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

[MPLS_BIER_ENCAPS] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS Networks", Work in Progress, draft-ietf-bier-mpls- encapsulation-12, October 2017.

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

[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.

謝辞

ラジブ・アサティ、アリア・アトラス、ジョン・ベティンク、ロス・カロン、(決定論的ECMPに関する文章の多くを寄稿してくれた)ナゲンドラ・クマール、クリスチャン・マーティン、ニール・ランズ、アルバート・ティエン、ラムジ・ヴァイティアナタン、シャオウ・シュウ、ジェフリー・チャンらの、この取り組みに対するアイデアと貢献に感謝する。

また、スー・ハレス、ビクター・クアルシン、ダン・ロマスカヌらの本文書のレビューにも感謝する。

貢献者

以下の人々は、本文書の内容に大きく貢献しており、共著者とみなされるべきである:

グレゴリー・コーシー
Bouygues Telecom
メール: gcauchie@bouyguestelecom.fr

マッハ(グオイー)・チェン
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

ルアイ・ジャリル
Verizon
1201 East Arapaho Rd.
Richardson, TX 75081
アメリカ合衆国
メール: luay.jalil@verizon.com

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

グレッグ・シェパード
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
アメリカ合衆国
メール: shep@cisco.com

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

著者のアドレス

イースブランド・ワイナンズ (編集者)
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

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

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

変更履歴

  • 2024.4.26
  • 2024.5.6
  • 2024.5.18: ジュニパーネットワークスのEANTIC BIERの相互接続のレポート
GitHubで編集を提案

Discussion