要約

  • RFC 3473 は RSVP-TE の Notify を登録済みの非隣接ノードへ直接届け、RFC 2961 の ACK で受信を確認できるようにした。
  • Notify は PathErr や ResvErr を置き換えないため、ACK は警報の到着証拠であって、状態収束、保護切替、通信やアプリケーションの復旧証拠ではない。

警報は、それが告げる修復より先に着く。RFC 3473 はこの時間差をプロトコルの構造として残した。

2003年1月に公開された同文書は、RFC 3471 の GMPLS 機能を RSVP-TE のオブジェクトへ具体化した。一般化ラベル、双方向 LSP、ラベル制約、保護、制御・データ分離、管理状態、再起動回復が含まれる。RFC 3472 が CR-LDP 版を担ったのに対し、Notify は明確な一問題を扱った。障害の直近ではなく、明示経路を変更できる離れたノードへ、どう早く知らせるかである。

Path の Notify Request は上流通知を、Resv の同オブジェクトは下流通知を要求した。IPv4 または IPv6 の Notify Node Address を保持し、受信ノードは対応状態へ記録し、通常は後段へ伝えた。

ただし宛先は不変の端点識別子ではない。ローカルポリシーが送出時に書き換えられた。複数の Request があれば意味を持つのは最初だけであり、後続は無視できた。そして Request が存在しても、Notify が必ず生成されるわけではなかった。

適切なエラーを検出すると、ノードは非隣接の宛先へ Notify を送れた。途中の非対象ノードが変更せず転送する方法と、新しい IP ヘッダーで直接宛先へ包む方法があった。Router Alert は付けない。障害の報告経路は、障害箇所や通常の PathErr/ResvErr 経路とは別になった。

ERROR_SPEC はエラーと検出ノードまたは故障リンクを表し、セッション記述子が対象 LSP を限定した。一つの障害から上下流双方へ通知できたが、対応する事前 Request なしに生成してはならなかった。

RFC 2961 の Message ID と ACK が信頼配送を支えた。Notify Node は受信後に Ack を返す。この往復が答えるのは、識別された RSVP メッセージが指定先に届いたか、という限定的な問いである。

ACK は物理障害の真偽、全ホップの状態削除、代替経路の容量、光スイッチの切替、パケットの復帰、アプリケーションの応答を示さない。RFC 3473 は Notify が既存エラーメッセージを置き換えないと明記した。PathErr または ResvErr を生む障害は Notify も生み得るが、後者は補助の証拠路であって状態機械のコミットではない。

Path_State_Removed フラグは差をさらに明確にした。PathErr を転送したノードが関連 Path 状態を実際に削除したことを別に記録できた。Notify の ACK と局所削除の証拠は異なる受領票であり、どちらも経路全体を代表しない。

同じ宛先と ERROR_SPEC の通知はまとめられた。イベント方式、タイマー方式などは実装依存で、タイマーの既定値は一ミリ秒だった。障害時の負荷は下がるが、封筒の時刻と各イベント時刻は同じとは限らない。同封セッションの復旧が原子的になるわけでもない。

管理状態の手順は二番目の証拠を要求した。Down を含む Notify を送ったノードは、Down を含む Path が設定時間内、既定では三十秒以内に戻ることを確認した。戻らなければ downstream の PathTear と upstream の tear または error を送る。最初の警報だけで完了とはしなかった。

制御チャネルだけが失われる場合もある。再起動待機中は RSVP と MPLS 転送状態を保持できた。「制御チャネル劣化」はデータ断を意味せず、「活動中」への復帰も全状態、物理信号、サービスの復旧を保証しない。

非ホップバイホップ配送はセキュリティ境界も変えた。通常の RSVP は各ホップで完全性とノード認証を行う。直送 Notify には IPsec を使うか、その方式を無効化する選択が示された。認証済みの警報と ACK でも、鍵の保持者が送信し受信者が得たこと以上に、光やパケットの現実を証明しない。

後の RFC 4090、RFC 4872、RFC 4873 は高速迂回、端点間回復、区間回復を詳しくした。それでも通知、判断、切替、観測結果は別の出来事である。

Heng Lu の running code 優先原則では、Notify は実際の状態遷移が観測されるまで記号的な記録に留まる。最小仕様は共通の警報文法だけを決め、集約とポリシーを局所に残す。現実の層を分ければ、ACK にサービス復旧の権威を借りさせずに済む。

完全な記録は Request を入れた Path/Resv、書換後の実効宛先、検出者、ERROR_SPEC、セッション、Message ID、送信、受信、ACK を保存する。PathErr/ResvErr、状態削除、保護や撤去、ハードウェア設定、物理信号、双方向トラフィック、アプリ結果は別に結合する。「復旧」は最後の観測まで届いて初めて使える言葉である。

出典