要約

  • RFC 9730の要点は、集中制御がGMPLSを置き換えることではなく、コントローラによる経路選択・サービス調整と、NE間のRSVP-TEシグナリングやローカル保護を組み合わせることにある。したがって「コントローラが要求を受理した」「ドメインでLSPが成立した」「障害時にローカル切替が起きた」「顧客サービスが回復した」は別々の主張であり、別々の証拠を要する。
  • 障害復旧では、検出と即時切替を担うローカル機構と、より広い資源・ドメインを見て再計算する集中制御が引き継ぎ関係を形成する。抽象トポロジー、ローカルTED、ポリシー、報告周期が異なるため、どちらが「最新」かを一律には決められない。運用品質は、各層の状態を時系列で結び、最後にエンドポイント性能とSLOで閉じられるかに左右される。

RFC 9730「Interworking of GMPLS Control and Centralized Controller Systems」は2025年3月に公開されたIETFのInformational RFCである。文書が扱うのは、分散制御と集中制御の勝敗ではなく、その相互動作である。GMPLSのネットワーク要素（NE）は、ノードやリンクの状態を収集し、トポロジーを構築し、ローカルポリシーの下で経路を計算し、RSVP-TEを使ってラベルをホップごとに確保できる。一方、集中コントローラは、複数ドメインや複数技術をまたぐ要求を受け、経路を選択または事前計算し、入口ノードにプロビジョニングを依頼できる。ここでコントローラが各ホップを逐一設定する必要はない。入口へのPCInitiateまたはNETCONF要求の後、NE同士がRSVP-TEでLSPを成立させる構成が取り得る。

この区別は、障害時の説明責任に直結する。集中側で「代替経路を計算した」という事実は、その経路がドメインに受理されたことも、ラベルが割り当てられたことも、クロスコネクトがプログラムされたことも、トラフィックが実際に切り替わったことも意味しない。同様に、ローカルのPLRが高速に切り替えたことは、エンドツーエンドのサービスが元のSLOを満たして回復したことを自動的には意味しない。RFC 9730を運用文書として読むときに最も重要なのは、制御系の「成功」を一つのステータスで表さないことである。

二つの制御面は、同じ地図を同じ時刻に見ていない

ACTNの枠組みを定めるRFC 8453では、CNCからのサービス要求と物理ネットワーク資源の間にMDSCが置かれ、MDSCはサービス要求の対応付けや変換、複数ドメインの調整、抽象化を担う。PNCは個々のNEを設定・監視し、MDSCに対して生のトポロジーまたは抽象化されたトポロジーを提示する。MPIを流れるのは、接続性や帯域の要求だけではなく、ポリシーで選別された資源ビューでもある。

このため、MDSCが持つクロスドメインのグラフは「全体」を表していても、各ドメイン内部の詳細を意図的に欠くことがある。これは欠陥ではなく、抽象化の設計目的そのものだ。ドメインの商用境界、ベンダー差、機密性、スケーラビリティを守りながら、上位が必要な意思決定を行えるようにするためである。逆に言えば、MDSCの経路計算が成功しても、その根拠は各ドメインの生のTEDと同一ではない。

経路計算の場所も一つではない。計算は集中コントローラ、入口ノードが持つTED、あるいはPCEで行える。古典的なPCEの関係では、PCEが経路を返しても、PCCがそれをいつ使うか、そもそも使うかを決める。PCE-initiated operationでは、PCE側からLSPの設定、保守、削除を起動できる。したがって「PCEが経路を返した」と「ネットワークに経路が展開された」を同じ監査イベントとして扱うべきではない。

マルチドメインでは「一本のLSP」とは限らない

複数ドメインをまたぐサービスの実装方法も一様ではない。エンドツーエンドRSVP-TEを使う場合、ドメインごとのLSPをステッチする場合、あるいは別々のセグメントとして設定する場合がある。ドメイン境界のラベルは境界ノードまたはコントローラが割り当てることがある。上位のサービス要求が一本でも、制御上は複数の独立した成立条件を持つ可能性がある。

そのため、障害調査で最初に確認すべき問いは「コントローラのルートは正しかったか」だけではない。どのドメインまで同じ経路意味論が共有されていたか、どこで抽象化されたか、境界ラベルがどの主体によって割り当てられたか、どのセグメントが既に成立していたかを分ける必要がある。特に、上位で算出された経路が各ドメインのローカルポリシーや利用可能資源によって実装時に修正・拒否される可能性を考慮しなければならない。

RFC 9730は、NEとコントローラが生の状態、削減された状態、抽象化された状態を異なる時計で保持し得ることを前提にしている。文書は普遍的な鮮度上限を与えていない。したがって「コントローラのトポロジーが5秒以内なら安全」といった一般化は、このRFCからは導けない。鮮度は、報告、処理、格納、経路計算、ヘッドエンドの状態反映までの連鎖で評価する必要がある。

障害時には、速さと視野が別の層にある

障害復旧では、この非対称性がむしろ役に立つ。ローカルNEは障害を直接検出でき、PLRや保護機構は上位制御の往復を待たずに切替を行える。集中システムは、より広い資源集合を見て、単一ドメインまたは複数ドメインにまたがる新しい代替を計算できる。この二つは競合するというより、異なる時間スケールの処理を分担する。

スパン保護についてRFC 9730は新しい要件を追加していない。既存のAPSやGMPLS Notifyなどの仕組みが、コントローラより速くローカルに切り替えることはあり得る。一方、集中側は互いに素な保護経路を事前計算したり、障害後に代替を更新したりできる。ただし、集中側で代替が更新された時刻と、ヘッドエンドがその代替を実際に利用可能と認識した時刻は同じとは限らない。

Fast Rerouteを理解するには、「compute」「create」「detect/switch」を分けるのが有効である。コントローラまたはPCEが代替を計算し、RSVP-TEがLSPやバイパスを作成し、PLRが障害を検出して切り替える。三つの段階が別の主体に属するなら、成功判定も三つに分かれる。RFC 4873では、branch/PLRがmerge nodeまで独立したrecovery LSPを設定でき、branchやmergeの動的選択はローカルに行われ得るが、実行できない場合はその事実を報告しなければならない。

RFC 4426が整理するように、復旧にはスパン、セグメント、エンドツーエンドなど複数のレベルがあり、同時に動作し得る。ここにプリエンプションやリバージョンが加わると、最初の障害を回避した後に別の揺れが生じる可能性がある。障害直後にパケットが戻ったという観測だけでは、復旧が安定したとは言い切れない。再最適化や通常経路への復帰まで観察する必要がある。

ドメイン内の失敗から、ドメインをまたぐ再計算へ

マルチドメイン障害では、まずGMPLSドメイン内でセグメント再ルーティングを試みることができる。必要な資源が不足する、またはインタードメインリンクが失われると、その結果がController(G)からMDSC側へ伝えられ、MDSCがより広い範囲で代替を計算し、新しいドメインを含む経路を起動する可能性がある。

ここで重要なのは、引き継ぎ条件を観測可能にしておくことだ。ローカル再ルートが「試行中」なのか「資源不足で失敗」したのかが上位に曖昧に伝われば、MDSCは古い前提で再計算する。逆に、上位が新しい経路を起動している間にローカル復旧が完成すれば、二つの制御判断が重なる。RFC群は、すべての実装に共通する単一の競合解決アルゴリズムを定義してはいない。運用者は、どの状態を正とするか、プリエンプションやリバージョンの優先順位を自ら明確にする必要がある。

証拠は「要求」から「顧客境界」までつなぐ

実務上の証拠連鎖は、少なくとも四層に分けると扱いやすい。

第一はコントローラ／MDSC層である。ここでは、要求と制約、利用した抽象トポロジーのバージョンとポリシー、PNCからの応答、選んだ経路またはセグメント、経路分離の前提、再ルート命令のacknowledgementを残す。これにより「上位制御が何を知り、何を意図したか」を説明できる。

第二はドメイン制御層である。ローカルTED、適用したローカルポリシー、PCInitiateまたはNETCONF受信、RSVP Path/Resv/error、ラベル割当、クロスコネクトのプログラム、PCRpt相当の状態が必要になる。この層の証拠は、「要求がドメインでどのように具体化されたか」を示す。

第三はローカル復旧層である。障害検出時刻、PLR・branch・mergeの識別、保護対象範囲、detour/bypassの状態、トラフィック切替、不足資源通知、プリエンプション、リバージョンを時系列化する。これにより「何が速く動いたか」だけでなく、「その後どの制御が上書きしたか」まで追える。

第四はサービス層である。最終的にはエンドポイントの到達性、遅延・損失などの性能、顧客境界のSLO証拠が必要になる。制御面のログがすべて成功していても、ここが回復していなければ「サービス復旧」は成立しない。逆に、顧客サービスが回復していても、どの保護機構で回復したかが不明なら、再現可能性や責任分界は弱いままである。

可用性とセキュリティは、制御方式とは別に設計する

RFC 9730の相互動作モデルでは、コントローラ障害時にも既存サービスと事前設定済み保護が動き続けることが重要になる。コントローラ冗長性やNE側のバックアップ機能は望ましいが、それだけで継続性が保証されるわけではない。どの操作がコントローラ不在でも許可されるか、既存LSPの維持と新規要求の扱いをどう分けるか、復帰後にどの状態を同期源とするかを決める必要がある。

また、各エンティティには管理、信頼、セキュリティポリシーが必要であり、集中コントローラは認証、認可、パッチ適用、監視、保護が必要な高価値点になる。ただし、これは「集中だから危険」「分散だから安全」という単純な比較ではない。分散NEの認証やシグナリング保護が弱ければ、攻撃面は別の形で広がる。責任境界は、どの主体がどの状態を書き換えられるか、どの証拠がその操作を裏付けるかで定義する方が実務的である。

関連RFCを混同しない

RFC 9731のVN YANG、RFC 9732のNRP資源パーティショニング、RFC 9889の5Gスライス実現は、それぞれ隣接領域として重要だが、RFC 9730の復旧機構そのものではない。これらを同一の「集中制御スタック」としてまとめると、どの仕様がどの動作を規定しているかが不明瞭になる。

同様に、RFC 9730は単一のテレメトリ製品、収束時間目標、証明フォーマットを定義していない。非GMPLS側の一部復旧も範囲外である。そのため、運用者が求める「何秒で復旧すべきか」「どのログを保存すべきか」「どの状態を監査記録にするか」は、RFCを引用するだけでは完成しない。標準は相互動作の構造を与えるが、証拠の保持期間、時刻同期、SLO、アラート閾値は運用設計として別途定義する必要がある。

情報源

Errataは2026-09-14に確認し、RFC 9730に一致するErrataは見つからなかった。