RFC 7274 - 特殊目的 MPLS ラベルの割り当てと廃止

概要

一部の MPLS ラベルは特定の目的に割り当てられている.このためにラベル 0～15 のブロックが確保され,一般に「予約ラベル」と呼ばれてきた.本文書ではこれらを「特殊目的ラベル」と呼ぶ.

特殊目的ラベルは 16 個しかないため,新しい値の割り当てには慎重さが必要である.一方で,必要な場合には技術の進展を妨げるべきではない.

本文書は,特殊目的ラベルを割り当て,廃止するための新しい手順,特殊目的ラベル空間を拡張する方法,およびデータプレーンで拡張特殊目的ラベルを処理する方法を定義する.また,IANA レジストリを「Special-Purpose MPLS Label Values」に改名し,「Extended Special-Purpose MPLS Label Values」という新しいレジストリを作成する.

本文書は「reserved label」という用語を用いる RFC 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, 6790 を更新する.

本メモの位置付け

本文書は Internet Standards Track 文書であり,IETF コミュニティの合意を表す.公開レビューを受け,IESG によって公開が承認されている.現在の状態,エラッタ,フィードバック方法は http://www.rfc-editor.org/info/rfc7274 を参照されたい.

著作権表示

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

本文書には,公開日時点で有効な BCP 78 および IETF Trust Legal Provisions (http://trustee.ietf.org/license-info) が適用される.本文書から抽出した Code Components には,同規定 4.e 節の Simplified BSD License 文を含めなければならず,同ライセンスに記載されたとおり無保証で提供される.

1. はじめに

MPLS Label Stack Encoding [RFC3032] は,4 個の特殊目的ラベル値 (0～3) を定義し,4～15 を将来の利用のために確保した.これらのラベルはコントロールプレーンとデータプレーンの両方で特別な意味を持つ.その後,値 7, 13, 14 がそれぞれ [RFC6790], [RFC5586], [RFC3429] によって割り当てられ,当初の 16 値のうち未割り当ては 9 値となった.

約 12 年間に残り 12 値のうち 3 値が割り当てられたこと自体は懸念材料ではないが,特殊目的ラベルが希少であることは問題である.さらに,多くの特殊目的ラベルは転送ハードウェアに特別な処理を要求し,その変更は高価で,場合によっては不可能である.したがって,新たに割り当てる値を文書化することが重要である.

本文書は,特殊目的ラベル値の割り当てと廃止に関する問題を整理し,それらに対処する仕組みを定義するとともに,特殊目的ラベル空間を拡張する.

1.1. 本文書で使用する規約

キーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は [RFC2119] の記述に従って解釈する.

本文書では次の 2 つの略語を導入する.

• XL (Extension Label): 後続するラベルが拡張特殊目的ラベルであることを示すラベル.
• ESPL (Extended Special-Purpose Label): XL の直後にラベルスタックへ配置される特殊目的ラベル.XL と ESPL の組は,ラベルスタック中の連続する複数エントリからなる新しい「複合ラベル」とみなせる.

2. 問題点

MPLS 特殊目的ラベルを再検討すると,次の問題が生じる.

1. IANA は特殊目的ラベルの割り当てにどのポリシーを適用すべきか.Early Allocation [RFC7120] を許可すべきか.実験用または私的利用 [RFC5226] の値を設けるべきか.
2. 今後割り当てる特殊目的ラベルには,どのような文書が必要か.
3. 特殊目的ラベルを廃止できるか.どの基準,手順,期間が適切か.廃止した値を別の目的へ再割り当てできるか.
4. 値 3 の Implicit NULL Label [RFC3032] はシグナリングだけで使用され,データプレーンでは使用されない.データプレーンでも利用できるか,また利用すべきか.その場合の目的と方法は何か.
5. 必要になった場合,特殊目的ラベル空間を拡張する実現可能な仕組みは何か.
6. 拡張特殊目的ラベルをロードバランシングに使用すべきか.

3. 回答

前節の問題に対する回答は次のとおりである.

1. 特殊目的 MPLS ラベルの割り当ては Standards Action による.IANA レジストリを「Special-Purpose MPLS Label Values」に改名する.Early Allocation は個別に許可できる.16 値の空間は実験用・私的利用の値を確保するには小さすぎるが,本文書が作成する拡張レジストリには十分な空間があるため,実験用範囲を設ける.
2. Standards Action による割り当て要求には,[RFC5226] に従い Standards Track RFC を添えなければならない.
3. 特殊目的 MPLS ラベル値の廃止は,既存導入環境でその値の利用を孤立させないよう,厳格かつ十分に文書化されたプロセスに従わなければならない.詳細は 3.2 節で定義する.
4. 当面,Implicit NULL Label (値 3) をデータプレーンで使用することは許可しない.この判断を将来再検討する場合,ラベルの用途,シグナリングとデータプレーン間で混乱が生じる原因,およびその緩和策を詳述する Standards Track RFC が必要である.
5. 特殊目的ラベル空間を拡張するため,値 15 を Extension Label (XL) として確保する.詳細は 3.1 節で定義する.
6. [RFC6790] は特殊目的ラベルをロードバランシングに使用してはならない (MUST NOT) と規定する.同じ論理が ESPL にも適用されるため,ESPL をロードバランシングに使用してはならない (MUST NOT).既存実装は XL の後に ESPL が続くことを認識しないため,この規則に反する可能性がある.その結果,同一フローの一部のパケットで ESPL を使用すると異なる経路へ配送され,順序が入れ替わる可能性がある.それでも将来の実装に正しい動作を規定することが重要である.

さらに,通常の特殊目的ラベルが XL の後に置かれた場合にも元の意味を保つかという問題がある.その回答を 3.1 節に示す.

3.1. 拡張特殊目的 MPLS ラベル値

XL の直後には別のラベル L が続かなければならず (MUST),したがって XL の Bottom-of-Stack ビットを設定してはならない (MUST NOT).L は ESPL として,本文書が作成する新レジストリ (5 節) の定義に従って解釈しなければならない (MUST).L の Bottom-of-Stack ビットは,L の後に別のラベルが続くかどうかで決まる.XL が特別な意味を与えるのは L だけである.L の後にあるラベルは通常どおり解析され,通常ラベルまたは特殊目的ラベルになり得る.後者が XL であれば,さらに ESPL が続く.

値 15 を XL として確保する.「Extended Special-Purpose MPLS Label Values」レジストリの 0～15 は予約済みとする.さらに,0～6 および 8～15 は XL の直後にデータプレーン上で現れてはならない (MUST NOT).ラベルスタック先頭の XL に続いてこれらの値を受信した LSR は,パケットを破棄しなければならない (MUST).

ラベル 7 は,通常の特殊目的ラベルとして受信した場合も ESPL として受信した場合も Entropy Label Indicator (ELI) の意味を保つ.これは,直前のラベルが XL かを検証せず ELI を探す既存のコードやハードウェアとの後方互換性のためである.ただし,LSR が Entropy Label を挿入するときは,ELI を ESPL ではなく通常の特殊目的ラベルとして挿入しなければならない (MUST).

3.1.1. 拡張特殊目的ラベルを含むパケットの転送

LSR がスタック先頭で XL に遭遇し,Extension Label を理解しない場合,[RFC3031] の無効な入力ラベルの処理に従ってパケットを破棄しなければならない (MUST).LSR が XL の後のスタック先頭で理解できない ESPL に遭遇した場合も,同じ手順でパケットを破棄しなければならない (MUST).どちらの場合もイベントを記録してよい (MAY) が,ログ出力はレート制限しなければならない (MUST).

LSR はスタック先頭以外のラベルに基づいて転送判断を行うべきではない (SHOULD NOT).ロードバランシングについては 3 節の回答 6 を参照されたい.

3.1.2. 新しい特殊目的ラベルの選択

新しい特殊目的ラベルを割り当てるとき,プロトコル設計者は ESPL を利用できないか検討すべきである.これにより,ラベルスタックの大きさを最小化することが特に重要な用途のために,希少な通常の特殊目的ラベルを温存できる.

3.2. 特殊目的ラベルの廃止手順

完全を期すため次の手順を定義するが,特殊目的ラベルの廃止は困難であり,この手順の利用は最小限にすることを推奨する.

1. 「Special-Purpose MPLS Label Values」レジストリから割り当てられた値は,MPLS ワーキンググループ (存在しない場合は指定専門家) のレビューを伴う IETF 合意によって非推奨にできる.少なくとも Informational ステータスの RFC が必要である.RFC は IANA に値を deprecated と表示するよう指示するが,この段階では値を解放しない.非推奨後はその値を使う新たな仕様を文書化せず,ベンダーは新実装へ含めず,運用者は新規導入での利用を避ける.
2. 非推奨 RFC の公開から 12 か月後,その値がまだ使用中かを調べる IETF 全体の調査を実施できる.使用中であれば,さらに 6 か月後に再調査できる.
3. 調査で未使用と判明した場合,非推奨 RFC の公開から 24 か月後に,値を廃止する Standards Track Internet-Draft の公開を要求できる.この文書は IANA に,将来の利用と割り当てのため値を解放するよう要求する.

4. 更新される RFC

次の RFC にある「reserved labels」への参照は,すべて「special-purpose labels」と読み替える.

• [RFC3032] MPLS Label Stack Encoding
• [RFC3038] VCID Notification over ATM link for LDP
• [RFC3209] RSVP-TE: Extensions to RSVP for LSP Tunnels
• [RFC3811] Definitions of Textual Conventions for MPLS Management
• [RFC4182] Removing a Restriction on the Use of MPLS Explicit NULL
• [RFC4928] Avoiding Equal Cost Multipath Treatment in MPLS Networks
• [RFC5331] MPLS Upstream Label Assignment and Context-Specific Label Space
• [RFC5586] MPLS Generic Associated Channel
• [RFC5921] A Framework for MPLS in Transport Networks
• [RFC5960] MPLS Transport Profile Data Plane Architecture
• [RFC6391] Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
• [RFC6478] Pseudowire Status for Static Pseudowires
• [RFC6790] The Use of Entropy Labels in MPLS Forwarding

5. IANA に関する考慮事項

IANA は MPLS ラベル登録に次の変更を行った.

1. 「Multiprotocol Label Switching Architecture (MPLS) Label Values」を「Special-Purpose MPLS Label Values」に改名した.
2. 同レジストリの割り当てポリシーを Standards Action に変更した.
3. 値 15 を「Extension Label」として割り当て,本文書を参照先とした.
4. 「Extended Special-Purpose MPLS Label Values」レジストリを作成した.登録手順は Standards Action であり,[RFC7120] による Early Allocation は Standards Action で割り当てる値に限って許可される.

範囲	割り当てポリシー
0～15	予約済み.割り当て不可
16～239	未割り当て
240～255	実験用に予約
256～1048575	予約済み.割り当てポリシーを定義する新たな Standards Track RFC なしには割り当て不可

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

本文書は MPLS データプレーンの動作を大きく変更しないため,セキュリティ上の考慮事項は MPLS Architecture [RFC3031] および MPLS and GMPLS Security Framework [RFC5920] とほぼ同じである.

ただし,ラベルスタックを増やすとパケットの断片化を引き起こし,一部の実装で処理不能になる可能性がある.本文書は,単一の不正ラベルを挿入する場合より高い割合で追加の {XL, ESPL} ペアを挿入し,プロトコル上合法的にスタックを増やす方法を提供する.これは,一定の大きさまでしかラベルスタックを処理できないノードに対し,プロトコル規則に違反せず攻撃する手段となる可能性がある.

また,本文書には LSR がパケットごとの頻度でイベントログを出す原因となる事象がある.実装がこのログをレート制限することは極めて重要である.

7. 謝辞

有益な議論を行った Pablo Frank と Lizhong Jin,ならびに有益なコメントを寄せた Curtis Villamizar, Mach Chen, Alia Atlas, Eric Rosen, Maria Napierala, Roni Even, Stewart Bryant, John Drake, Andy Malis, Tom Yu に感謝する.

8. 参考文献

8.1. 規範的参考文献

[RFC2119], [RFC3031], [RFC3032], [RFC3038], [RFC3209], [RFC3811], [RFC4182], [RFC4928], [RFC5226], [RFC5331], [RFC5960], [RFC6391], [RFC6478], [RFC6790], [RFC7120].書誌情報と正式な表題は各 RFC を参照されたい.

8.2. 参考文献

[RFC3429], [RFC5586], [RFC5920], [RFC5921].

著者の連絡先

• Kireeti Kompella, Juniper Networks, [email protected]
• Loa Andersson, Huawei, [email protected]
• Adrian Farrel, Juniper Networks, [email protected]