要約

  • RFC 9914 は DAO Projection を定義し、RPL Root または外部コントローラーが主 DODAG に従わない最適化経路を RPL ドメインへ導入できるようにする。
  • PCE はトポロジー、経路長、バッテリー、予約可能バッファーなどの制約から経路を計算し、Root が Projected DAO として対象ノードへ投影する。
  • Storing-Mode と Non-Storing-Mode の P-Route が定義され、ハイブリッド状態も生じ得る。したがって投影は一回限りの計算ではなく、確認、保守、期限、置換、削除を伴う状態として扱う必要がある。

RFC 9914 は 2026 年 4 月に公開された IETF Proposed Standard であり、RFC 6550、RFC 6553、RFC 8138 を更新する。主 RPL Instance は Non-Storing Mode で先に存在することが想定され、Projected Route の追加によってモードが混在する場合がある。Storing-Mode P-Route と Non-Storing-Mode P-Route では状態を保持し、転送する責任が異なるため、最終的なホップ数だけで比較してはならない。

P-Route は、伸長したポイントツーポイント経路を短縮したり、保護経路になったり、6TiSCH Track に組み込まれたりする。Track や保護経路では別の高優先度 RIB が使われるため、通常の RPL 経路をどの条件で上書きし、いつ通常経路へ戻すのかを検証する必要がある。sibling topology の関係も、主 DODAG の親子関係と同一とは限らない。経路長だけでなく、電池、バッファー、リンク状態、予約可能性を制約に含めるべきである。

DAO Projection のライフサイクルには、インストール確認、維持、期限切れ、置換、削除が含まれる。確認を受けていない状態を全ノードで利用可能と見なしてはならない。ノード離脱、トポロジー変化、バッファー枯渇、制約違反があれば、再計算、撤回、またはロールバックを起動できなければならない。実装が P-Route の鮮度、バージョン、確認、削除結果をどう可視化するかは、個別に確認すべき未知の部分である。

ここでいう RPL source routing は SRv6 ではない。RFC 9914 の経路投影は RPL、RPL Information Option、RFC 8138 の圧縮されたルーティングヘッダーの境界にある。両者が経路を表現できるからといって、SRv6 の導入や相互運用を推論してはならない。また、RFC 9914 は RFC 9912 の代替でもない。RFC 9912 は RAW の recovery graph とローカル PLR 制御、RFC 9913 は異種無線の能力正規化を扱う。本稿の対象は、RPL 内の Root/PCE 起点の P-DAO、RIB 優先度、状態ライフサイクルである。

主張と RFC の証拠台帳

主張 RFC の根拠
DAO Projection、P-Route の設定・更新・削除 RFC 9914
RPL DODAG と基本アーキテクチャ RFC 6550
RPL 情報を運ぶオプション RFC 6553
RPL source routing とヘッダー圧縮の境界 RFC 8138
6TiSCH の Track と制約ネットワーク RFC 9030
RAW の recovery graph と隣接カバレッジ RFC 9912
RAW の信頼性・低遅延ユースケース RFC 9450

運用受入れの判断経路

最初に、トポロジーの鮮度と、経路長、電池、バッファー、リンク容量、sibling 関係に対する監査可能な制約を確認する。次に Storing、Non-Storing、ハイブリッドの各モードで、確認の欠落、部分インストール、再起動を試す。高優先度 RIB の選択、Track と保護経路の予約、期限、置換、削除も観測する。Root または PCE の停止、古い DAO、ノード離脱を注入し、安全なフォールバックとロールバックを確認する。バージョン、TTL、確認結果、削除結果を可視化できて初めて小規模導入を受け入れる。これは普遍的な展開やベンダー対応を意味しない。

結論

判断すべきなのは、PCE が短い経路を見つけたかだけではない。投影状態がまだ正しく、適切な優先順位で選ばれ、部分的な導入やトポロジー変化の後に収束できることを証明できるかである。P-Route の採用は、監視可能で撤回可能な集中状態への依存を受け入れる決定だ。

出典