要約

  • RFC 3469はMPLS復旧を、障害検出、待機、通知、復旧操作、そして実際のトラフィック到着という別々の時間に分けた。
  • あらかじめ設定された保護経路でも、同じ故障要因を共有し、帯域を予約しておらず、限定的な品質しか出せず、切替後に無保護状態を残すことがあった。

運用画面には二本の線があった。一本は稼働経路、もう一本は保護経路。ところがリンクが切れた瞬間、その図からは、保護経路が同じ管路を通っているのか、必要な帯域があるのか、どの装置が切替を命じるのか、パケットがいつ再び届くのかが分からなかった。

2003年2月のRFC 3469は、この空白を「復旧フレームワーク」として整理したInformational RFCである。一つの実装方式を標準化した文書ではなく、再起動問題も対象外だった。歴史的な価値は、復旧という一語を、別々の主体が観測しなければならない出来事へ分解した点にある。

最初の区別は、再ルーティングと保護切替だった。再ルーティングは故障後に新しい経路または区間を作る。保護切替は故障前に用意した回復経路を使う。両者は排他的ではない。まず準備済みの迂回路に素早く移し、半安定状態で時間を稼ぎ、ルーティング収束後により適切な新しい稼働経路へ移すことができる。

ここで、経路が「存在する」ことの弱さが現れる。事前確立された経路でも、稼働経路と故障リンクやノードを共有することがある。ラベルは設定済みでも帯域やバッファは予約されていないかもしれない。別用途の経路を事前審査しただけの場合もある。同じ物理障害で二本とも失われれば、管理データ上の冗長性は何も運ばない。

RFC 3469の最初の復旧サイクルには五つの区間がある。T1は障害発生から検出まで。T2は下位層などに時間を与える待機。T3は故障指示信号が修復権限を持つPath Switch LSRへ届くまで。T4はPath Merge LSRとの調整を含む復旧操作。T5は最後の操作が終わってから、途絶した地点へトラフィックが完全に戻るまでである。

T5は制御面中心の指標に対する重要な反論だった。切替コマンドの完了は、パケットの復帰ではない。パケットは伝播中かもしれず、キューで詰まり、破棄され、順序を変え、帯域不足と競合しているかもしれない。復旧時計は設定変更ではなく、データ面の観測で止める必要がある。

しかも初期復旧は終点ではない。復帰サイクルでは、故障原因の修理、クリア検出、安定性を見る待機、クリア通知、復帰操作、優先経路でのトラフィック復元を分ける。修理直後の経路が不安定なら、即時の切り戻しは二度目の障害を作る。make-before-breakは損失や並べ替えを減らせるが、完了確認を不要にはしない。

動的再ルーティングには別のサイクルがある。ネットワークが半安定状態に入り、ルーティングが収束し、必要なら有限のhold-downを置き、新しい稼働経路を設定して、もう一度トラフィックを移す。高速保護は最終形を保証する機能ではなく、最終形を安全に作る時間を買う機能だった。

経路設定と資源確保も別軸である。回復経路は事前確立、事前認定、オンデマンド確立のいずれでもよい。資源は事前予約しても、故障後に予約してもよい。RFC 3469は、元の性能保証を維持できるものをequivalent recovery path、維持できないものをlimited recovery pathと呼んだ。限定経路は無通信より有用だが、長期利用を前提にしていない。

1+1保護では二つの経路に同じトラフィックを送り、合流点が選択する。資源消費は大きいが、切替判断は合流側に寄る。1:1では通常は稼働経路だけを使い、回復経路上の資源を低優先トラフィックに使える。故障時、そのトラフィックは保護対象によって追い出される。1:nやm:nになると、同時障害の組合せと保護計画が、誰が実際に救われるかを決める。

修復位置も証拠を変える。ローカル修復は故障の直前で素早く動けるが、対象は特定リンクや隣接ノードに限られる。グローバル修復は広い区間を守り、より分離した経路を取れる可能性がある一方、遠い修復点まで通知が必要になる。別の出口へ送ることで、故障した経路そのものを復旧せずサービスを戻す案もあった。

バイパストンネルは複数の回復経路をまとめられる。しかし同時にすべてを収容できる資源があるとは限らない。選択的保護では、あるクラスだけが復旧し、他のパケットが失われることもある。原文のEXPビットという表現はRFC 5462以後のTraffic Classとして歴史的に読むべきで、重要なのは保護対象を誰が選ぶかである。

障害観測も一枚岩ではない。完全なパス障害と性能劣化は異なる。劣化は設定閾値を超えて初めて故障宣言になる。下位層からLink FailureやLink Degradedを受け取ることもできる。検出したLSRが自分で修復できなければFISを修復点へ送る。観測、宣言、通知、切替権限は四つの記録である。

切替後には新しい弱点ができる。revertive modeでは修復された優先経路へ戻るまで、トラフィックは唯一の回復経路を使用し、次の障害に対して無保護になることがある。同時に元の経路資源は保持される。non-revertive modeでは迂回路を新しい稼働経路とし、旧経路を保護側にするか、新しい最適な組を作る。表示が正常でも二重障害への余裕は失われているかもしれない。

そこでRFC 3469はrecovery timeとfull restoration timeを区別した。前者は検出、待機、通知、操作、トラフィック復帰の総時間。後者は障害時の需要を十分に運べるよう設計されたリンクへ恒久的に収容するまでの時間である。最初の回復が同等かつ恒久的な場合だけ、二つの時計は一致する。

比較項目には、設定中の脆弱時間、予備容量、追加遅延、保護品質、並べ替え、状態量、損失、故障カバレッジも含まれた。SONETに似た50ミリ秒という記述は設計目標の参照であって、測定結果でもアプリケーション保証でもない。

RFC 4090は後にRSVP-TE fast rerouteを標準化し、RFC 4426、4427、4428は用語と多層分析を進め、RFC 5714はIP fast rerouteを整理した。これらは系譜を示すが、特定の導入、物理的分離、利用者体験を証明しない。

Heng LuのRunning-Code Primacyで読めば、「設定済み」「保護済み」「復旧済み」は、転送状態とトラフィックが一致するまで記号にすぎない。Minimum Initial Specificationは、共通部分を小さな組合せ可能な要素にした理由を説明する。Reality Layersは、障害、検出、メッセージ、切替、パケット、アプリケーションを混同しないための読み方になる。

RFC 3469の教訓は、予備経路を増やすことではない。経路の存在を復旧の完了と呼ばないことだ。誰が故障を見て、誰が宣言し、誰が切り替え、どの資源が実在し、どこでパケットが戻り、どの品質が残り、いつ再び保護状態になったのか。その連鎖を保存して初めて、復旧は設定上の願望から運用上の事実になる。

出典