要約

  • RFC 3477 は、安定した Router ID と端点ローカルの Interface ID を組にし、RSVP-TE がポイント・ツー・ポイントの番号なしリンクを指定し記録できるようにした。
  • 両端の数値には一致する義務がなく、ERO の意図、IF_ID の解決、RRO の記録、実際の転送はそれぞれ別の証拠だった。

「番号なし」という言葉からは、識別子を持たない回線が連想される。しかし RFC 3477 のリンクには、むしろ二つの名前があった。両端の LSR が一つずつ名前を付け、どちらの数字も、それを付けた装置の外では単独の意味を持たなかった。

対象となるのはポイント・ツー・ポイントのリンクである。各 LSR はゼロ以外の 32 ビット値を割り当て、その一意性を自分のスコープ内でだけ保証した。仕様は、両端の値の間に事前の関係はないと明記する。A から見れば A の値がローカルで B の値がリモート、B に立てば呼び方が逆になる。観察点は付帯情報ではなく、名前の意味そのものだった。

そこで RFC 3477 は Interface ID を、割り当てた LSR の Router ID と組み合わせた。Router ID は、装置への接続性が一つでも残る限り到達可能であるべき安定した IP アドレスで、一般にはループバックとして実装される。外部で役立つ識別子は 32 ビット値だけではなく、Router ID と Interface ID のタプルだった。

この構造なら、異なるルーターが同じ数値を再利用しても衝突しない。逆に、同じ物理リンクの両端が異なる数値を選んでも矛盾しない。データベースがその差を「不整合」とみなして一つの値に整形すれば、消えるのは重複ではなく、誰がどの側を命名したかという来歴である。

両端は互いの割り当てを知る必要があった。方法として、設定、LMP、Forwarding Adjacency の場合の RSVP または CR-LDP、IS-IS や OSPF の拡張が挙げられた。IGP をトラフィックエンジニアリングに使う場合、同じ LSR の IGP モジュールと RSVP モジュールは値を一致させなければならない。タプルの形式が正しくても、隣接マップが古ければ解決は失敗する。

最初の用途は経路の意図だった。Explicit Route Object に追加された Unnumbered Interface ID サブオブジェクトは Type 4、Length 12 で、Router ID と、そのルーターが付けた Interface ID を格納する。ERO の中でこの組は、次に使うべき番号なしリンクを示す。そこをすでに通過したという証明ではない。

次に必要なのが隣接側での解決である。番号なしの出力リンクを選んだノードは、Path メッセージの IF_ID RSVP_HOP に自分の Router ID とローカル識別子を入れる。受信 LSR は、隣接ルーターがリンクに付けた番号を知っていなければならず、受信した組と手元の知識を照合する。一致しない場合、RFC は IF_ID ERROR_SPEC のコード 24、値 16、Unknown Interface Index を返すことを推奨した。

このエラーが確定する範囲は狭い。ある受信者が、ある時点の知識では、提示された隣接スコープの名前を解決できなかったという事実である。物理回線の不在、送信者の偽装、IGP 全体の誤り、代替経路の不存在までは証明しない。原因を論じるには、対応表の取得方法、版、時刻、メッセージ方向、隣接状態が必要になる。

Record Route Object も Type 4、Length 12 の組を使うが、役割は異なる。ERO は予定された経路を表し、RRO は Path メッセージの進行に伴って RSVP が記録した経路状態を残す。同じ符号化は、意図と記録を同じ事実に変えない。また制御面の記録は、そのまま光回線やパケットの独立観測にはならない。

RRO の保護フラグも区別を要求する。一つは下流でローカル保護が利用可能であること、もう一つは通常、障害後の修復として保護が実際に使用中であることを示す。「備えがある」と「切り替えた」は別の出来事である。両方を単に「保護済み」と保存すれば、障害の時間軸が失われる。

番号なし Forwarding Adjacency にも同じ原則が及んだ。LSP をそのようなリンクとして広告する場合、ヘッドエンドとテールエンドがそれぞれ識別子を付ける。Class 193、C-Type 1 の LSP_TUNNEL_INTERFACE_ID は、Path では順方向、Resv では逆方向のインターフェース名を運べる。LSP から作られた抽象リンクでも、二つの管理視点は残った。

後続の GMPLS、OSPF、IS-IS、リンクバンドル関連文書は、このローカル／リモート識別モデルを広げた。RFC 6107 は後に Path Key のため RFC 3477 を更新した。しかし後年の機構は、2003 年 1 月の実装や配備実績を遡って証明する資料ではない。

Heng Lu のノートが求める現実レイヤーの分離は、ここで実務的な意味を持つ。Router ID はスコープを与えるが、現在の到達性を証明しない。ERO は意図であり、通過の証明ではない。RRO は RSVP 状態であり、物理的連続性の独立計測ではない。ラベル割り当てはハードウェア転送でも、サービス到達でもない。

監査では RSVP 生メッセージ、セッション、送信者、方向、時刻を残す。ERO の順序、IF_ID タプル、隣接マップの出所と照合結果、Path/Resv 状態、ラベル操作、RRO の順序とフラグを保存する。その後で初めて、インターフェース台帳、隣接状態、転送テーブル、アラーム、物理状態、トラフィック計測を、それぞれの来歴と時刻付きで結合する。

運用上の核心は、Interface ID を割り当て元 Router ID から切り離さないことだ。両端の値を架空の一つの「正規値」に統合してもいけない。値が違うことは障害ではなく、命名権が両端に分かれていたことの証拠である。

RFC 3477 の歴史的意義は、分散システムに世界共通名を強制せず、二つの局所的真実を正確に共同利用した点にある。名前にスコープを付け、視点を保存し、意図・解決・記録・実体を区別すれば、一つのリンクを一つの権威に所有させる必要はない。番号なしリンクは無名ではなかった。名前が正しく局所的だったのである。

出典