Dear all:
Yesterday at the mike, Adnan asked questions about the use of TID and ROVR.
In the general case today, the ROVR is not available in the DAO messages and
Since multiple nodes will register the same anycast or multicast address
With uncoordinated TODs, the TID freshness comparison that is used to remove
stale unicast routes cannot happen.
Now, RFC 9010 added the ROVR field in the DAO messages, enabling the routing
to determine the origin of the route and opening the door to zerotrust/ROV in
the future. When the ROVR is available either in NA(EARO) or DAO(RTO), the
origin can be determined, and the stale (mobility) or retired (lifetime=0)
routes can be removed.
I reread the text and that was not sufficiently documented. So I went on
with the following proposed clarification:
5. Updating RFC 6550
+ [RFC6550] uses the Path Sequence in the Transit Information Option
+ (TIO) to retain only the freshest unicast route and remove stale
+ ones, e.g., in the case of mobility. [RFC9010] copies the TID from
+ the EARO into the Path Sequence, and the ROVR field into the
+ associated RPL Target Option (RTO). This way, it is possible to
+ identify both the registering node and the order of registration in
+ RPL for each individual route advertisement, so the most recent path
+ and lifetime values are used.
+
+ For anycast and multicast advertisements (in NS or DAO messages),
+ multiple origins may subscribe to the same address, and multiple
+ advertisements from different origins are merged by the common parent
+ which becomes the origin of the merged advertisements. The Path
+ Sequence is to be used between advertisements with the same ROVR
+ value, denoting an update from the same origin, but cannot apply if
+ the origin is not determined. This is why this specification
+ requires the use of the ROVR field as the indication of the origin in
+ the RPL advertisements.
+
+ [RFC6550] uses the Path Lifetime in the TIO to indicate the remaining
+ time for which the advertisement is valid for unicast route
+ determination, and a Path Lifetime value of 0 invalidates that route.
+ [RFC9010] maps the Address Registration lifetime in the EARO and the
+ Path Lifetime in the TIO so they are comparable when both forms of
+ advertisements are received.
+
+ For anycast and multicast advertisements, the Path Sequence is to be
+ used between advertisements from the same origin only. The RPL
+ router that merges multiple advertisement for the same anycast or
+ multicast addresses must use and advertise the longest remaining
+ lifetime across all the origins of the advertisements for that
+ address. When the lifetime expires, the router sends a no-path DAO
+ (lifetime=0) using the same value for ROVR value as for the preceding
+ advertisements.
5.1. Updating MOP 3
...
- Though it was implicit in [RFC6550], this specification clarifies
- that the freshness comparison based on the TID field is ignored for
- RPL multicast operations. A RPL router maintains a remaining Path
- Lifetime for each DAO that it receives for a multicast target, and
- sends it own DAO for that target with the longest remaining lifetime
- across its listening children.
+ For anycast and multicast advertisements, including MOP 3, the ROVR
+ field is placed in the RPL Target Option as specified in [RFC9010]
+ for both MOP 3 and MOP 5 as it is for unicast advertisements.
+
+ Though it was implicit with [RFC6550], this specification clarifies
+ that the freshness comparison based on the Path Sequence is not used
+ when the origin cannot be determined, which is the case there. The
+ comparison is to be used only between advertisements from the same
+ origin, which is either an individual subscriber, or a descendant
+ that aggregated multiple advertisements.
+
+ A RPL router maintains a remaining Path Lifetime for each DAO that it
+ receives for a multicast target, and sends its own DAO for that
+ target with the longest remaining lifetime across its listening
+ children. If the router has only one descendant listening, it
+ propagates the TID and ROVR as received. Conversely, if the router
+ merges multiple advertisements (including possibly one for self as a
+ listener), the router uses its own ROVR and TID values.
5.2. New Non-Storing Multicast MOP
...
- As with MOP 3, the freshness comparison based on the TID field is
- ignored for RPL MOP 5 multicast operations. The Root maintains a
- remaining Path Lifetime for each DAO that it receives, and the 6LRs
- generate the DAO for multicast addresses with the longest remaining
- lifetime across its registered 6LNs.
+ For anycast and multicast advertisements in NA (at the 6LR) and DAO
+ (at the Root) messages, as discussed in Section 5.1, the freshness
+ comparison based on the TID field is applied only between messages
+ from the same origin, as determined by the same value in the ROVR
+ field.
- The route disappears when the associated path lifetime in the transit
- option times out, but the procedure to remove a unicast route based
- on TID cannot apply to multicast and anycast.
+ The Root maintains a remaining Path Lifetime for each advertisement
+ it receives, and the 6LRs generate the DAO for multicast addresses
+ with the longest remaining lifetime across its registered 6LNs, using
+ its own ROVR and TID when multiple 6LNs subscribed, or if this 6LR is
+ one of the subscribers.
...
5.3. RPL Anycast Operation
...
With the A flag, this specification alleviates the issue of
- synchronizing the TIDs, and as for multicast, the freshness
- comparison based on the TID field is ignored. A target is routed as
- anycast by a parent (or the Root) that received at least one DAO
- message for that target with the A flag set to 1.
+ synchronizing the TIDs and ROVR fields. As for multicast, the
+ freshness comparison based on the TID (in EARO) and the Path Sequence
+ (in TIO) is ignored unless the messages have the same origin, as
+ inferred by the same ROVR in RTO and/or EARO, and the latest value of
+ the lifetime is retained for each origin.
+
+ A RPL router that propagates an advertisement from a single origin
+ MUST use the ROVR and Path Sequence from that origin, whereas a
+ router that merges multiple subscriptions MUST use its own ROVR and
+ Path Sequence and the longest lifetime over the different
+ advertisements. A target is routed as anycast by a parent (or the
+ Root) that received at least one DAO message for that target with the
+ A flag set to 1.
Also added missing terminology...
The full commit is here:
https://github.com/pthubert/6lo-multicast-registration/commit/3fa57412a565731ab73b90ca49fb79115fb5919b
I refrain from publishing till Erik indicates the fate of the proposed IPv6 ND
Node Uptime option.
All the best;
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
