要約

  • RFC 9685 は 6LoWPAN Neighbor Discovery を拡張し、node が multicast または anycast address を購読できるようにする。
  • Router は同じ address について origin ごとの state を保持しながら announcement を一つに merge するが、anycast packet は購読者すべてではなく一つの候補へ送られる。
  • したがって subscriber count から delivery count を推定せず、admission、route injection、selection、forwarding、受信結果を独立した receipt として扱う必要がある。

同じ anycast address に三台の node が購読していた。監視画面は「active subscribers: 3」と表示し、運用報告は三つの service endpoint が同じ request を受け取ったように読めた。実際には packet は一台だけに転送される。残り二台は候補であり、受信者ではなかった。

これは障害ではなく、anycast の意味である。RFC 9685 は 6LoWPAN の葉が anycast address を受け入れることを購読として知らせ、その state を RPL に載せる方法を定める。複数の購読を認めることと、一つの packet を複製することは別の処理である。

Subscription は候補資格を作る

RFC 8505 の registration は node が所有する unicast address を扱う。RFC 9685 の subscription は node が listen または accept する multicast／anycast address を扱う。同じ address を複数の node が提示しても、unicast の duplicate として拒否されない。

P-field の値 2 が anycast を示す。R flag は reachability service を求めるかを別に示す。P=2 は候補の種類を表すが、RPL への injection 完了や packet 選択を表さない。R=1 も request であり、結果ではない。

Listener の権利を検査する場合、6LR は 6LBR と EDAR/EDAC を交換する。ROVR の保護は RFC 8928 から継承される。この validation は origin の登録を守るが、三候補のどれを local policy が選ぶべきか、選ばれた application が健全かまでは決めない。

必要な admission receipt は node、address、P、R、TID、ROVR、lifetime、EDAR/EDAC result、NA(EARO) status を保持する。その後に selection の新しい主体が現れる。「subscription accepted」という一行に selection result まで入れてはならない。

Merge は候補一覧を上流から隠す

Router は同じ address について origin ごとの registration を保持し、advertisement を一つに merge する。上流に一つの route が見えても、候補が一つとは限らない。逆に三つの origin entry があっても、route が三つになるわけではない。

Reachability を求める active subscription が複数ある場合、injection は最長 lifetime を基準に維持される。一つの候補が期限切れになっても、別の候補が route を支えられる。その route は address 全体について正しいが、期限切れ node の資格を証明しない。

Registration と route injection は asynchronous でもある。新しい候補が NA(EARO) を受け取った時点で、既存の merged route が見えるかもしれない。しかし、その route が新しい origin を含むよう更新されたかは別の event で確かめる必要がある。

そのため ledger は per-origin set、各 lifetime、merge change、effective lifetime、injection timestamp、DAO sequence を保持する。上流 route だけでは、選択時点の候補集合を再構成できない。

Anycast は一つを選ぶ

Storing mode では、RPL router は同じ anycast address を複数の child から受け入れられるが、一つの packet を一つの child にだけ送る。Non-Storing mode では Root がその address を announce した RPL node の一覧を保つが、やはり packet ごとに一つを選ぶ。

RFC 6550 の control state と RFC 9008 の data-plane mechanism は、候補へ packet を運ぶ材料を与える。RFC 6553 の option も application outcome を報告するものではない。

選択理由は RFC 9685 が一律に決めるものではない。Topology、objective function、local policy、現在の state により結果は変わり得る。運用者が「最も近い」「低負荷」「同じ realm」といった意味を要求するなら、その policy version、候補集合、chosen node、path、時刻を自分で記録しなければならない。

Multicast では話が逆になる。Storing mode は tree の各 branch へ進み、Non-Storing multicast MOP は Root が ingress replication を行う。Anycast subscriber count を multicast fanout のように読むと、二つの forwarding semantic を取り違える。

RFC 3810 の MLDv2 と RFC 7731 の MPL は隣接する multicast mechanism である。それらの counter を RFC 9685 anycast の selection receipt として代用することはできない。

選ばれても届くとは限らない

Packet が一つの候補へ向けられた後にも境界がある。6LR が state を失うことがある。Link transmission が失敗することがある。Node が sleep 中かもしれない。IP layer が受けても application が拒否することがある。

RFC 9685 は Direct MAC Broadcast が unreliable になり得ること、asynchronous broadcast が listener の wake time を増やすことを説明する。Multicast では可能な限り個別 unicast MAC frame を期待するが、その期待も application receipt ではない。Anycast でも、chosen next hop は final service outcome ではない。

Reboot 後に未永続化 state を失った router は refresh request を送るべきである。送らなければ periodic registration まで recovery が遅れ、その間 packet が失われ得る。以前の EDAC と NA は真正でも、現在の forwarding state を語れない。

RFC 7346 の multicast scope は address の範囲を整理する。RFC 9685 の Realm-Local／Admin-Local の選択も、compatible 6LR の density や path continuity を自動的には証明しない。

MOP 5 は live network の toggle ではない

新しい Non-Storing multicast MOP 5 を導入するとき、既存 instance をその場で更新することはできない。新しい instance を作り、node を参加させて移行する必要がある。Brownfield では legacy unicast 用 instance と multicast／anycast 用 instance が並立し得る。

どの instance に候補が属するかを失えば、selection policy は誤った集合を参照する。Compatible 6LR の density が足りなければ、capability を持つ network でも listener が対応 router に届かない。Configuration は設計意図であり、coverage は観測事実である。

最小初期仕様は共通交換を規定しつつ、deployment decision を local に残す。現実の層は subscription、candidate、selection、receipt の主体を分ける。running code 優先は、最後に選ばれた node と application を確認することを求める。

RFC 9685 は RPL-Unaware Leaf に service を与えながら、RPL message injection の権限を与えない。この限定は reporting にも必要である。Subscriber は候補である。Route は到達可能性の projection である。選択と受信は別の system が証明する。

情報源