Hello Adnan
RFC 8505 MUSTs the setting of the T bit. That’s how you now we have an RFC 8505
registration instead of a RFC 6775 one.
“
o A node that supports this specification MUST provide a TID field
in the EARO and set the T flag to indicate the presence of the TID
(see Section
5.2<https://datatracker.ietf.org/doc/html/rfc8505#section-5.2>).
“
Maybe one day we can deprecate the flag, once we are sure that the TID is
always there…
All the best,
Pascal
From: Adnan Rashid <[email protected]>
Sent: mercredi 27 juillet 2022 17:05
To: Pascal Thubert (pthubert) <[email protected]>
Cc: ROLL WG ([email protected]) <[email protected]>; [email protected]
Subject: Re: ROVR and TID in the 6lo multicast
Hi Pascal,
Thanks for addressing my question.
Do you really think that the T flag is really important in EARO? As we already
discussed the rfc6775 is obsoleted.
T: 1-bit flag. Set if the next octet is used as a TID.
The significance of TID is really important, so is there any case where TID
octet is not available in EARO?
On Wed, Jul 27, 2022 at 4:08 PM Pascal Thubert (pthubert)
<[email protected]<mailto:[email protected]>> wrote:
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
--
Regards,
ADNAN RASHID (Ph.D. Research Scholar)
Dpt. Ingegneria dell'Informazione
Università di Firenze, via di S.Marta-3,
50139, Florence, Italy.
email: [email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>
Cell: (+39) 347 9821 467
--------------------------------------------------------------------------------------------------
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
