要約

  • RFC 5376 は、希望または除外する AS／ASBR と、それが必須かどうかを要求に載せる一方、受信側 PCE が要求元 AS に応じてローカル方針を適用し、拒否やパラメータ変更を行える構造を求めた。
  • 内部ホップを隠す不透明なパスセグメント識別子は、計算結果への参照であって、LSP のシグナリング、資源予約、稼働、配送を証明するものではない。
  • 要求元 PCC から見えない下流 PCE が関与し得るため、セグメント所有 AS は、後のシグナリング展開がローカル PCE の計算と一致したことを自ら検証できなければならない。

「必須」は他者の権限を消さない

inter-AS 経路には、通過させたい AS や ASBR、避けたい境界、保護、帯域、分離性、多様性といった条件がある。RFC 5376 は、要求側が AS／ASBR を指定し、必須か非必須かを区別できることを求めた。曖昧な希望ではなく、計算入力として明示するためである。

しかし、必須フラグは命令権ではない。受信側 PCE は要求元の AS 番号を使い、自分のローカル方針を適用する。資源の所有者は、要求を拒否できる。優先度、帯域、Fast Reroute、DS-TE クラス、保護条件などを変更する場合もある。要求が正しく認証されたことと、その要求を受け入れる義務は別である。

ここで必要なのは、単なる最終値ではなく変化の履歴だ。どの値を誰が要求し、どの AS が何を必須と解釈し、どの項目を書き換え、何を理由に拒否したのか。最終パスだけを保存すると、上流の意図と下流の裁量が混ざり、後から責任を割り当てられない。

ローカル拒否はプロトコル障害とは限らない。むしろ、分散された権限が実際に機能した証拠になり得る。相手を認証したからといって、相手が符号化できる全ての資源要求を許可したことにはならない。

同じフィールドでも意味が移る

境界を越えるのは値だけではない。MPLS を前提にした制約が GMPLS ドメインへ入れば、そのドメインの技術と方針に合わせた解釈が必要になる。表面的に同じ帯域や保護のフィールドが残っても、運用上の意味は完全には同一でない場合がある。

したがって、相互運用性とは一つの意味を全 AS に強制することではない。変換の出所を残し、どこで意味が変わったかを追跡可能にすることである。要求、ローカル解釈、計算出力、シグナリング入力を別々に保存すれば、後の障害解析で「同じ値だった」という誤った前提を避けられる。

累積コストも同様だ。RFC 5376 は inter-AS パスコストを応答に載せられるとしたが、AS 間のコスト正規化は範囲外とした。数値を加算できることは、各ドメインの尺度や目的が共通であることを意味しない。小さい数値が常に良い、という比較には別の方針証拠が必要だ。

ドメインごとの計算は、制約を満たす候補を見つけても、エンドツーエンドの大域最適を保証しない。「最適」と呼ぶなら、目的関数、尺度、正規化、参加 AS、除外された制約を示さなければならない。

トポロジーを公開しないための参照

事業者が内部リンクや容量、設計上の弱点、商用上の選択を公開したくないのは合理的である。RFC 5376 は、応答に AS や ASBR を含めつつ、ドメイン内部については明示ホップの代わりにパスセグメント識別子を返せるよう求めた。

この識別子は、隠された一連のホップを後で展開するための参照である。上流は内部構造を知らなくても、複数ドメインの結果を組み合わせられる。これは最小開示による協力であり、全情報を中央に集める方式ではない。

同時に、その参照が示す証拠は狭い。PCE がある時点の入力と方針に基づきセグメントを計算したことは示せる。識別子だけでは、後の LSP シグナリングが実行されたこと、同じセグメントへ展開されたこと、資源が予約されたこと、パケットが転送されたことは示せない。

RFC 5376 は 2008 年 11 月の Informational な要件文書であり、シグナリングでの展開自体を規定していない。RFC 5440 の PCEP、RFC 5520 の path key、後の階層型 PCE、stateful 拡張、TLS は仕組みを発展させたが、計算と実行の境界は残る。

隠すなら、所有 AS が照合する

上流 PCC は、隠された内部パスを自力で比較できない。そこで RFC 5376 は、対応するシグナリングに反映される仕組みにより、各 AS がシグナリングされたパスとローカル PCE の計算セグメントとの適合を検証できることを求めた。

たとえば PCE が、指定 ASBR、帯域、保護条件を満たすセグメントに K を割り当てたとする。シグナリング時に K が別の内部経路へ展開されても、外部からは同じ K に見える。古いキャッシュ、方針更新、実装不具合、意図的な置換のいずれでも、確認能力がなければ抽象化が不一致を隠す。

検証者は、そのセグメントを計算したローカル権限主体であるべきだ。K、計算時の状態、方針版、展開結果、照合時刻を結び、適合または不適合を記録する。外部へ内部ホップを開示する必要はない。外部に必要なのは、知り得る主体が責任を持って照合したという限定的な結果である。

これは秘密と監査の妥協ではない。秘密を守るからこそ、境界上の証拠を厳密にする設計である。不透明性を「誰も確認できない」という意味にしてはならない。

PCC が知らない PCE

送信元 PCC が問い合わせた inter-AS PCE は、さらに別の inter-AS PCE や intra-AS PCE へ処理を委ねられる。送信元が下流 PCE の存在や身元を知らない場合もある。直接ピア以外には、PCE の存在自体を隠すこともあり得る。

PCE ピアは互いの身元を認証し、交換データを検証し、必要な暗号化を行うべきである。AS 境界を越える鍵配布には RFC 4107 の原則を考慮する。だが、安全な直結セッションは、見えない全参加者の判断を自動的に保証しない。

信頼チェーンが望ましくても、常に成立するとは限らない。この現実を記録から消してはいけない。直接ピアの証明、下流寄与の可視性、セグメント所有 AS の適合確認を別々の欄に置くべきである。

ポリシーオブジェクトが転送プロトコルにとって不透明なら、その内容を理解するポリシーコンポーネントが追加の保護、識別、権限確認を担う。暗号化された運搬路は、理解していない意味を承認できない。

一つの成功では足りない

実運用では、少なくとも次の記録を分ける必要がある。

  1. 要求記録：端点、要求元 AS、必須・希望・除外 AS／ASBR、帯域、保護、多様性。
  2. 方針記録：判断主体、受理値、書き換え、拒否理由、尺度の解釈。
  3. 計算記録：状態版、参加 PCE、明示ホップまたは不透明セグメント、未確定事項。
  4. 適合記録：所有 AS による、シグナリング展開とローカル計算の照合。
  5. 確立記録：シグナリング結果、予約、ラベル、LSP の実稼働状態。
  6. 結果記録：転送テレメトリー、受信、品質、アプリケーション確認。

PCE 応答が成功しても、後半の記録はまだ存在しない。逆に、後のリンク障害は以前の計算を虚偽にしない。各段階を分ければ、どこを再計算し、どこを再試行し、どの権限主体へ問い合わせるべきかが分かる。

時刻も不可欠だ。10 時に計算されたセグメントは、10 時 3 分の障害後も同じ意味とは限らない。識別子の有効期限、撤回、トポロジー版、方針版がなければ、古い参照が新しい事実のように再利用される。

規格から言えないこと

これらの資料は、現在の特定事業者がどう実装しているか、どの経路が利用されたか、性能や配送結果がどうだったかを証明しない。IETF の文書はアーキテクチャと要件の根拠であり、個別運用の受領書ではない。

確実に言えるのは、inter-AS 自動化でも各ドメインの権限が残ることだ。要求側は条件を表明し、資源所有者は解釈し、PCE は計算し、シグナリングは確立を試み、運用面が結果を観測する。内部を隠すドメインは、その隠された遷移を最もよく検証できる主体でもある。

この分担を保つ限り、相互運用性は中央集権を必要としない。必要なのは、限定された参照、明示された権限、境界ごとの検証、そして後から撤回可能な判断である。