RFC 5151：局所的な再最適化は全体の証明ではない

要約

RFC 5151 は AS、IGP area、GMPLS overlay をまたぐ RSVP-TE LSP を扱う。
ingress が方法を制約し、各境界が local policy に従って contiguous、nested、stitched を選ぶ。
境界は loose hop を展開し、内部計算をすべて開示せずに出口を決められる。
機密性が必要なら、特定ノードの PathErr をドメイン全体のエラーへ一般化できる。
許可された crankback を試す間を除き、境界は PathErr を抑止してはならない。
後続試行が成功すれば保持中のエラーを捨て、全失敗なら ingress へ送らなければならない。
RRO の内部 hop はドメイン識別子へ置換または削除できるが、境界自身は隠せない。
フィルタ後も signaling は動く一方、管理診断は不能または複数管理者の協調依存になり得る。
RRO を使う Fast Reroute は label と downstream merge point の情報を失い非効率になり得る。
Notify 宛先の置換は局所対応を早めるが、境界ごとの処理と転送コストを増やす。
bit 4 は contiguous signaling を要求・報告するが、可視性や配送結果までは証明しない。
方法、開示範囲、隠れた経路、再試行、保護、復旧、実トラフィックを別々に記録すべきである。

局所最適は全体の所有者を作らない

contiguous LSP の make-before-break は ingress が開始する。nested または stitched では、ドメイン境界を変えない限り、H-LSP や segment をそのドメインだけで再最適化できる。変更範囲を小さくし、内部運用の裁量を残す設計である。

しかし、ある transit domain が自分のサービス水準を十分と判断して何もしない一方、複数ドメインの累積効果を head end が問題視する場合がある。ingress は end-to-end の再最適化を求められるが、transit domain は無視してもよい。ローカルな再最適化は入出口を固定し、全体操作だけが別の境界を選べる。

したがって、成功を判断する記録には、劣化を見た主体、各区間の所有者、要求と応答、変更前後の経路、実測トラフィックが必要になる。各ドメインの完了通知を足しても end-to-end の性能証明にはならない。

signaling method 自体も分散して決まる

contiguous は全経路で同じ RSVP session と LSP ID を保つ。nested は e2e LSP を H-LSP の中に入れる。stitched は別セッションの segment を結合し、data plane では一つの連続経路を作る。一つの LSP がドメインごとに異なる方法を使うこともできる。

ingress は許容範囲を指定するが、決定を独占しない。各境界が能力と policy を適用する。内部再最適化を自分で制御するため stitching だけを認めるドメインと、全経路を制御するため contiguous を要求する ingress は衝突し得る。その場合、迂回、要件緩和、サービス断念のいずれかになる。

方式の選択は packet format より広い権限配分である。障害時に誰がどの証拠を保有するかも同時に決めなければ、確立済みという一語が責任境界を隠す。

ERO は見えている範囲でだけ具体的になる

境界へ届く Explicit Route Object は、計算手法、TE visibility、以前のノードの policy を反映する。内部ノードを直接指定する ERO をドメインが拒否してもよい。標準的には Inter-domain explicit route rejected を返すが、安全上の理由で Path を黙って破棄したり別のエラーを返したりできる。

次が loose な IP address または AS number なら、境界がローカルに展開する。境界後に subobject がなければ RSVP Session の destination が次の loose hop になる。H-LSP や segment の広告で作られた TE link を ERO が指す場合、通常の contiguous signaling は使えず、能力、要求、policy に従って nesting または stitching を選ぶ。

結果の ERO は、各 authority が外へ出した route description である。内部候補、除外した共有リスク、出口選択の理由を完全には再現しない。

PathErr の粒度は境界で変わる

setup failure の PathErr は ingress へ戻り、途中の各境界を通る。機密性が明示的に必要なら、境界は特定ノードの障害をドメイン全体の一般的なエラーへ置き換えられる。通常ノードは変更すべきでなく、境界も理由なく変更すべきではない。

境界はエラーを単に消してはならない。ただし crankback を試す間は保持できる。別の内部経路または downstream domain が成功すれば保持した PathErr を捨てる。全部失敗すれば上流へ送り、crankback detail を集約してもよい。

ingress にエラーが来ないことは、失敗がなかった証明ではない。再試行中か、別経路が成功した可能性がある。attempt ledger と新しい LSP、data-plane observation を結合して初めて結論になる。

RRO は行政境界だけを残せる

RRO 内の複数の internal hop は一つの AS number へ置換でき、あるいは削除して border nodes だけを残せる。border router 自身は隠せず、RRO に含めなければならない。

RFC 5151 は、この filtering が signaling の動作を妨げないとする。同時に、情報損失が management diagnostics を不能または複雑にし、複数ドメインの管理者協調を必要にすると警告する。規格どおりの RRO は公開可能な骨格を正確に表すが、内部の健全性を表さない。

Fast Reroute は RRO から label と downstream MP を決める。人間の調査だけでなく、automation も開示方針の影響を受ける。

保護経路には隠れた working path が必要になる

bypass tunnel、detour LSP、segment recovery LSP にも border policy と ERO 処理が適用される。backup に loose hop があれば、展開するノードは PLR から MP までの protected path を知り、同じ link、node、SRLG を避けなければならない。

RRO、DETOUR object、route exclusion がその証拠を運ぶ。協調 PCE で計算する方法もある。内部を外に見せないなら、全 hop を公開せず disjointness を検証できる別の trust channel が要る。

backup tunnel が存在するだけでは diversity receipt にならない。protected risk、working path version、exclusion、backup version、実際の切替結果を保持する必要がある。

Notify の局所化は転送責任を増やす

GMPLS Notify は hop-by-hop でなく直接送れる。local protection を行いたい境界は Notify Request の recipient を自分へ書き換えることが推奨される。元は ingress 宛てだった一部の通知は、その後に境界で検査、処理、転送される必要がある。

局所対応は早くなるが、処理と転送のコストはドメイン数に比例して増える。内部で生成した Notify は confidentiality のために filter または modify され得る。

境界の receipt は境界までの配送だけを証明する。元の ingress が同等内容を受け取ったかを示すには、recipient rewrite と各転送を追跡しなければならない。

bit 4 は方式選択の receipt である

ingress は Attributes Flags TLV の bit 4 Contiguous LSP を設定して nesting と stitching を禁止できる。transit node は bit を変更できない。理解しながら contiguous を支援できないノードは Routing Problem value 28 を返す。

対応する境界または loose-hop expander は contiguous に signal し、RRO があれば Attributes subobject で行動を報告する。TLV や bit を知らないノードは object を変更せず転送する。PathErr を受けた ingress の判断は RFC の範囲外である。

この仕組みは要求した construction と応答した behavior を残す。内部 RRO の完全性、failure cause、protection diversity、customer delivery は別の receipt である。

trust は証拠の開示範囲を自動では決めない

inter-domain RSVP-TE を有効にする前に、隣接ドメインの管理者は適切な trust relationship を確認しなければならない。なければ deployment を避け、inter-domain interface で RSVP-TE を無効にすべきである。key coordination、border policy、rate limiting、outbound filtering も必要になる。

これらは signaling と topology exposure を守る。認証された neighbor は、詳細原因の開示、backup の物理分離、Notify の完全転送、data plane の回復まで証明しない。

必要なのは全面公開ではなく、最小共有 evidence、private retention、correlation ID、期限付き escalation の合意である。

各ドメインは自分の区間を最適化した。端から見ると全体は悪化していた。

なぜ重要か

要約

局所最適は全体の所有者を作らない

signaling method 自体も分散して決まる

ERO は見えている範囲でだけ具体的になる

PathErr の粒度は境界で変わる

RRO は行政境界だけを残せる

保護経路には隠れた working path が必要になる

Notify の局所化は転送責任を増やす

bit 4 は方式選択の receipt である

trust は証拠の開示範囲を自動では決めない

情報源

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説