要約

  • Conditional PathTearを受けた互換性のあるノード保護マージポイントは、対象LSPの状態を保持する。それ以外の受信側には、削除して通常のPathTearを送る義務が生じる。
  • Remote PathTearは、バックアップのシグナリングが完了する前でも、局所修復点からマージポイントへ明示的な削除を届ける。
  • 対応能力の誤った通知は、古い状態の長期残存にも、有効な状態の早すぎる削除にもつながる。部分導入では方向ごとの互換動作が必要になる。

空になった表が正解とは限らない

障害処理の後、あるルーターには予約状態が残り、別のルーターからは消えている。運用画面だけを見ると、残った方が処理に失敗したように見える。しかし、保護のために残すことが正しい場合がある。削除を早めれば改善になるとは限らない。

2025年3月に標準化過程の文書として公開されたRFC 9705は、その判断を明示する。Conditional PathTearを受信しても、ノード保護のマージポイントであれば状態を消してはならない。これは実際の障害報告ではなく、仕様が扱う処理の分岐である。

背景には、タイマーに二つの仕事を任せたことがある。RFC 4090の共有バイパスによる保護では、更新が来なくなった状態をタイムアウトで片付けられる。一方、バックアップのシグナリングが遅れると、その到着前に通常の破棄が必要な状態まで消しかねない。更新間隔を延ばせば、今度は不要な状態が長く残る。RFC 9705は、保持の理由と削除のきっかけを明示することで、この競合を扱う。

役割はLSPごとに成立する

ラベル交換パスをLSPと呼ぶ。RSVPではパスの状態をPSB、予約の状態をRSBとして管理する。局所修復点PLRは保護対象を迂回させ、マージポイントMPはその保護経路を後続のLSPにつなぐ。

リンク保護のLP-MPは、直前のホップに対応する。ノード保護のNP-MPは、二つ前のホップが間のルーターを迂回する場合の合流点である。同じ装置が両方を兼ねることもある。これは装置全体に永久に付く肩書ではなく、個別のLSPについて確認される役割だ。

確認には、RFC 8796由来のB-SFRR-Ready関連付けが使われる。受信ノードが迂回先として指定され、指定されたPLRとのNode-IDシグナリング隣接関係が稼働し、PLRがRI-RSVP能力を通知している必要がある。経路記録のNode-IDが欠け、別のIGPエリアにいる相手を特定できない場合などには互換動作へ戻る。

「図ではここが合流点だ」という理解だけでは足りない。状態を保持する権限は、障害より前の信号交換と、現在も成立する関係に基づく。

受信者によって変わる破棄の意味

仕様の例では、A―B―C―Dというパスに対し、AがBを避けてCに至る迂回路を持つ。CはAのNP-MPになる。A―Bリンクが切れ、BがこのLSPのMPでなければ、BはPSBとRSBを削除する。入口がノード保護を要求し、上流からPathTearを受けていない場合、BはConditional PathTearを送る。

Cは状態を保持しなければならない。これに対し、NP-MPではない受信者はPSBとRSBを削除し、任意のCONDITIONSオブジェクトを外して、通常のPathTearを下流に送る。条件を理解しないまま、そのまま先へ流す処理ではない。

送信した隣接ノードが新手順への対応を通知していなければ、受信した条件付きメッセージも通常のPathTearとして処理する。この場合は削除し、下流へ伝える。CONDITIONSが含まれていること自体は、能力合意を飛び越える根拠にならない。

CONDITIONSのクラス番号は135、C-Typeは1で、マージポイント条件のフラグによって役割に応じた処理を選ぶ。フラグがなければ通常処理となる。短いフラグ説明にある「MP」を、すべてのMPが保持できるという意味に広げてはいけない。詳細な受信規則はNP-MPを指定している。

保持と、古い関係の撤去は両立する

A―B障害の例で、BもDに向けてノード保護を通知していたとする。B自身が状態を削除した後も、DがBを保護者だと思い続けるのは正しくない。

CはAのためのLSPを保持しながら、Bに対応するB-SFRR-ReadyをPathから除去し、更新をDへ送る。DはBに対応する遠隔パス状態を削除する。その関連付けの除去だけが変更なら、DはPathをさらに下流へ伝播させない。残すべき予約と、撤回すべき保護関係は別の対象になる。

遠隔パス状態は、PLRのNode-IDアドレスをRSVP_HOPに持ち、後の直接的な削除を照合するための記録だ。追加の利用者予約ではない。この記録の消失を、そのまま保護対象のPSB・RSB全体の削除と扱うことはできない。

保持にも期限を終わらせる事象がある。LP-MPは前ホップのリンク障害ではPLRとの隣接関係が続く限り保持できるが、前ホップのノード障害では通常の破棄を行う。NP-MPは間のリンクやノードの障害を越えて保持できるが、より遠いPLRとの隣接関係の喪失や、所定のPathTear、Remote PathTear、ResvTearで条件が変わる。両役割を兼ねる場合、前ホップのリンクが切れても一方の隣接関係だけの喪失で直ちにすべてを消すわけではない。Graceful Restartの猶予も、隣接関係の障害判定より先に考慮される。

待つ理由がなくなったら直接伝える

入口から管理上のLSP撤去が来た時、PLRでは局所修復が始まったばかりで、バックアップ信号がまだ完了していないことがある。PLRだけが状態を消すと、MPは到着しない信号を待ち続ける。

Remote PathTearは、この待ち状態を終わらせる。PLRはMPのNode-IDアドレスへ、既存の隣接関係に対応する識別情報でメッセージを送る。動作中の迂回路も、完了済みのバックアップ信号も前提ではない。PLRとMPは対応する状態を削除する。局所修復そのものが失敗した場合にも送信が必要で、MPは処理後に下流へ破棄を伝える。

Resvの経路記録RROが変わり、旧NP-MPがパスから外れた場合も、旧NP-MPへ直接、状態の削除を通知する。仕様例ではBからDへのバックアップ信号が完了した後、Aが旧合流点Cの状態を削除させる。Cは通常のPathTearをDへ送るが、DはBの完了済みバックアップが支える状態を残す。遠隔破棄は、下流のあらゆる状態を一律に消す指示ではない。

また、前ホップのリンク障害後、バックアップ信号の到着前に予約がプリエンプションで失われると、MPが保持を続ける理由はなくなる。通常の破棄を送り、状態を削除する。後から来たバックアップPathが必要な状態を見つけられず拒否される順序も、RFCは示している。現在の製品障害と混同すべきではない。

長い更新間隔を支える約束

RFC 8370のRI-RSVPは、RFC 2961の信頼性あるメッセージ配送などを基礎に、確認応答と隣接関係の障害検出を組み合わせる。RFC 9705は共有バイパスによる保護で残っていた状態削除手順を補う。この保護方式を使う実装がRI-RSVP能力を通知するには、その新手順全体への対応が必要だ。

誤通知したBが条件付き・遠隔の破棄を送れなければ、古い状態が長く残り得る。誤通知したCがCONDITIONSを理解できなければ、通常の破棄として有効なLSPを消し得る。同じ「対応しているはず」という思い込みが、正反対の失敗を生む。

正しい混在構成では、非対応の下流に対してPathの更新間隔を短くし、新しい破棄手順を使わない。上流が非対応なら、関連するResvなどの更新値を調整し、新しいMP保持手順を止める。ノード保護では間のノードも対応する必要がある。このため、一台の装置の上流方向と下流方向で適用範囲が異なってよい。

短い更新への復帰は、それだけで不具合ではない。文書が示すのは、状態の去就を決める条件であり、導入率、測定済み復旧時間、製品の適合性ではない。

出典