Subject: [Roll] DAO lifetime

From: "Turner, Randy" <[email-masked]>
Date: Fri, 25 Sep 2015 14:53:34 +0000

Hi Guys,

I was hoping someone could answer a quick question regarding non-storing mode and DAOs - If I establish a route to a node using DAO with transit info at time 0 with a lifetime of 100 lifetime units, and then 20 lifetime units later, I send another DAO for the same target address specifying a different path, will this latest DAO cause the root or LBR to overwrite its' routing information for the destination?  I was trying to figure out if I need to explicitly send a DAO with a lifetime of 0 (or something else) to kill the previous route before sending a new DAO for the same destination?

Thanks for any replies...
Randy

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Cenk Gündogan <[email-masked]>
Date: Fri, 25 Sep 2015 17:24:55 +0200

Hello Randy,

It seems like for the Non-Storing mode there is no "No-Path" DAO (DAOs 
with Path lifetime of 0) [2].

To quote section 9.7 section [2]:

3.  When a node removes a node from its DAO parent set, it MAY
        generate a new DAO message with an updated Transit Information
        option.

I am not so sure about this, but I would assume that this new DAO 
message would include an incremented Path Sequence in order to mark 
other DAOs, which might be also still on the way to the root, as 
outdated. So I guess the root would make the decision to overwrite or 
not based on the comparison of the path sequence.

Best,
Cenk

[1] https://tools.ietf.org/html/rfc6550#section-6.4.3
[2] https://tools.ietf.org/html/rfc6550#section-9.7

On 25.09.2015 16:53, Turner, Randy wrote:
>
> Hi Guys,
>
> I was hoping someone could answer a quick question regarding 
> non-storing mode and DAOs – If I establish a route to a node using DAO 
> with transit info at time 0 with a lifetime of 100 lifetime units, and 
> then 20 lifetime units later, I send another DAO for the same target 
> address specifying a different path, will this latest DAO cause the 
> root or LBR to overwrite its’ routing information for the 
> destination?  I was trying to figure out if I need to explicitly send 
> a DAO with a lifetime of 0 (or something else) to kill the previous 
> route before sending a new DAO for the same destination?
>
> Thanks for any replies…
>
> Randy
>
>
> This e-mail (including any attachments) is confidential and may be 
> legally privileged. If you are not an intended recipient or an 
> authorized representative of an intended recipient, you are prohibited 
> from using, copying or distributing the information in this e-mail or 
> its attachments. If you have received this e-mail in error, please 
> notify the sender immediately by return e-mail and delete all copies 
> of this message and any attachments. Thank you.
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Sep 2015 12:19:28 +0000

Hello Randy:

Sorry for overlooking this. Answer is that it depends on the path sequence (see section 7.1 in RFC 6550).
A same sequence indicates multiple parents that can be used in parallel. New sequence cleans all state from the preceding sequence.

Clarification: the non-storing DAO does not indicate a path but a one parent-child relationship.

Cheers,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Turner, Randy
Sent: vendredi 25 septembre 2015 16:54
To: [email-masked]
Subject: [Roll] DAO lifetime

Hi Guys,

---

From: Joakim Eriksson <[email-masked]>
Date: Tue, 29 Sep 2015 21:44:53 +0200

Hello All,

I have spend quite some time to get a more stable implementation of DAO handling
for Contiki RPL and I am currently looking into DAO aggregation. But I realised that
it is for me not 100% clear what a node that receives a DAO with several prefixes to
be registered but can only accept a sub-set of them. Should it be a DAO_NACK in
this case or is there any other way to handle that case?

If each would have been sent separately it is obvious that the receiving node can
do a NACK when the routing table is full and therefore it is possible to get fine-grained
answers. But with aggregation of DAOs this is not the case.

Any ideas?

Best regards,
— Joakim Eriksson, SICS

---

From: Cenk Gündogan <[email-masked]>
Date: Tue, 29 Sep 2015 23:08:11 +0200

Hello Joakim,

This is an interesting question and I also couldn't find any answers in 
RFC 6550.
However, my thoughts on this are as follows:
Since a sub-set of the announced RPL targets could have been accepted 
before filling up
the routing table (e.g.), I would choose a status code between 1 and 127.
I would expect a node to choose another parent if a more aggressive 
status code is received ([128-255]).
But a full routing table can have free space again until the next or any 
subsequent DAO arrives ..
therefore I prefer a "mild rejection" with a status code of [1-127].

To give some feedback to the originator of the DAO, it might be sensible 
to copy the
rejected RPL Target options from the affected DAO to the DAO-ACK, so 
that the originator is fully
aware of which Target prefixes got rejected (and which ones got 
accepted, implicitly).
I would choose this method, because it doesn't require the originator of 
the DAO to save any extra state
about the DAO and its contents.

Nonetheless, everything I wrote is nonconform and I am also interested 
in the RPL experts' opinions
and solutions.

Best,
Cenk

---

From: Csaba Kiraly <[email-masked]>
Date: Wed, 30 Sep 2015 06:44:34 +0200

Hello Joakim,

I have also worked on the Contiki DAO-ACK code, enabling ACKs, 
implementing fixes to the DAOSequence handling, and looking into 
multiple targets.
What Cenk is saying sounds a reasonable hack, but the standard itself is 
in my opinion a bit underspecified for the semantics of DAO-ACK messages 
in several ways.
My preferred solution for ACKing DAO messages with multiple targets 
would be to have support for the same semantics that you would have had 
with one DAO message per Target, i.e., I would prefer an option field 
that gives an individual status for each Target.

To give another example of subtle problems with DAO-ACK, it was not 
clear to me whether I want my implementation to ACK when the Target is 
added to the routing table, or only when this node itself receives an 
ACK for the same Target from its parent. Both makes sense, with the 
former giving a quick one-hop ACK, while the latter works as an 
end-to-end ACK, ensuring that the path is actually built. Both look 
conformant to the standard, but I suppose the original author was 
thinking of the former, and I can easily see interoperability problems 
arising between two implementations using different semantics.

Best regards,
Csaba

On 29/09/15 23:08, Cenk Gündogan wrote:
> Hello Joakim,
>
> This is an interesting question and I also couldn't find any answers 
> in RFC 6550.
> But a full routing table can have free space again until the next or 
> any subsequent DAO arrives ..
> To give some feedback to the originator of the DAO, it might be 
> sensible to copy the
> I would choose this method, because it doesn't require the originator 
> of the DAO to save any extra state

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Sep 2015 07:58:24 +0000

Hello all:

The DAO ACK status really is a summary that indicates that there was a problem or not, so if there is none, no need to dig further. With this, the only thing the child can do is globally pick another parent, and, depending on the range in the status, never come back.

But the digging further, I agree, is not specified. If the groups wants it, we'll have to design additional stuff and draft it.

* We could use the status as an enumeration the way people probably expect it. But you'll note that we did not create a registry for it.

* Which hints you that we could also use it as a metric. A scalar degree of unwillingness to serve as a parent, that accounts for stuff like memory, available time slots in a chunk (for 6TiSCH) and/or battery depletion of the node. The status would translate in such things as serving as alternate but not as preferred parent.

For more selective stuff, we would have to indicate the problem in the dao-ack per route advertisement that is a problem. This is a step that we did not take with RFC 6550, people advising that the draft was workable and thick enough without it.

The path that is really accepted in storing mode is self as a transit for a given target. Transit can be aggregated for multiple targets. And there can be multiple transits for a target. The DAO Ack could include the pairs (transit/target) that are trouble  and indicate for each what the trouble is. It could in theory aggregate what's aggregatable, but the way the info in the dao ack is aggregated may have to differ from what was placed in the DAO.

The path control delegates a right to propagate and eventually fan out the advertisement. If the T+T pair is placed in the dao ack, the path control could be used to refuse that right to propagate, so the child would be free to offer that particular pair to an alternate parent. We still have bits in the transit that could indicate stuff if we need it as well.

Thoughts?

Pascal

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Cenk Gündogan
> Sent: mardi 29 septembre 2015 23:08
> To: [email-masked]
> Subject: Re: [Roll] Semantics of DAO ACK
> 
> Hello Joakim,
> 
> This is an interesting question and I also couldn't find any answers in RFC
> 6550.
> before filling up the routing table (e.g.), I would choose a status code
> between 1 and 127.
> I would expect a node to choose another parent if a more aggressive status
> code is received ([128-255]).
> To give some feedback to the originator of the DAO, it might be sensible to
> copy the rejected RPL Target options from the affected DAO to the DAO-
> ACK, so that the originator is fully aware of which Target prefixes got
> rejected (and which ones got accepted, implicitly).
> I would choose this method, because it doesn't require the originator of the
> DAO to save any extra state about the DAO and its contents.
> 
> Nonetheless, everything I wrote is nonconform and I am also interested in
> the RPL experts' opinions and solutions.
> 
> Best,
> Cenk
> 
> > I have spend quite some time to get a more stable implementation of
> > DAO handling for Contiki RPL and I am currently looking into DAO
> > aggregation. But I realised that it is for me not 100% clear what a
> > node that receives a DAO with several prefixes to be registered but
> > can only accept a sub-set of them. Should it be a DAO_NACK in this case
> or is there any other way to handle that case?
> >
> > If each would have been sent separately it is obvious that the
> > receiving node can do a NACK when the routing table is full and
> > therefore it is possible to get fine-grained answers. But with aggregation
> of DAOs this is not the case.
> >
> > Any ideas?
> >
> > Best regards,
> > — Joakim Eriksson, SICS

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 30 Sep 2015 17:50:59 +0200

> On 29 Sep 2015, at 23:08, Cenk Gündogan <[email-masked]> wrote:
> 
> This is an interesting question and I also couldn't find any answers in RFC 6550.
> Since a sub-set of the announced RPL targets could have been accepted before filling up
> I would expect a node to choose another parent if a more aggressive status code is received ([128-255]).
> But a full routing table can have free space again until the next or any subsequent DAO arrives ..

Yes, but I am in bad need to know exactly what was accepted or not since I would like to
provide full scalability and reliability of the “promised” routes. But it is very hard to know
the best thing to do for aggregated DAOs. At the moment I am keeping the single DAO target
model that we have been using for registration - but I am considering to do aggregation
on no-path DAOs since they can not fail in the same way.

> 
> To give some feedback to the originator of the DAO, it might be sensible to copy the
> rejected RPL Target options from the affected DAO to the DAO-ACK, so that the originator is fully
> aware of which Target prefixes got rejected (and which ones got accepted, implicitly).
> I would choose this method, because it doesn't require the originator of the DAO to save any extra state

Yes, that would work - but I guess we would need to specify clearly in a RFC-add-on how
to handle this. 

> Nonetheless, everything I wrote is nonconform and I am also interested in the RPL experts' opinions
> and solutions.

Yes, I think this topic is something we need to figure out to get out the full potential of RPL. 

Best regards,
— Joakim

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 30 Sep 2015 17:55:41 +0200

> On 30 Sep 2015, at 06:44, Csaba Kiraly <[email-masked]> wrote:
> 
> Hello Joakim,
> 
> I have also worked on the Contiki DAO-ACK code, enabling ACKs, implementing fixes to the DAOSequence handling, and looking into multiple targets.

Nice, I have a PR on Contiki now with what we have been doing to get Contiki RPL more scalable (but still only single targets / paths).

> What Cenk is saying sounds a reasonable hack, but the standard itself is in my opinion a bit underspecified for the semantics of DAO-ACK messages in several ways.

Yes, it is underspecified. There is need for clarifications and more details on the DAO / DAO ACK!

> My preferred solution for ACKing DAO messages with multiple targets would be to have support for the same semantics that you would have had with one DAO message per Target, i.e., I would prefer an option field that gives an individual status for each Target.

Yes, but that would require more memory in the sending node to keep track of things or full specification of the target in the response.
I guess it might be solved by allowing multiple DAO ACKs for the same DAO and to have the Target options included in the DAO ACK.

> 
> To give another example of subtle problems with DAO-ACK, it was not clear to me whether I want my implementation to ACK when the Target is added to the routing table, or only when this node itself receives an ACK for the same Target from its parent. Both makes sense, with the former giving a quick one-hop ACK, while the latter works as an end-to-end ACK, ensuring that the path is actually built. Both look conformant to the standard, but I suppose the original author was thinking of the former, and I can easily see interoperability problems arising between two implementations using different semantics.
> 
We did go for the end-to-end ACK to achieve better scalability. There is to me no point having a route to the parent if it is not possible to
get it all the way to root. But I totally agree - this is not obvious from the RPL RFC either.

Do you have your Contiki code somewhere in the open-source?

Best regards,
— Joakim

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 30 Sep 2015 18:06:17 +0200

> On 30 Sep 2015, at 09:58, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello all:
> 

Yes - lets try to get this designed and detailed so that we can get interoperability between implementations! 
I would be happy to provide what we have been doing to get our implementation working!

> * We could use the status as an enumeration the way people probably expect it. But you'll note that we did not create a registry for it.

Not yet - I guess creating a registry might be fairly easy?

> * Which hints you that we could also use it as a metric. A scalar degree of unwillingness to serve as a parent, that accounts for stuff like memory, available time slots in a chunk (for 6TiSCH) and…

Not sure that degree of unwillingness can be specified in a clear way so that everybody will interpret it the same way. But
sure - it is an option. I have done a “quick hack” and defined 255 as “Root is out of routes”. Because if you get that type of
response - there is no immediate need to look for another parent and another path - it will not work anyway… (that is if the
 node is desired to get a path all the way to/from root).

> For more selective stuff, we would have to indicate the problem in the dao-ack per route advertisement that is a problem. This is a step that we did not take with RFC 6550, people advising that the…

Yes, and we were tired of writing more I guess - and eager to implement ;-)

> The path that is really accepted in storing mode is self as a transit for a given target. Transit can be aggregated for multiple targets. And there can be multiple transits for a target. The DAO Ac…

Yes, the thing with todays RFC is that there is not yet any defined options for the DAO ACK - but that is of course easy to add. One other option
would be to add a flag into the DAO that says “all-or-nothing”. If it is set all routes or no-routes should be installed. It is a bit complex possibly but
it would be very clear when the DAO sending node gets the ack what happened. < 128 means all routes are installed. >=128 means none was
installed. 

> The path control delegates a right to propagate and eventually fan out the advertisement. If the T+T pair is placed in the dao ack, the path control could be used to refuse that right to propagate,…

Yes, but I my case I am doing the simple case of just registering with one single parent / one single DAO path per target.

My current “plan” is to avoid aggregation when doing the regular DAO but possibly aggregate the no-path DAO since that one
can not possibly cause out-of-memory or other problems (or?).

Best regards,
— Joakim