Subject: [Roll] FW: FW: Transit information option

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Tue, 13 Jul 2010 13:05:28 +0200

Hi JP,

I just saw that you have been opening some tickets to clarify the current
specs. Could we open a ticket to clarify these points as well?

Thanks,

Mathilde

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mathilde Durvy (mdurvy)
Sent: vendredi, 9. juillet 2010 15:17
To: Pascal Thubert (pthubert); ROLL WG
Subject: Re: [Roll] FW: Transit information option

Hi Pascal,

Thanks again for your reply. What you say makes sense although I still think
that the separation of the fields between the target and transit options is
somewhat arbitrary J However this is not a major issue and maybe at this
point it's more important to clarify the specs with respect to the meaning /
usage of the path sequence, control, and lifetime.

- In storing mode, the path control is used to limit the DAO fan-out. It can
also be used to set a preference between routes with the limitation that it
cannot specify two routes which are equally preferred (since path control
bits sent to different parents have to be disjoint). 

- It seems to me that the path control usage is incompatible with the
sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with
the same DAOSequence to all other DAO parents". No?

- In the non storing mode, the path control is not used to limit the DAO
fan-out as nodes send DAOs to only one of their DAO parents. I guess it can
be used as a preference by the root when it computes the source routes.

- How is the path sequence processed? Given that we have already a DAO
sequence is it possible to receive a stale path sequence? Isn't it
redundant? 

- What does the lifetime represent concretely? Is it a measure of the
lifetime of the link between the target and the transit?

It's a lot of questions, but I hope it will help make the DAO part clearer
to everybody!

Best,

Mathilde

From: Pascal Thubert (pthubert) 
Sent: mercredi, 7. juillet 2010 09:22
To: Mathilde Durvy (mdurvy); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information option

Hi Mathilde,

1) In storing mode, the transit information "parent address" is not used

You're correct on that with the current spec. 

I'm pointing out that in some cases we are missing the info for the tunnel
endpoint and that it might become handy to indicate a RPL router to which a
target host is attached.

2)    Hence the pattern would be (Target+) for storing and
(Target+,Transit+)+ for non-storing.

We want to factorise: in non-storing mode, the target can have multiple
parents each one with a different path control.  

In storing mode, a router with multiple interfaces can place multiple
targets for all its addresses and then only one transit info that is common
to them all.

Pascal

From: Mathilde Durvy (mdurvy) 
Sent: Tuesday, July 06, 2010 4:47 PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information option

Hi Pascal,

My point is a bit different.

In storing mode, the transit information "parent address" is not used. The
only fields that are relevant in the transit information are the path
control, sequence, and lifetime, which actually relate to the target prefix.
So why not put these fields in the target option and use only the transit
option when we are in non-storing mode and hence need to specify a parent
address?

Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for
non-storing.

Does this make sense?

Best,

Mathilde

From: Pascal Thubert (pthubert) 
Sent: mardi, 6. juillet 2010 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: RE: [Roll] FW: Transit information option

Hi Mathilde:

Pls note that the target identifies the final destination and the transit
tells you about how you get there. So you can factorize optimally depending
on what you are doing.

We have issue 55 that should cover your proposed change. AS Phil pointed
out, The pattern is really (Target+, Transit+)+. 

I tend to think that the parent is needed in storing mode to indicate the
tunnel end point for targets outside the RPL network, like the proverbial
dumb host attached to a RPL router. 

What do you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 PM
To: ROLL WG
Subject: [Roll] FW: Transit information option

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

---

From: JP Vasseur <[email-masked]>
Date: Tue, 13 Jul 2010 13:23:13 +0200

Sure - done: Ticket #59

On Jul 13, 2010, at 1:05 PM, Mathilde Durvy (mdurvy) wrote:

> Hi JP,
>
> I just saw that you have been opening some tickets to clarify the  
> current specs. Could we open a ticket to clarify these points as well?
>
> Thanks,
> Mathilde
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Mathilde Durvy (mdurvy)
> Thanks again for your reply. What you say makes sense although I  
> still think that the separation of the fields between the target and  
> transit options is somewhat arbitraryJ However this is not a major  
> issue and maybe at this point it’s more important to clarify the  
> specs with respect to the meaning / usage of the path sequence,  
> control, and lifetime.
> - In storing mode, the path control is used to limit the DAO fan- 
> out. It can also be used to set a preference between routes with the  
> limitation that it cannot specify two routes which are equally  
> preferred (since path control bits sent to different parents have to  
> be disjoint).
> - It seems to me that the path control usage is incompatible with  
> the sentence “If a node sends a DAO to one DAO parent, it MUST send  
> a DAO with the same DAOSequence to all other DAO parents”. No?
> - In the non storing mode, the path control is not used to limit the  
> DAO fan-out as nodes send DAOs to only one of their DAO parents. I  
> guess it can be used as a preference by the root when it computes  
> the source routes.
> - How is the path sequence processed? Given that we have already a  
> DAO sequence is it possible to receive a stale path sequence? Isn’t  
> it redundant?
> - What does the lifetime represent concretely? Is it a measure of  
> the lifetime of the link between the target and the transit?
>
> It’s a lot of questions, but I hope it will help make the DAO part  
> clearer to everybody!
>
> Best,
> Mathilde
>
>
> 1) In storing mode, the transit information “parent address” is not  
> used
>
> You’re correct on that with the current spec.
> I’m pointing out that in some cases we are missing the info for the  
> tunnel endpoint and that it might become handy to indicate a RPL  
> router to which a target host is attached.
>
> 2)    Hence the pattern would be (Target+) for storing and (Target 
> +,Transit+)+ for non-storing.
>
> We want to factorise: in non-storing mode, the target can have  
> multiple parents each one with a different path control.
> In storing mode, a router with multiple interfaces can place  
> multiple targets for all its addresses and then only one transit  
> info that is common to them all.
>
> Pascal
>
> In storing mode, the transit information “parent address” is not  
> used. The only fields that are relevant in the transit information  
> are the path control, sequence, and lifetime, which actually relate  
> to the target prefix. So why not put these fields in the target  
> option and use only the transit option when we are in non-storing  
> mode and hence need to specify a parent address?
> Hence the pattern would be (Target+) for storing and (Target+,Transit 
> +)+ for non-storing.
>
> Does this make sense?
> Best,
> Mathilde
>
> Pls note that the target identifies the final destination and the  
> transit tells you about how you get there. So you can factorize  
> optimally depending on what you are doing.
>
> We have issue 55 that should cover your proposed change. AS Phil  
> pointed out, The pattern is really (Target+, Transit+)+.
>
> I tend to think that the parent is needed in storing mode to  
> indicate the tunnel end point for targets outside the RPL network,  
> like the proverbial dumb host attached to a RPL router.
>
> What do you think?
>
> Pascal
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Mathilde Durvy (mdurvy)
> 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)
> 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
>
>
> - “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.
> 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?
>
> 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.
> 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.
> 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
> <ATT15247545.txt>