Re: [Roll] Semantics of DAO ACK

["Pascal Thubert (pthubert)" <[e-mail]>]

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:[e-mail]] On Behalf Of Cenk Gündogan
> Sent: mardi 29 septembre 2015 23:08
> To: [e-mail]
> 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.
> 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
> 
> On 29.09.2015 21:44, Joakim Eriksson wrote:
> > 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
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll