DetNetの経路最適化は権限から始まる

Summary

RFC 9938のDetNet Controller Planeは、フロー要求を受け、実行可能な経路を計算し、「最適」なものを選び、資源を予約して各ノードへ動作を設定する枠組みを示す。しかし最適という評価には、遅延、損失、ジッター、帯域、保護、共有リスク、ドメイン境界、通常トラフィックの余地をどの順で重視するかという、事前に承認された判断が必要である。
必要なのは生のトポロジーを複製する監査台帳ではなく、制約の所有を示す受領記録である。要求と制約の版、取捨選択を認められた主体、各ドメインの資源上限、計算時点の証拠、再評価条件、例外期限、解放責任者を結び、経路や運用目的そのものは公開しない。

終了したフローが資源だけを残すとき

DetNetのガバナンスは、経路を作る瞬間より、終わったはずの経路を片付ける場面で見えやすい。あるサービスの有効期間は終了した。それでも予約状態が残り、新しいフローの要求が拒否される。装置は保存された状態どおりに動いている。計算も設定も壊れていない。

RFC 9055は、teardownが遅れると資源漏出が起き、新規フローを割り当てられなくなる危険を挙げる。セキュリティ上は制御メッセージ遅延の問題である。同時に、それは委任の問題でもある。誰が終了時刻を決めたのか。延長できるのは誰か。例外はいつ切れるのか。解放を確認する責任はどこにあるのか。

コントローラーが最新のトポロジーでもう一度計算しても、これらの問いには答えられない。計算に不足しているのはネットワーク情報ではなく、決定の所有者である。

「最適経路」という言葉も同じ構造を持つ。結果は数値で表せるが、何を最小化し何を守るかは数値の前に決まる。最短の経路と、共有故障を避ける経路と、通常通信の余地を最大にする経路は一致しないことがある。アルゴリズムは順位を実行できるが、その順位を正当化することはできない。

RFC 9938は完成済みプロトコルを装わない

RFC 9938は2026年3月にInformationalとして公開されたIETF文書である。Deterministic NetworkingのController Planeについて、概念と要求を一つの枠組みにまとめ、将来の解決仕様の基礎となり得る内容を示す。本文は具体的なプロトコル仕様を提供せず、それを後続作業に委ねる。

この位置づけを守る必要がある。文書は全組織に共通の権限制度を定めていないし、定めたと読むべきでもない。問題は、実装側が技術的な受付を制度的な承認として扱う場合に生じる。

Controller Planeは、通常なら制御面と管理面に分ける機能を合わせて扱う。フローの生成、変更、削除、明示経路、リンク帯域やノードのバッファー、キュー制御、双方向性、集約、ラベル、PREOF、能力情報、障害対応、性能監視までが対象になる。

これらは共有資源の状態を変える行為である。アプリケーションからAPIで届く要求も、静的プロビジョニングも、SDNコントローラーも、分散シグナリングも入力経路になり得る。しかし、入力経路が正規であることと、要求した資源量や保護水準が承認済みであることは別である。

枠組みが機能をまとめても、責任まで一人にまとめる必要はない。アプリケーション所有者は目的を知り、サービス所有者は約束を管理し、Flow Management Entityは要求を表現し、Controller Plane Functionは経路と設定に変換する。ドメイン運用者は局所的な資源を受け入れ、セキュリティ担当は命令の真正性を守り、運用担当はOAMを読む。

同じソフトウェアが複数の役割を実装しても、それぞれの判断根拠は分離して追跡できなければならない。

パラメーターの値だけでは制約の身分が分からない

RFC 9016はDetNetのフローとサービス情報を表現する。帯域、最大エンドツーエンド遅延、損失、遅延変動などが要求に入る。RFC 9938は、トラフィック仕様が平均ではなく最悪条件を表すと説明する。確実な予約には重要な考え方である。

ただし、同じ値でも意味は違う。最大遅延が物理制御の限界である場合も、契約値である場合も、古いテンプレートの安全余裕である場合もある。二経路の分離が不可欠な場合も、望ましいだけの場合もある。ピーク帯域が測定済みか、念のため大きく書かれただけかでも、資源配分の正当性は変わる。

制約をhard、soft、monitoring triggerに分けずに保存すると、最適化は意図を失う。すべてをhardにすれば利用可能な経路を無用に拒否する。すべてを緩和可能にすれば、保証という言葉が空になる。

YANGは望ましい状態を表現し、NETCONFは設定を運び、PCEは中央制御の経路を計算できる。BGP-LSはトポロジーや能力の情報を提供できる。いずれも重要だが、そのフィールドを誰がどの権限で設定したかを自動的には証明しない。

認証済みのAPI呼び出しにも同じ限界がある。資格情報の所有者は確認できる。操作クラスの実行許可も確認できる。だが、このサービス、この上限、この期間、この参加ドメイン、この縮退ルールという具体的な範囲まで一致するかは、別の証拠を要する。

一つのフローの安心は他の選択肢を消費する

RFC 8938は、DetNetの転送サブレイヤーが資源割り当てと明示経路を提供すると説明する。予約は競合、損失、ジッターを減らす。さらに、最良の経路は最大帯域、最小ジッター、または複数の測定値に応じて変わり、最短経路とは限らない。

したがって、「最良」は発見する属性ではなく、選んだ評価軸に対する結果である。

PREOFによる保護は取引を具体化する。パケットを複数の分離経路へ複製し、後で重複排除と順序回復を行えば、一つの障害に耐えられる可能性が高まる。その代わり、複数支路の帯域、処理、バッファーを使う。あるフローに厚い保護を与えることは、別のフローに残る保護資源を減らす。

RFC 8655は、DetNetと通常トラフィックの共存を求める。決定性フローに高い割合を割り当てても、非DetNet通信を飢餓状態にしてはならず、送信機会を残すべきだとする。準備されていない下流へDetNetトラフィックを送ることはfaultであり、その準備には下流容量を認める行政的判断も含み得る。

ここで経路選択は分配政策になる。依頼者のSLAだけを見れば良い経路でも、別の利用者に約束した最低水準を破ることがある。コントローラーはその下限を制約として必要とし、監査は誰が下限と例外を決めたかを必要とする。

三つの方式で変わるのは責任ではなく証拠の配置

RFC 9938は分散型、完全中央集約型、ハイブリッド型を示す。

分散型では、入口と各ノードが情報を交換し、シグナリングを通じて経路と予約を成立させる。一台が全体を知る必要はない。しかし、後の検証では初期要求、各場所のadmission、版、結果を結ぶ必要がある。中央の決定者がいなかったのに、後から存在したように記録してはいけない。

中央集約型では、コントローラーが能力を集め、候補を計算し、選択して装置へ設定する。技術的な時系列は分かりやすい。その一方で、広い設定権限が無制限の資源配分権と誤認されやすい。一つのコントローラーが複数部門と優先度を扱うなら、資格情報だけでどの要求が上位かは決まらない。

ハイブリッド型では、中央計算とRSVP-TEなどの分散シグナリングが協力する。計算時と予約時の状態が異なる可能性がある。二つの処理がそれぞれ成功しても、同じ制約版に基づいたとは限らない。成功フラグではなく、参照した状態の版を残すべきである。

方式は証拠の発生場所を変える。権限の必要性そのものは変えない。

ドメイン間では一枚の地図より限定的な約束をつなぐ

複数ドメインを通る場合、RFC 9938は複数のController Plane Functionが協力し、Flow Management Entityの要求を各フロー、各hopの振る舞いへ変えるとする。CPF同士は発見、認証、交渉を必要とし得る。アプリケーション面が責任を各ドメインへ分割する場合もある。

相手の認証は不可欠だが、認証された相手が要求できる量と期間までは示さない。あるクラスのサービスを要求する権限があっても、帯域を倍にしたり、保護期間を延ばしたり、別の目的のために経路を変えたりする権限はないかもしれない。

交渉が成功しても、局所動作が合意されたことを示すにとどまる。遅延測定の窓、リスク分離、縮退時の意味、解放時刻がドメイン間で一致しなければ、局所成功は端から端の約束にならない。

そこで必要なのは、内部トポロジーの全面開示ではなく、組み合わせ可能なcommitmentである。各ドメインは受け入れた制約の部分集合、資源クラス、有効期間、起動結果、再評価条件、解放イベントを証明する。グローバルな受領記録は、その証明を同じ要求版へ結ぶ。

内部経路が契約範囲内で変わるだけなら、詳細を公開しなくてよい。ドメインが約束を撤回したり、端から端のhard constraintが破れたりした場合は、全体を再決定する。通信が続くからといって黙って置換すれば、配達は保っても約束を失うことがある。

正しい署名は、範囲外の命令にも付けられる

RFC 9055は制御・シグナリングの改変、注入、経路選択操作、コントローラー侵害を扱う。偽の制御命令は帯域を変え、endpointを追加・削除し、フローを停止し、資源を枯渇させる偽フローを作り得る。遅いteardownも資源を残す。

強い認証と完全性保護は前提である。しかし、認証と委任は同義ではない。

署名が正しく、証明書が有効で、コントローラーも侵害されていない命令を考える。それでも、サービス上限を超え、例外期限を過ぎ、未承認ドメインを追加し、一時保護を常設化しているなら、命令は制度上の範囲外である。鍵を交換しても直らない。アルゴリズムが入力どおり計算したなら、再実装しても直らない。

必要なのは、命令が本物かだけでなく、具体的な委任と一致するかの確認である。

一方、監査記録に生の経路、正確な時刻、帯域、産業用途を集めすぎれば、RFC 9055が警告するreconnaissanceの資料になる。通常の検証にはdigest、時間範囲、資源クラス、合否で十分な場合が多い。

観測方法まで含めて最適化の入力である

管理側は性能と接続性を監視する。RFC 9938は、試験パケットを注入するactive monitoringが遅延やthroughputに影響し得るため通常運用では推奨せず、passive monitoringをより適切とする。RFC 9551はOAMの枠組みを詳しく扱う。

測定値には取得方法、時間窓、新鮮度が必要である。導入試験の結果を恒久的な事実として使えない。passiveな平均値は最大遅延のまれな違反を隠すかもしれない。完全なtopology snapshotでも、緊急の再配置には古すぎることがある。

制約が共有リスクの分離に依存するなら、その関係の変化を監視する。一時的な縮退を認めたなら、期限で新しい判断を起こす。削除命令が完了しなければ、残存予約を担当者と修正期限に結び付ける。

OAMは結果の採点だけではない。過去の承認が現在の状態を説明できなくなる時点を知らせる。

計算が証明できる範囲

トポロジー・能力のsnapshot、制約の版、アルゴリズムの版を固定すれば、どの候補を検査し、なぜ除外し、どの経路を上位にしたかを再現できる。install evidenceは各ノードが状態を受けたことを示し、OAMはある期間の振る舞いを示す。

しかし、それだけでは次を証明できない。

要求者がサービス目標の所有者だったこと
制約が現行版だったこと
hardとsoftの分類が承認済みだったこと
資源消費が上限内だったこと
複製や追加バッファーの費用が認められたこと
通常トラフィックの最低水準が守られたこと
全ドメインが同じ端から端の意味を受け入れたこと
縮退例外に期限と責任者がいたこと
委任終了と同時に資源が解放されたこと

これは数学を疑う理由ではない。数学に入力されていない制度上の事実を、計算結果に代弁させないための境界である。

制約所有受領記録の中身

最初に、要求本文ではなく安定したdigestを置く。要求者のrole、サービス所有者、Flow Management Entityとの境界、希望有効期間を記録し、版管理されたconstraint setへ結ぶ。

各制約にはsourceとstatusを付ける。最大遅延はhard commitmentか、engineering targetか。帯域はworst-case reservationか、observed averageか。path disjointnessは必須か、望ましいか、一時的に免除されたか。非DetNet通信のfloorも忘れない。

次にdecision authorityを明記する。soft constraintの順位を変えられる人、資源上限を承認できる人、degraded modeを受け入れる人、新しいdomainをcommitできる人、teardownを命じる人を範囲付きで残す。万能管理者アカウントから推定してはならない。

計算証拠はprivacyを保てる。snapshot digestとfreshness、evaluator version、candidate-set digest、selected-path digest、reject reason、uncertaintyを保存する。各ドメインは限定されたcommitment tokenを追加する。

最後にactivation、OAM window、reevaluation trigger、exception expiry、rollback target、release owner、correction stateを記録する。状態が変われば、以前の受領記録を上書きせず、明示的に関連付けた後継を作る。

証拠の限界

ここで参照したRFCは、実在するDetNet運用の事故、製品の不正な資源配分、採用率、容量不足率を示していない。RFC 9938はInformationalな枠組みであり、完成済みの共通プロトコルではない。

制約所有受領記録もIETF要件ではなく、Daniel Kadeによるガバナンス上の提案である。機械が判断を細かく実行できるほど、その判断を誰が定義したかを組織が後で説明できることが重要になる。

経路計算、認証、設定、OAMはすべて必要だ。ただし「最適」と呼ぶ前に、誰の制約に基づき、誰の資源を、いつまで使うことが許されたかを残すべきである。

DetNetの「最適経路」は計算より先にガバナンスの決定である

なぜ重要か