要約

  • RFC 4090は明示的にルーティングされたRSVP-TE LSPを対象とする。ヘッドエンドは保護を要求し、変更されないFAST_REROUTE制約を入れる。PLRは適格でバックアップ状態が利用可能なLSPについてだけ、バックアップを計算または選択してローカルに起動する。merge pointは元の保護LSPへ再合流させる。
  • 保護ホップの故障時、PLRはデータと制御トラフィックをdetourまたはbypassへ向ける。規範上の目標は数十ミリ秒の再指向である。検出は入力であって、修復経路を選ぶ権限ではない。BFDなどの生存性情報だけでは修復を決定しない。
  • one-to-one detourは保護LSPごとに別のバックアップを作り、状態と資源がLSP数に応じて増える。shared facility bypassは同じ施設とmerge pointを共有する複数の適格LSPを一つのbypassで守るため、構成数を抑えられる一方、容量、merge point、共通障害への依存を共有する。facility bypassではラベルを積層し、PLRが保護LSPのラベルにbypassトンネルのラベルをpushし、merge pointがbypassの文脈を外して元のLSPを継続する。

三者の権限

ヘッドエンドLERだけがFAST_REROUTEオブジェクトを挿入でき、下流LSRは変更してはならない。ヘッドエンドはlocal-protection-desiredまたはFAST_REROUTEでローカル保護を要求し、ラベル記録、link protectionまたはnode protectionも求められる。オブジェクトにはsetup priority、holding priority、requested bandwidth、hop limit、保護方式、affinity／link-attribute filtersが含まれる。RSVP-TEではsetup priorityが新しいセッションによる資源取得と既存予約のpreemptionを決め、holding priorityがその予約を奪われ得るかを決める。帯域がなく、適格な低優先度予約をpreemptできなければPathErrとなる。

PLRの権限は一時的で限定される。node protectionの要否、requested bandwidth、帯域保証の要求、FAST_REROUTEの属性フィルターを確認し、適格なバックアップを計算または選択して故障時に起動する。local-protection-availableは、利用可能なバックアップ経路と必要な転送状態がそろった場合に限り可用性を示す。verified Errata 4203はこの点を明確化している。起動後、PLRはlocal-protection-in-useを示し、PathErrでヘッドエンドへ通知すべきである。ヘッドエンドは広い視野でより適切なLSPを再信令し、グローバルに再最適化する権限を保つ。

merge pointは新しい経路の意思決定者ではない。迂回トラフィックを受け、facility bypassのラベル文脈を除き、保護LSPへ戻す。この役割は、PLRの起動権限、ヘッドエンドの制約設定と全体再最適化の権限とは別である。

方式、回復、更新のトレードオフ

one-to-one方式はLSP単位の意味が明確だが、バックアップ状態、ラベル、信令を増やす。facility方式は構成数を減らすが、一つのbypassの容量、状態清掃、merge point適合性がより多くのLSPに影響する。保護容量は予約済みである場合も、priority規則によりpreempt可能な場合もある。Elias Wardの分析では、速い修復の費用は帯域だけでなく、ラベルスタック、制御面状態、実装互換性、試験範囲であり、共有方式は規模とshared fateを交換する。

RFC 4090はhead-endによるglobal reversionと、PLRで任意に行うlocal reversionを区別し、global revertive modeを推奨する。資源がflapするとlocal reversionは追加の中断を生み得る。事前修復がなければ、ヘッドエンドやルーティングの収束を待つため、より多くのパケット損失と遅い継続性になる可能性がある。他方、制約のない、または古いバックアップ状態は誤った予約を維持し、保護範囲の不足を隠し、二度目の故障で前提を超える可能性がある。

RFC 8796はRFC 4090のfacility backupを更新し、summary-FRR信令によって、一本のbypassを多くのLSPが共有する場合のPLR／merge point間メッセージ交換、制御面の規模と遅延の圧力を減らすことを意図する。RFC 9705はfacility protectionを更新し、状態維持と古い状態の清掃を短い周期refresh timeoutに依存しない方式を追加する。能力、隣接、teardown手順も定める。ただし、これらがすべての実装で利用できるとは限らない。

検証フィクスチャ

  1. 信令フィクスチャ：PATHでFAST_REROUTEがヘッドエンドLERだけから挿入されることを確認し、setup/holding priority、bandwidth、hop limit、保護方式、affinityを記録する。下流による書き換えがないことも確認する。
  2. 資源フィクスチャ：既知容量と優先度のLSPで、十分な帯域、帯域不足、preemption可能、preemption不可を順に試す。成功またはPathErrと、requested bandwidth／holding priorityの結果を照合する。
  3. トポロジーフィクスチャ：保護リンクと保護ノードを別々に切断し、link protectionとnode protectionを混同しないことを確認する。PLR、バックアップnext hop、merge point、ラベルスタックを記録する。
  4. 状態フィクスチャ：バックアップ経路と転送状態がある場合、信令フラグだけで転送状態がない場合を比較し、local-protection-availableを検証する。故障後はlocal-protection-in-use、PathErr、ヘッドエンドの状態を確認する。
  5. 方式フィクスチャ：同じ施設についてone-to-one detourとshared facility bypassを作り、LSPごとの状態、ラベルのpush／pop、共有容量、二度目の故障範囲を比較する。
  6. reversionフィクスチャ：資源回復、短いflap、連続故障を作り、global reversionとPLR local reversionの中断回数および清掃後の古い状態を比較する。
  7. 更新フィクスチャ：RFC 8796 summary-FRRとRFC 9705 refresh-independent手順を、対応ノードと非対応ノードの組み合わせで試し、メッセージ規模、能力交渉、隣接、teardownを観測する。対応を仮定してはならない。

ここまでの事実はRFC Editorの本文とverified errataが直接支える範囲に限る。容量、運用上の誘因、事故時の危険はElias Wardの分析であり、展開の証拠ではない。出典は、特定のベンダー、事業者、トポロジー、現在の余力、実測修復時間、事故、顧客影響を示していない。同時故障、flap、古い状態、混在バージョンの相互運用がどう動くかも未知である。

出典