Subject: [Roll] FW: Transit information option

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Tue, 6 Jul 2010 15:24:53 +0200

Hi All,

I didn't see these comments addressed in the new draft. Any reason? 

For point 2, I would go even further and propose to put the path sequence,
control, and lifetime fields in the Target option and keep only the parent
address field in the Transit option.

Let me add that the sentence "In a DIO, the RPL Target Option identifies a
resource that the root is trying to reach" should be removed if I believe
the list of options allowed for DIO.

Best,

Mathilde

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 11:09
To: Philip Levis
Cc: [email-masked]
Subject: Re: [Roll] Transit information option

Hi All,

I just looked at the updated draft and most of the comments below have been
addresses / clarified. Just a few rather minor points:

- Section 5.7.7. RPL Target. Based on the discussion below I would change "A
set of one or more Transit Information options MAY directly follow the
Target option in a DAO message" to "a RPL Target Option in a unicast DAO
MUST be followed by a set of one or more Transit Information Option ".

- If the Path-Sequence / Control fields are indeed used both in storing
(where I have doubts they are really needed) and non-storing mode, why not
put them in the target option rather than in the transit option. This way we
could maybe only use only the target option in storing mode and the
target+transit option in non-storing mode. This would have the additional
benefit of making the parent address mandatory in the transit information
option and thus avoid a variable length option.

Best,

Mathilde

From: Philip Levis [mailto:[email-masked]] 
Sent: vendredi, 11. juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: [email-masked]
Subject: Re: [Roll] Transit information option

On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote:

Hi Phil,

Thanks a lot for your answer. Here are my comments:

A few items that might be worth clarifying in version 09:

- "Transit Information options MAY directly follow the Target option" Is it
really a MAY? If not included it means the path sequence / control /
lifetime are not specified (which seems to contradict section 7.1.4.2).

In non-storing mode, it is definitely a MUST. Storing mode seems like it is
a MUST as well...

I think we all agree.

- "A non-storing node that has more than one DAO parent MAY include a
Transit Information option for each DAO parent as part of the non-storing
Destination Advertisement operation." Why would a node do that? If a node is
sending a DAO for a specific target to e.g. 2 DAO parents (A and B)
shouldn't he send one DAO with transit information A (i.e. parent address =
A) to DAO parent A and another DAO with transit information B to DAO parent
B? Otherwise how this would work over multiple hop? Maybe an example of DAO
would help.

- In section 7.1.5 point 2, I assume the node should add a transit
information with its parent before passing the content of the received DAO.
Also do the operation specified on the path control field in the previous
section for storing node also apply in the non-storing case?

These are good questions. Currently the draft is a bit unclear on whether 

1) a DAO's transit option contains the full source route when it arrives at
the DODAG Root, or 

2) the DODAG Root receives just the last downward hops of each node, and
stitches together source routes with this information. 

1) seems like a much better idea to me. Note that if it's 2), then in
non-storing mode node needs to send a DAO to just one DAO parent, and this
DAO can contain the full set of last-hops. What are your thoughts?

Indeed, I think the current draft is a bit unclear. My interpretation when
reading was 1 (probably due mostly to the history of the draft). Now from
your comments I understand what the draft is proposing, namely 2. Thanks for
explaining.

What triggered this change?

It seems to me that if proper aggregation of the routes is performed (in
particular if in the record route case you can avoid transmitting routes
which are sub-routes of others) the two schemes could actually be quite
similar in terms of overhead. This would need to be confirmed by a careful
study as it could depend quite on bit on the topology. What is quite clear
is that 2 requires more processing power than 1 as it needs to reassemble
routes from the received information.

Also concerning your last comment, I agree. The DAO produced will be
slightly larger but we send only one DAO instead of one DAO per DAO parent.
I think if we do that we might not really need the path control field,
correct?

-09 has a rewrite of the Downward Routes section that should make all of
this much clearer. The answer is 2), for reasons Richard brought up a few
months ago. In particular, if you use 1), then when a node changes its
parent set it entire sub-DODAG must resend DAOs. This is a significant cost.
If you use 2), then only that node needs to send a new DAO.

- Has the advantage of having multiple DAO parents been assessed with
respect to the added complexity? One could argue that since we take so much
care in selecting a preferred this should be a good enough choice. Similar
to Phil I'm getting worried about the increased complexity.

But note that in upward routes, there's a parent set. The concern is that
the vagaries and unreliability of wireless links call for supporting some
degree of path diversity. Most protocols today maintain multiple candidate
next hops for this exact reason. Because downward routes start at the
endpoints, there needs to be some way to establish multiple routes.
Otherwise, when one link breaks and you have to issue a trigger to the
entire sub-DODAG.

I understand how this would work in the storing case but in the non-storing
case how would you know at the root that the path failed?

ICMP error.

Phil