要約

  • RFC 9938 は IETF の Informational RFC であり、DetNet コントローラプレーンの概念、要件、三つの構成を集約する。解決策に必要なプロトコル詳細は後続文書の対象だと明記する。
  • 要求の受信、パスの算出、設定の送信は、各ノードでの資源受入れと継続、PREOF の動作、測定済み性能、利用者側の結果、決裁権限を単独では立証しない。

「中央で見えているのだから、現場でも起きているはずだ」という推論は、ネットワーク運用で最も高価になりやすい省略である。集中コントローラはトポロジと能力を集め、API や北向きインターフェースから要求を受け、NETCONF/YANG などでノードを設定できる。画面に表示される一連の進捗は有用である。しかし表示が結ぶのは管理の経路であり、利用者が受けた効果を自動的に結ぶわけではない。

2026 年 3 月に公開された RFC 9938 は、A Framework for the Deterministic Networking (DetNet) Controller Plane と題する枠組みである。概要は、将来の解決策仕様の基礎になり得る概念と要件を扱うと述べる。本文はさらに、コントローラプレーン解決策のプロトコル詳細を提供しないと明記する。

この限定は、実装を弱くするのではなく、検証を強くする。何を収集し、どこで判断し、どの資源を確保し、何を設定・監視すべきかを分解して示すからである。分解図を、その全段階が特定のサービスで成功したという領収書に読み替えてはならない。

方式の違いは責任の消滅ではない

RFC 9938 は、動的シグナリングによる完全分散型、SDN 的な完全中央集権型、両者を組み合わせるハイブリッド型を扱う。中央集権型の例では、コントローラがネットワークのトポロジと DetNet 能力を集め、UNI、API または北向きインターフェースからフロー確立要求を受け、NETCONF/YANG、DetNet YANG、PCE ベースのコントローラなどでノードを設定する。分散型では情報がシグナリングプロトコルを通じて伝わり、ハイブリッドでは役割を分ける。

これは三つの可能な設計であり、単一の必須実装ではない。ハイブリッドの各組合せに必要なプロトコル拡張について、RFC 9938 は将来の作業だとしている。

従って、画面上の「成功」は細分化されなければならない。要求の到着は意図の到着である。経路計算は、特定時点の入力と規則に基づく候補の生成である。設定操作の完了は、操作の記録である。これらが、全参加ノードの受入れ、キュー・バッファの保持、ラベル・カプセル化の有効性、保護構成の形成、対象パケットの性能境界を同時に意味することはない。

要件を、未確認の成果にしない

RFC 9938 はフローの動的な生成、変更、削除を支援することを求める。明示的経路、帯域・バッファなどの資源予約、キュー規律、双方向フロー、集約が含まれ得る。また、Packet Replication, Elimination, and Ordering Functions（PREOF）も扱う。

ここで列挙されるのは、解決策が満たすべき機能である。計算された予約は確保された予約ではない。確保の応答は、設定変更後も維持されることの保証ではない。ノード設定は、そのフローのデータ面挙動の観測ではない。複数パスは、複製、除去、順序化が対象のパケット集合に機能したことの証明ではない。

複数ドメインでは、証拠はさらに分かれる。RFC は、コントローラプレーン機能が協調し、異なるドメインのコントローラが相互発見、認証、ホップ単位の振る舞いの交渉を必要とし得るとする。一方の運用者が見た状態を、他方の受入れや権限の代わりにはできない。

操作の履歴ではなく、サービスの受領証を残す

要求には、サービス識別子、権限ある依頼者、端点、方向、トラフィック仕様、求める境界を結び付ける。コントローラ判断には、トポロジと能力の版、アルゴリズム、ポリシー、候補経路、設定エポックを結ぶ。受入れには、各ノードの確認、資源・キュー、ラベル/カプセル化、保護ロール、期限を結ぶ。測定には、対象パケット、方向、手法、時刻源、窓を結ぶ。結果には、損害または便益を実際に受けるサービス境界の独立観測を結ぶ。

これは Heng Lu の Running-Code Primacy を運用に戻す方法である。フレームワーク、モデル、集中画面が、各参加者が稼働中のシステムで確かめられる状態を上書きしてはならない。宣言、計算、インストール、測定、結果は別の現実層である。

Sources