RFC 8401: IS-ISによるBit Index Explicit Replication (BIER)のサポート
要旨
本文書では、Bit Index Explicit Replication (BIER)アーキテクチャを使用したマルチキャスト・フォワーディングをサポートするためのIS-IS拡張を定義する。
本文書の位置付け
本文書はインターネット標準化過程の文書である。
本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。
文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc8401 で入手できる。
著作権表示
Copyright (c) 2018 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。
1. はじめに
Bit Index Explicit Replication (BIER)[RFC8279]は、対象となるすべてのマルチキャスト受信者は、[RFC8296]で規定されているような様々なカプセル化内でマルチキャスト・パケット・ヘッダのビットマスクとして符号化されるアーキテクチャを定義している。このようなパケットを受信したルータは、パケット・ヘッダのビット位置に基づいて、パケット内の各ビットについて事前に計算されたツリーに従って、受信者に向けてパケットをフォワードする。各受信者は、ビットマスク内の固有のビットで表される。
本文書は、BIERドメインとサブドメインの運用に必要な情報の配布をサポートするために、現在展開されているIS-IS for IP[RFC1195]に必要な拡張を提示する。本文書では、BIERシグナリングに参加するすべてのルータが広告する新しいTLVを定義する。
本文書は、[RFC8296]で規定されているMPLSカプセル化のサポートを定義する。他のカプセル化タイプのサポートと複数のカプセル化タイプの使用は、本文書の範囲外である。
2. 用語
[RFC8279]で規定されている用語の一部をここに引用し、必要な定義を拡張する:
BIER: Bit Index Explicit Replication。ビット位置を使用してマルチキャストをフォワーディングする全体アーキテクチャ。
BIER-OL: BIERオーバーレイ・シグナリング。BFIRがBFERについて学習する方法。
BFR: ビット・フォワーディング・ルータ。ビット・インデックス・マルチポイント・フォワーディングに参加するルータ。BFRは、BIERドメイン内のユニークなBFRプレフィックスで識別する。
BFIR: ビット・フォワーディング・イングレス・ルータ。BitStringをパケットに挿入するイングレス・ボーダー・ルータ。各BFIRには有効なBFR-idを割り当てなければならない。
BFER: ビット・フォワーディング・エグレス・ルータ。ビット・インデックス・フォワーディングにリーフとして参加するルータ。各BFERはBFRでなければならない。各BFERには有効なBFR-idを割り当てなければならない。
BFT: ドメイン内のすべてのBFERに到達するために使用されるビット・フォワーディング・ツリー。
BIERサブドメイン: ユニークなサブドメイン識別子によって識別されるBIERドメイン内のさらなる区別。BIERサブドメインは、複数のBitString長をサポートできる。
BFR-id: BIERサブドメイン内のBFRのオプションのユニークな識別子。
無効なBFR-id: 未割り当てのBFR-id。この目的のために特別な値0が予約されている。
BAR: BIERアルゴリズム。アンダーレイのネクストホップの計算に使用される。
IPA: IGPアルゴリズム。おそらくBAR値によって定義されるアンダーレイ・パスの計算を修正、強化、または置き換えるために使用される。
SPF: IGPリンク・メトリックに基づくショーテスト・パス・ファースト型ルーティング計算。
2.1. 要件言語
この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。
3. IANAに関する考慮事項
本文書は、「Sub-TLVs for TLVs 135, 235, 236, and 237」レジストリに以下のエントリを追加する。
⚠️ コメント
正しいレジストリ名は「IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability」。
2024.5
| タイプ | 説明 | 27 | 126 | 127 | 135 | 235 | 236 | 237 | 参照先 |
|---|---|---|---|---|---|---|---|---|---|
| 0 | 未割り当て | ||||||||
| 1 | 32ビット管理タグ・サブTLV | y | y | y | y | y | y | y | [RFC5130] |
| 2 | 64ビット管理タグ・サブTLV | y | y | y | y | y | y | y | [RFC5130] |
| 3 | プレフィックス・セグメント識別子 | n | n | n | y | y | y | y | [RFC8667] |
| 4 | プレフィックス属性フラグ | y | y | y | y | y | y | y | [RFC7794] |
| 5 | SRv6エンドSID | y | n | n | n | n | n | n | [RFC9352, Section 7.2] |
| 6 | Flexible Algorithm Prefix Metric (FAPM) | n | n | n | y | y | y | y | [RFC9350, Section 8] |
| 7-10 | 未割り当て | ||||||||
| 11 | IPv4ソース・ルータID | y | y | y | y | y | y | y | [RFC7794] |
| 12 | IPv6ソース・ルータID | y | y | y | y | y | y | y | [RFC7794] |
| 13-31 | 未割り当て | ||||||||
| 32 | BIER情報 | n | n | n | y | y | y | y | [RFC8401] |
| 33-255 | 未割り当て |
値: 32
名前: BIER情報 (BIER Info)
本文書はまた、BIER情報サブTLVのサブサブTLV用の新しいレジストリも導入する。登録ポリシーは、[RFC8126]で定義されている専門家レビューである。「Sub-sub-TLVs for BIER Info Sub-TLV」は「IS-IS TLV Codepoints」レジストリ内に作成された。定義された値は以下のとおりである:
| タイプ | 名前 |
|---|---|
| 1 | BIER MPLSカプセル化 |
IANAは、「Bit Index Explicit Replication (BIER)」レジストリ内に「BIER Algorithms」レジストリを作成した。このレジストリの登録ポリシー[RFC8126]は以下のとおりである。
値0 ～ 127は「標準アクション」となる
値128 ～ 239は「仕様が必須」
値240 ～ 254は 「実験的使用」
「BIER Algorithms」レジストリの初期値は以下のとおりである。
0: BIER固有のアルゴリズムは使用しない
255: 予約済み
⚠️ BIER Algorithmsレジストリ
| 値 | 説明 | 参照先 |
|---|---|---|
| 0 | BIER固有のアルゴリズムは使用しない | [RFC8401] |
| 1-239 | 未割り当て | |
| 240-254 | プライベートまたは実験的使用目的で予約済み | [RFC8401] [RFC9272] |
| 255 | 予約済み | [RFC8401] |
4. コンセプト
4.1. BIERドメインとサブドメイン
IS-ISで伝えられたBIERドメインは、IS-IS内のBFRを識別するBFRプレフィックスの配布範囲に合わせて調整される。このような場合、IS-ISはサポートするBIERアンダーレイとして動作する。
このようなドメイン内で、本文書で定義している拡張は、1つ以上のBIERサブドメインのBIER情報を広告する。各サブドメインは、サブドメインID(SD)によって一意に識別される。各サブドメインは、1つのシングルIS-ISトポロジ(MT)[RFC5120]に関連付けられ、IS-ISがサポートするトポロジのいずれかであってもよい。どの<MT,SD>ペアをルータがサポートするかは、ローカル設定で制御する。サブドメインとトポロジのマッピングは、BIER情報の広告に使用されるIS-ISフラッディング・ドメイン内で一貫していなければならない(MUST)。
各BIERサブドメインは、使用するカプセル化と、BIERフレームのフォワードに使用するツリーのタイプ(現在は常にSPF)を固有の属性として持つ。さらに、サブドメインでサポートされるBitString長ごとに、各ルータはそれをサポートするために必要なラベル範囲を広告する。
4.2. BIER情報の広告
BIER情報の広告は、拡張到達性TLVの新しいサブTLVに関連付けられる。BIER情報は常にホスト・プレフィックスと関連付けられ、これは広告ノードのノード・アドレスでなければならない(MUST)。そうでない場合は、その広告を無視しなければならない(MUST)。したがって、以下の制限が適用される:
-
プレフィックス長は、IPv4プレフィックスの場合は32、IPv6プレフィックスの場合は128でなければならない(MUST)。
-
プレフィックス属性フラグ・サブTLV[RFC7794]が存在する場合、Nフラグを設定しなければならず(MUST)、Rフラグを設定してはならない(MUST NOT)。
-
プレフィックス到達性広告がレベル間で漏洩する場合、BIERサブTLVを含めなければならない(MUST)。
5. 手順
5.1. マルチトポロジとサブドメイン
サブドメインは、1つのトポロジでのみサポートされる。BIERサブTLVのフラッディング範囲内のすべてのルータは、同じマルチトポロジ内で同じサブドメインを広告しなければならない(MUST)。ローカルに設定されたペアと一致しない<MT,SD>広告を受信したルータは、受信した<MT,SD>ペアの設定ミスを報告しなければなりません(MUST)。 競合する<MT,SD>ペアに関連する受信したBIER広告はすべて無視しなければならない(MUST)。このような設定ミスがあると、サブドメインの分裂が発生することに留意する。
例:
次の広告の組み合わせは有効である: <0,0> <0,1> <2,2>
次の広告の組み合わせは無効である: <0,0> <0,1> <2,0>。<0,0>と<2,0>に関連する広告は無視しなければならない。
5.2. BFR-idの広告
BFER/BFIRにBFR-idが設定されている場合、BIER広告でこの値を広告する。BFR-idが設定されていない場合、値「無効なBFR-id」が広告される。有効なBFR-idは、BIER広告のフラッディング範囲内で一意でなければならない(MUST)。すべてのBFER/BFIRは、指定された<MT,SD>に対する重複した有効なBFR-IDの広告を検出しなければならない(MUST)。このような重複が検出された場合、重複を広告しているすべてのルータは、有効なBFR-idを広告していないものとして扱われなければならない(MUST)。これは、その<MT,SD>ではBFERまたはBFIRとして動作できないことを意味する。
5.3. 設定ミスのロギング
本文書で定義されている制約のいずれかに違反する広告を受信した場合は常に、受信ルータはこの発生のログ記録をサポートしなければならない(MUST)。過剰な出力を避けるため、ロギングを抑制する必要がある(SHOULD)。
5.4. フラッディングの軽減
IS-ISが広告するBIERドメイン情報の変更はまれに発生することが想定される。この想定が長時間(数秒を超えるバースト性)満たされない場合、変更はリンクステートPDU(LSP)更新の数が増加し、ネットワークのパフォーマンスに悪影響を及ぼす。実装は、この可能性を、例えば、更新が長期間にわたって発生した場合、更新を抑制するなどして防ぐ必要がある(SHOULD)。
6. パケット・フォーマット
すべてのIS-IS BIER情報は、TLV 235と237[RFC5120]、135[RFC5305]、または236[RFC5308]で配送する。
⚠️ IS-IS拡張
| タイプ | 名前 | 機能 | 伝送 |
|---|---|---|---|
| TLV | 135: Extended IP reachability 235: MT IP. Reach 236: IPv6 IP. Reach 237: MT IPv6 IP. Reach |
135: TE情報を含む、IPv4経路情報 235: MT IPプレフィックス 236: IPv6経路情報 237: MT IPv6プレフィックス |
IS-ISパケット |
| サブTLV | BIER情報サブTLV | BFR-idやサブドメインIDのような情報を広告する | IS-ISパケット内のTLV |
| サブサブTLV | BIER MPLSカプセル化サブサブTLV | BIER MPLSカプセル化情報 | BIER情報サブTLV |
6.1. BIER情報サブTLV
このサブTLVは、ルータがBFRとして参加するBIERサブドメインの情報を伝える。このサブTLVは、あるプレフィックス到達性TLV内で複数回出現してもよい(MAY) ─ 関連するトポロジでサポートされるサブドメインごとに1回。
サブTLVは、次のセクションで説明するように、単一の<MT,SD>の組み合わせと、その後に続くオプションのサブサブTLVを広告する。
タイプ: IANAセクションに示されているとおり。
長さ: 可変
BAR: BIERアルゴリズム。BFERに到達するアンダーレイ・パスの計算に使用されるBIER固有のアルゴリズムを指定する。値は「BIER Algorithms」レジストリから割り当てられる。1オクテット。
IPA: IGPアルゴリズム。 BAR値で定義されたBFERに到達するためのアンダーレイ・パスの計算を修正、強化、置換のためのIGPアルゴリズムを指定する。値はIGPアルゴリズム・レジストリのものである。1オクテット。
サブドメインid: BIERサブドメインを識別するユニークな値。1オクテット。
BFR-id: [RFC8279]に記載されているように、BFR-idを符号化する2オクテットのフィールド。BFR-idが割り当てられていない場合、このフィールドの値は、 [RFC8279]で不正と定義されている「無効なBFR-id」に設定される。
BARフィールドとIPAフィールドのいずれかにゼロ以外の値の使用することは、本文書の範囲外である。実装がこれらのフィールドでのゼロ以外の値の使用をサポートしていないにもかかわらず、これらのフィールドにゼロ以外の値を含むBIER情報サブTLVを受信した場合、その実装は広告ルータをBIERがサポートできないものとして扱う必要がある(SHOULD)。能力のないルータを処理する方法の1つは[RFC8279]のセクション6.9で文書化されており、将来追加の方法が定義されるかも知れない。
6.2. BIER MPLSカプセル化サブサブTLV
このサブサブTLVは、ある<MT,SD>のあるBitString長のラベル範囲を含む、BIER MPLSカプセル化情報を伝送する。これは、BIER情報サブTLV内で広告される(セクション6.1)。このサブサブTLVは、1つのBIER情報サブTLV内に複数回出現してもよい(MAY)。
同じ BitString長が同じBIER情報サブTLV内の複数のサブサブTLVで繰り返される場合、そのBIER情報サブTLVは無視しなければならない(MUST)。
同じBFRが広告するすべてのBIER情報サブTLVにまたがるすべてのBIER MPLSカプセル化サブサブTLV内のラベル範囲は、重複してはならない(MUST NOT)。重複が検出された場合、広告ルータは、BIERサブTLVを広告しないかったものとして扱われなければならない(MUST)。
ラベル値は、[RFC3032]で定義されている予約値のいずれとも一致してはならない(MUST NOT)。
タイプ: MPLSカプセル化を示す値1。
長さ: 4
Max SI: このBitString長、1オクテットに対して、BIERサブドメインのカプセル化で使用される最大セット識別子([RFC8279]のセクション1)。各SIは、ラベル範囲内の1つのラベルにマッピングされる。最初のラベルはSI=0、2番目のラベルはSI=1などである。最大セット識別子に関連付けられたラベルが20ビットの範囲を超える場合、サブサブTLVは無視しなければならない(MUST)。
ローカル・ビット文字列長(BS Len): [RFC8296]に従って符号化されたビット文字列長。4ビット。
ラベル: 範囲の最初のラベル、20ビット。ラベルは[RFC8296]で定義されているとおりである。
7. セキュリティに関する考慮事項
IS-ISのセキュリティに関する懸念は、[RFC5304]と[RFC5310]で取り組まれている。
[RFC8279]のセキュリティに関する考慮事項セクションでは、BIERでカプセル化されたパケットのBitStringに多くのビットを設定することで、サービス拒否(DoS)攻撃が実行される可能性について議論している。ただし、この種のDoS攻撃は、本文書で指定されているIS-IS BIER広告を修正することで開始することはできない。BFIRは、BIERでカプセル化されたパケットを受信するシステムを決定する。この決定を行う際、IS-IS制御メッセージの影響を受けない。カプセル化を作成するとき、BFIRは宛先システムごとにカプセル化に1ビットを設定する。IS-IS BIER広告の情報は、カプセル化の各ビットを、そのビットで識別されるホストのネクストホップ・セットにマッピングするフォワーディング・テーブルを構築するために使用されるが、BFIRがどのビットを設定するかを決定するためには使用されない。したがって、IS-ISのコントロール・プレーンに対する攻撃は、この種のDoS攻撃を引き起こすことはできない。
BIERでカプセル化されたパケットがネットワークを通過する間、BitStringにnビットが設定されたBIERでカプセル化されたパケットを受信したBFRは、パケットを複製して複数のコピーをフォワードする必要があるかも知れない。ただし、特定のビットはパケットの1つのコピーにのみ設定される。これは、受信パケットの送信した複製それぞれは、受信パケットよりも少ないビットが設定されている(つまり、より少ない宛先を対象としている)ことを意味する。これは、[RFC8279]で定義されているBIERフォワーディング・プロセスの重要な特性である。このプロセスの失敗は、([RFC8279]のセキュリティに関する考慮事項で説明されているように)DoS攻撃を引き起こすかも知れないが、そのような失敗がIS-ISのコントロール・プレーンへの攻撃によって引き起こされることはない。
BIER固有のセキュリティに関する考慮事項のさらなる考察は、[RFC8279]を参照のこと。
8. 参考文献
8.1. 引用規格
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[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>.
[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>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, <https://www.rfc-editor.org/info/rfc5308>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[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>.
[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>.
8.2. 参考規格
[OPSFv2BIER] Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2 Extensions for BIER", Work in Progress, draft-ietf-bier-ospf-bier-extensions-18, June 2018.
[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>.
謝辞
このRFCは、プロトコルのメカニズムが重複する限り、「OSPFv2 Extensions for BIER」[OPSFv2BIER]文書と連携している。
ハンネス・グレドラー、イースブランド・ワイナンズ、ピーター・プセナク、クリス・バワーズらのコメント(順不同)に感謝する。
エリック・ローゼンに深く感謝する。
著者のアドレス
レス・ギンズバーグ (編集者)
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
アメリカ合衆国
メール: ginsberg@cisco.com
トニー・プジジエンダ
Juniper Networks
メール: prz@juniper.net
サム・オルドリン
Google
1600 Amphitheatre Parkway
Mountain View, CA
アメリカ合衆国
メール: aldrin.ietf@gmail.com
ジェフリー(ジャオホイ)・チャン
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
アメリカ合衆国
メール: zzhang@juniper.net
更新履歴
- 2024.5.6
Discussion