要約

  • RREQ の制御は OrigNode から TargNode へ進むが、その DODAG が支えるデータ方向は TargNode から OrigNode である。RREP 側は逆の関係になる。
  • DODAGID、ローカル InstanceID、6 bit の Delta は同時探索の混同を防ぐが、経路の現在性や利用実績を保証しない。
  • 往復サービスの判断には、二方向それぞれの実装記録、パケット観測、同じ時刻系で結ばれた要求と応答が必要だ。

制御の矢印とデータの矢印

RFC 9854 の出発点は無線の非対称性である。OrigNode が TargNode に送る必要を持ち、既存経路がアプリケーション要件を満たさないとき、AODV-RPL はオンデマンド探索を始める。

最初の RREQ-Instance は OrigNode を根とし、RREQ-DIO はターゲットへ広がる。しかし各参加ノードが得る上向き経路は根へ向かうため、データ用途は TargNode → OrigNode である。TargNode が返す RREP-DIO は OrigNode へ進み、必要なら TargNode を根にした別の RREP-Instance を作る。その経路は OrigNode → TargNode のデータに使われる。制御の到達とデータの到達は同じ主張ではない。

S bit は第一探索が各 hop で対称条件を保ったかを運ぶ。1 で始まり、逆方向も Objective Function を満たす場合だけ 1 のまま進む。TargNode が S=1 を受け取れば、既知の経路で RREP を unicast でき、第二 DODAG は不要だ。S=0 なら RREP-Instance を作り、RREP-DIO を multicast する。第二経路の親と中継ノードは第一経路と異なり得る。

ただし、対称性の判定方法そのものは規格外である。本文はローカル情報、過去の通信、テスト、OAM を挙げ、ETX/RSSI は付録の例にすぎない。S=1 は、ある評価法と時刻の下での制御判断だ。将来の radio link や packet delivery を永久に証明する値ではない。

Delta が結ぶもの

RPLInstanceID はローカルに割り当てられる。同じ端点間で異なる Objective Function の探索が同時進行でき、別の OrigNode が同じ数値を選ぶこともある。RREQ の完全な識別子は OrigNode の値とアドレスの組、RREP は TargNode の値とアドレスの組である。

RREP 用候補値が同じ DODAGID の active instance に使われていれば、TargNode は別の値を選ばなければならない。6 bit の Delta は受信した RREQ 値に加えた差を示し、255 を越える計算は 0 に戻る。受信ノードは Delta を引いて、target 向け route entry に対応する RREQ 値を保存する。

これは重要な整合性規則だ。同じ数字だけを見て別の探索や OF の状態を結合する事故を防ぐ。しかし、正しい pair は「二つの control record が同じ探索に属する」と示すだけだ。全ノードで経路が存在すること、両側の世代が同時に有効であること、パケットが使ったことは別の証拠になる。

Rank、sequence、lifetime を分ける

Rank を path cost と読んではならない。RFC 6550 は、Rank を DODAG Version 内の相対的位置と定義し、root までの距離や経路コストの適切な表現とは限らないと明記する。RFC 9854 も同じ境界を繰り返す。利用可能な metric/constraint は RFC 6551 が別に定義する。Rank が低いだけで遅延、loss、energy の改善を公表する根拠にはならない。

Orig SeqNo と ART の Dest SeqNo は route generation の新旧を扱う。同じ source、destination、instance で古い sequence を持つ entry は削除される。これは論理的 freshness であって、hardware install や link health の readback ではない。

L field は temporary instance に参加できる時間を決める。route lifetime とは独立し、後者は DODAG configuration から得られ、実際の利用で延長され得る。instance の生存、route の未失効、最近の packet は三つの時計である。

実装形式ごとの証拠

H=1 の hop-by-hop では、各 router が source、instance、destination、next hop、lifetime、sequence を含む entry を構築する。asymmetric な target 向け route は RREP DODAG の preferred parent を使う。証跡は方向と node を特定しなければならない。

H=0 の source routing では Address Vector が経路を保持する。非対称 RREP の vector は第二の control wave が通った interface を示し、対称なら RREQ vector がそのまま戻る。自分の address を既に含む vector の拒否は loop を抑えるが、正しい list は各 interface の現在の可用性を保証しない。

OrigNode は RREP を受け取ると application data の送信を「開始できる」。ここで discovery は終わるが、結果の検証は始まったばかりだ。第一 packet、target の受理、response 生成、reverse delivery の各段階が残る。

往復を構成する五つの記録

第一は discovery identity、すなわち端点、DODAGID、二つの InstanceID、Delta、OF、H/S、sequence、timer、observer。第二は RREQ が見つけた TargNode → OrigNode の route/vector。第三は RREP が見つけた OrigNode → TargNode の独立した route/vector である。

第四は方向別 packet observation だ。counter や probe には期間、分母、reset 履歴、source/destination、instance context が要る。一方向の成功はその方向だけを証明する。別時刻の二つの片道 test は coexistence を証明しない。

第五は application receipt である。一意な request ID により、送信、TargNode での受理、response 生成、期限内の OrigNode 到着を結ぶ。これが初めて round trip の service fact になる。

RFC 9854 は RPL の optional security framework と RFC 7416 の脅威分析を参照する。それでも key を持つ rogue router は false DIO を出せる。悪意ある Address Vector や forged G-RREP は loop/DoS を起こし得る。authentication は話者の範囲を狭めるが、application outcome を認証しない。

IANA RPL registry は MOP 4 と RREQ/RREP/ART code を記録する。RFC Editor の情報ページ と Datatracker は Proposed Standard の status/history を示し、確認時の errata search は該当なしだった。いずれも deployment census ではない。

Heng Lu の Running-Code Primacy は、文書の成立と稼働事実を分ける。Minimum Initial Specification と voluntary adoption は共通規則を検証可能な最小範囲に置く。Reality Layers の区別に従えば、きれいな pair は象徴的整合性であり、実行された往復の代替ではない。

出典