3. 回答

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

1. 割り当てに関する回答は次のとおりである.

   A. 特殊目的 MPLS ラベルの割り当ては Standards Action による.

   B. IANA レジストリを「Special-Purpose MPLS Label Values」に改名する.

   C. Early Allocation は個別に許可できる.

   D. 現行の 16 値の空間は,実験用または私的利用の値を確保するには小さすぎる.ただし,本文書が作成する「Extended Special-Purpose MPLS Label Values」レジストリには十分な空間があり,本文書が実験用範囲を定義する.

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 として確保する (5 節参照).

「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. 特殊目的ラベルの廃止手順

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

a. 「Special-Purpose MPLS Label Values」レジストリから割り当てられた値は,MPLS ワーキンググループ (そのワーキンググループまたは後継が存在しない場合は指定専門家) のレビューを伴う IETF 合意によって非推奨にできる.少なくとも Informational ステータスの RFC が必要である.

その RFC は IANA に対し,レジストリ内で値を「deprecated」と表示するよう指示するが,この段階では値を解放しない.

非推奨とは,非推奨となった値を使用する新たな仕様を今後文書化しないことを意味する.

同時に,これはベンダーに対し新しい実装に非推奨値を含めないこと,運用者に対し新規導入に含めることを避けることを示すものである.

b. 値を非推奨とする RFC の公開から 12 か月後,その非推奨値がまだ使用中かを調べる IETF 全体の調査を実施できる.調査で使用中と判明した場合,さらに 6 か月後に再調査できる.

c. 調査で非推奨値が未使用と判明した場合,その値を非推奨とした RFC の公開から 24 か月後に,非推奨値を廃止する IETF Standards Track Internet-Draft の公開を要求できる.この文書は IANA に対し,将来の利用と割り当てのため値を解放するよう要求する.