Subject: Re: [6tisch] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...)

From: "S.V.R.Anand" <[email-masked]>
Date: Tue, 2 Feb 2016 13:19:24 +0530

Hi Pascal,

Thanks a lot for your response and for all the references. Please see my 
response in line.

On Sunday 31 January 2016 03:05 PM, Pascal Thubert (pthubert) wrote:
>  > Hello Anand: > > > > Thanks for this, please see below: > > > Having 
a symmetric path, in principle, certainly offers advantages when we want 
 > the communicating nodes to use a well-defined path that has been set 
up to meet > the QoS requirements of an application. Such a pinned path 
can be appropriately > provisioned with required bandwidth resources 
along the entire path. > > > > Ø  True but in radios, the links may be 
very asymmetrical, and the optimal return path may be very different. > 
 > Ø  So the pinned-down return path may be different actually. >

Surely the presence of uni-directional routes cannot be ignored. Some of the
dominating factors like, routing overheads, route and resource state
maintenance on the nodes and the associated scalability issues, 
implementation
complexity, and so on, will prompt network designers to deploy networks with
reliable bi-directional links and routes. Because of the factors listed 
here,
one would like to ensure absence of bi-directional routes will be more of an
exception rather than a norm. No ?

> > > I found the P2P RPL very appropriate for the current discussion. 
What is > interesting is that the Bidirectional Route presented here 
actually enables > creating a symmetric path between end nodes by 
passing on the complete path > information in its signaling messages. In 
this process, routing state is > installed along the path. > > > > Ø  I 
hope that we start new on-demand work for RPL, based on this and AODV. 
It may be that the route is optimized for metrics that are mostly 
directional, one way or the other, if the traffic is so. Ideally wed 
build and associated 2 DODAGs, one for each direction. This is discussed 
in https://tools.ietf.org/html/draft-thubert-roll-asymlink-00 >

Thanks for the draft! Would be happy to be part of the new work you are 
proposing :)

>  > > As you noted, keeping signaling separate from data is certainly an 
elegant way. > > There can however be contexts when in-band signaling 
that uses RH3 as per > RFC6554 data can be more efficient than using a 
signaling protocol, assuming > the security concerns are addressed as 
per RFC2460. This in-band approach is > attractive when we want to set 
up a rapid on-the-fly symmetric path along with > 6TiSCH OTF making 
bandwidth reservation along the way for transactional message > 
exchanges. I am hinting at the possible PCE/NME based solution that (i) 
works > with the RPL DODAG, (ii) considers the hop distance between the 
communicating > node to assess energy costs, (iii) optimizes network 
resource availability, and > finally provides right inputs for the 
nodes. It may well be that dropping the > address is the right choice. > 
 > > > Ø  I can agree with that, and I used that sort of method in 
https://tools.ietf.org/html/draft-thubert-tree-discovery > >

Thanks again! Started reading it. Looks like we are  revisiting concepts 
already developed many years back.

>  > > I think I am doing too much of hand waving going on by leaving out 
all the > essential details. Hope I managed to vaguely convey the point. 
 > > I tend to feel that distributed, centralized and their combination 
might > co-exist to optimize network resources, and therefore retaining 
or dropping the > address in RH3-6LoRH can be made optional. > > > > > > 
Ø  Could be, but should we do it now or when we have the actual need? > 
 > Ø  Do you have a design in mind that limits the implementation 
overhead of supporting both? >

At the rick of sounding naive, can't the option of dropping or retaining 
address be indicated by a bit ?

>  > > Am I making sense ? > > > > > > Ø  To me, certainly J >

Anand

>  > > Anand > > > > > On Saturday 23 January 2016 02:34 PM, Pascal 
Thubert (pthubert) wrote: > > > > > Hello Anand: > > > > > > > > > > > > 
2 good points , that we need to continue in different threads if we do. 
 > > > > > > > > > The source routing optimization done by dropping the 
addresses on the way > > > certainly has benefits. However, there could 
be loss of a natural "symmetric" > > > property that one might want to 
enforce between communicating end nodes in the > > > routing path. By 
symmetry I mean using the same path in both the directions of > > > 
communication. Policy based routing, centralized routing, for instance, 
could > > > be potential users of this property. May be this does not 
represent a common > > > use case. But nevertheless, we have to be aware 
of this side effect which RFC6554 > > > swapping process does not have. 
 > > > > > > > > > > > > Ø  Pascal: Yes, Simon made that point 
yesterday. > > > > > > Ø  It is generally not a good idea to reverse a 
routing header. The RH may have been used to stay away from the shortest 
path for some reason that is only valid on the way in (segment routing). 
 > > > > > > Ø  P2P RPL reverses a path that is learnt reactively, so we 
have a real protocol for doing that sort of thing as opposed to an echo. 
 > > > > > > Ø  Reversing a header is discouraged by RFC 2460 (for RH0) 
unless it is authenticated (which means AH). We do not authenticate the 
RH3, there are a number of reasons for that, general deprecation of AH, 
no use of AH in LLNs etc& Note that AH does not protect the RH on the 
way, it is just a validation at the receiver for the sole value of 
reversing it. > > > > > > Ø  A RPL domain is usually protected by L2 
security and that secures both RPL itself and the RH in packets, at 
every hop > > > > > > Ø  The benefit of saving energy and lowering the 
chances of loss are seen as overwhelming compared to the value of 
possibly reversing the header > > > > > > Ø  Yet we might define a 
variation where we do not pop out the first entry as we go. I do not see 
a consensus on the value of doing it now. > > > > > > > > > > > > > > > 
 > > > Going further, the DAO projection proposal > > > 
(draft-thubert-roll-dao-projection-02.txt) will have several virtual 
roots > > > inside the RPL domain. The automatic assumption of a well 
known root may not apply > > > when nodes within RPL domain communicate 
with each other. I suppose it will > > > have a bearing on the RH3-6LoRH 
performance. > > > > > > > > > > > > Ø  It is not really an assumption, 
but something we leverage as we go. The RPI is very much like a context 
indicator. If an address shares a lon prefix with a root, adding the RPI 
of that root is actually a compression technique. > > > > > > > > > > > 
 > The above observations are not serious, but feels good to ponder 
over. Will be > > > happy to receive your comments. > > > > > > Thanks 
Anand! > > > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > > 
 > On Monday 18 January 2016 11:24 PM, Pascal Thubert (pthubert) wrote: 
 > > > > > > > > > > > Dear all > > > > > > > > > > > > > > > > > > > > 
 > > > > > > > > The picture below illustrates how the RH3 6LoRH works 
with draft 03 in a case like Root -> A -> B -> C -> leaf > > > > > > > > 
 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The 
first 6LoRH is expected to be a full address (128 bits) to set up a 
reference and the next 6LoRH are expected to be smaller and just 
override the rightmost bits which form the delta from the reference. > > 
 > > > > > > > > > > > > > > > > > > > > > > > > > > Proposal: we could 
consider that the 128bits source of the IP header before the RH3 is the 
reference to start with. > > > > > > > > > > > > > > > > > > > > > > > > 
 > > > > With that even the first hop could be compressed the same way 
as the other hops. With RPL, the root is the encapsulator if IP in IP in 
used. Good thing, in that case the root is totally elided with the 
IP-in-IP 6LoRH. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
So this simple proposal saves up to 16 octets (thats in the case with a 
single subnet and all addresses differ only by the last 2 bytes). Im 
willing to add it in the next revision. > > > > > > > > > > > > > > > > 
 > > > > > > > > > > > > Any opposition? > > > > > > > > > > > > > > > > 
 > > > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > > > > > 
 > > > > > > > > -- > > > > > > > This message has been scanned for 
viruses and > > > > > > > dangerous content by MailScanner, and is > > > 
 > > > > believed to be clean. > > > > > > > > > > > > > > 
_______________________________________________ > > > > > > > 6tisch 
mailing list > > > > > > > [email-masked] > > > > > > > 
https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > > -- 
 > > > This message has been scanned for viruses and > > > dangerous 
content by MailScanner, and is > > > believed to be clean. > > > > > > > 
 > > _______________________________________________ > > > 6tisch 
mailing list > > > [email-masked] > > > 
https://www.ietf.org/mailman/listinfo/6tisch > > > -- > This message has 
been scanned for viruses and > dangerous content by MailScanner, and is 
 > believed to be clean.

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Wed, 3 Feb 2016 06:22:03 +0000

Hi,

> > I found the P2P RPL very appropriate for the current discussion. What is
> > interesting is that the Bidirectional Route presented here actually enables
> > creating a symmetric path between end nodes by passing on the complete path
> > information in its signaling messages. In this process, routing state is
> > installed along the path.
> >
> >
> >
> > Ø  I hope that we start new on-demand work for RPL, based on this and AODV. It may be that the route is optimized for metrics that are mostly directional, one way or the other, if the traffic is so. Ideally wed build and associated 2 DODAGs, one for each direction. This is discussed in https://tools.ietf.org/html/draft-thubert-roll-asymlink-00
> >
>
> Thanks for the draft! Would be happy to be part of the new work you are proposing :)

When we create 2 DODAGs for asymmetrical links, two DIO messages are generated:  one from source to destination (instance-1) and the other from destination to source (instance-2). So, there won’t be any DAO or RDO messages in P2P-RPL based on asymmetric links. Am I correct?

In P2P-RPL, ‘Address’ vector is created by the source during DIO-RDO multicast for both hop-by-hop routing (non-storing mode) and source routing (storing mode). For asymmetric-link based P2P-RPL, one ‘Address’ vector (DIO-RDO) is created by source for Instance-1 to discover path from destination to source and the other one needs to be created by destination to discover path from source to destination. If this is to be the proposing operations for asymmetrical P2P-RPL, then there would be two rounds of multicast compared to just one round in the traditional P2P-RPL. It is desirable if we can remove the ‘Address’ vector from the multicast DIO-RDO for asymmetric-link based P2P-RPL(especially for hop-by-hop routing).

With Regards,
Satish.

From: Roll [mailto:[email-masked]] On Behalf Of S.V.R.Anand
Sent: 2016年2月2日 15:49
To: Pascal Thubert (pthubert); [email-masked]
Cc: [email-masked]; Routing Over Low power and Lossy networks
Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...)

Hi Pascal,

Thanks a lot for your response and for all the references. Please see my response in line.

On Sunday 31 January 2016 03:05 PM, Pascal Thubert (pthubert) wrote:
>
> Hello Anand:
>
>
>
> Thanks for this, please see below:
>
>
> Having a symmetric path, in principle, certainly offers advantages when we want
> the communicating nodes to use a well-defined path that has been set up to meet
> the QoS requirements of an application. Such a pinned path can be appropriately
> provisioned with required bandwidth resources along the entire path.
>
>
>
> Ø  True but in radios, the links may be very asymmetrical, and the optimal return path may be very different.
>
> Ø  So the pinned-down return path may be different actually.
>

Surely the presence of uni-directional routes cannot be ignored. Some of the
dominating factors like, routing overheads, route and resource state
maintenance on the nodes and the associated scalability issues, implementation
complexity, and so on, will prompt network designers to deploy networks with
reliable bi-directional links and routes. Because of the factors listed here,
one would like to ensure absence of bi-directional routes will be more of an
exception rather than a norm. No ?

>
>
> I found the P2P RPL very appropriate for the current discussion. What is
> interesting is that the Bidirectional Route presented here actually enables
> creating a symmetric path between end nodes by passing on the complete path
> information in its signaling messages. In this process, routing state is
> installed along the path.
>
>
>
> Ø  I hope that we start new on-demand work for RPL, based on this and AODV. It may be that the route is optimized for metrics that are mostly directional, one way or the other, if the traffic is so. Ideally wed build and associated 2 DODAGs, one for each direction. This is discussed in https://tools.ietf.org/html/draft-thubert-roll-asymlink-00
>

Thanks for the draft! Would be happy to be part of the new work you are proposing :)

>
>
> As you noted, keeping signaling separate from data is certainly an elegant way.
>
> There can however be contexts when in-band signaling that uses RH3 as per
> RFC6554 data can be more efficient than using a signaling protocol, assuming
> the security concerns are addressed as per RFC2460. This in-band approach is
> attractive when we want to set up a rapid on-the-fly symmetric path along with
> 6TiSCH OTF making bandwidth reservation along the way for transactional message
> exchanges. I am hinting at the possible PCE/NME based solution that (i) works
> with the RPL DODAG, (ii) considers the hop distance between the communicating
> node to assess energy costs, (iii) optimizes network resource availability, and
> finally provides right inputs for the nodes. It may well be that dropping the
> address is the right choice.
>
>
>
> Ø  I can agree with that, and I used that sort of method in https://tools.ietf.org/html/draft-thubert-tree-discovery
>
>

Thanks again! Started reading it. Looks like we are  revisiting concepts already developed many years back.

>
>
> I think I am doing too much of hand waving going on by leaving out all the
> essential details. Hope I managed to vaguely convey the point.
>
> I tend to feel that distributed, centralized and their combination might
> co-exist to optimize network resources, and therefore retaining or dropping the
> address in RH3-6LoRH can be made optional.
>
>
>
>
>
> Ø  Could be, but should we do it now or when we have the actual need?
>
> Ø  Do you have a design in mind that limits the implementation overhead of supporting both?
>

At the rick of sounding naive, can't the option of dropping or retaining address be indicated by a bit ?

> Am I making sense ?
> Ø  To me, certainly J

Anand

>
>
> Anand
>
>
>
>
> On Saturday 23 January 2016 02:34 PM, Pascal Thubert (pthubert) wrote:
> >
>
> > Hello Anand:
>
> >
>
> >
>
> >
>
> > The source routing optimization done by dropping the addresses on the way
>
> > certainly has benefits. However, there could be loss of a natural "symmetric"
>
> > property that one might want to enforce between communicating end nodes in the
>
> > routing path. By symmetry I mean using the same path in both the directions of
>
> > communication. Policy based routing, centralized routing, for instance, could
>
> > be potential users of this property. May be this does not represent a common
>
> > use case. But nevertheless, we have to be aware of this side effect which RFC6554
>
> > swapping process does not have.
>
> >
>
> >
>
> >
>
> > Ø  Pascal: Yes, Simon made that point yesterday.
>
> >
>
> > Ø  It is generally not a good idea to reverse a routing header. The RH may have been used to stay away from the shortest path for some reason that is only valid on the way in (segment routing).
>
> >
>
> > Ø  P2P RPL reverses a path that is learnt reactively, so we have a real protocol for doing that sort of thing as opposed to an echo.
>
> >
>
> > Ø  Reversing a header is discouraged by RFC 2460 (for RH0) unless it is authenticated (which means AH). We do not authenticate the RH3, there are a number of reasons for that, general deprecation of AH, no use of AH in LLNs etc& Note that AH does not protect the RH on the way, it is just a validation at the receiver for the sole value of reversing it.
>
> >
>
> > Ø  A RPL domain is usually protected by L2 security and that secures both RPL itself and the RH in packets, at every hop
>
> >
>
> > Ø  The benefit of saving energy and lowering the chances of loss are seen as overwhelming compared to the value of possibly reversing the header
>
> >
>
> > Ø  Yet we might define a variation where we do not pop out the first entry as we go. I do not see a consensus on the value of doing it now.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Going further, the DAO projection proposal
>
> > (draft-thubert-roll-dao-projection-02.txt) will have several virtual roots
>
> > inside the RPL domain. The automatic assumption of a well known root may not apply
>
> > when nodes within RPL domain communicate with each other. I suppose it will
>
> > have a bearing on the RH3-6LoRH performance.
>
> >
>
> >
>
> >
>
> > Ø  It is not really an assumption, but something we leverage as we go. The RPI is very much like a context indicator. If an address shares a lon prefix with a root, adding the RPI of that root is actually a compression technique.
>
> >
>
> >
>
> >
>
> > The above observations are not serious, but feels good to ponder over. Will be
>
> > happy to receive your comments.
>
> >
>
> > Thanks Anand!
>
> >
>
> >
>
> >
>
> > Pascal
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > > Dear all
> > > The picture below illustrates how the RH3 6LoRH works with draft 03 in a case like Root -> A -> B -> C -> leaf
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > The first 6LoRH is expected to be a full address (128 bits) to set up a reference and the next 6LoRH are expected to be smaller and just override the rightmost bits which form the delta from the reference.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Proposal: we could consider that the 128bits source of the IP header before the RH3 is the reference to start with.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > With that even the first hop could be compressed the same way as the other hops. With RPL, the root is the encapsulator if IP in IP in used. Good thing, in that case the root is totally elided with the IP-in-IP 6LoRH.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > So this simple proposal saves up to 16 octets (thats in the case with a single subnet and all addresses differ only by the last 2 bytes). Im willing to add it in the next revision.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Any opposition?
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Pascal
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > --
>
> >
>
> > > This message has been scanned for viruses and
>
> >
>
> > > dangerous content by MailScanner, and is
>
> >
>
> > > believed to be clean.
>
> >
>
> > >
>
> >
>
> > > _______________________________________________
>
> >
>
> > > 6tisch mailing list
>
> >
>
> > > [email-masked]<mailto:[email-masked]>
>
> >
>
> > > https://www.ietf.org/mailman/listinfo/6tisch
>
> >
>
> >
>
> >
>
> > --
>
> > This message has been scanned for viruses and
>
> > dangerous content by MailScanner, and is
>
> > believed to be clean.
>
> >
>
> >
>
> > _______________________________________________
>
> > 6tisch mailing list
>
> > [email-masked]<mailto:[email-masked]>
>
> > https://www.ietf.org/mailman/listinfo/6tisch
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Sat, 6 Feb 2016 09:58:20 +0000

Hello everyone,

Please let me refresh my previous comments as follows.

draft-thubert-roll-asymlink-02

2-DODAGs for asymmetrical links:

For upward routes (Instance-1), root generates DIO message with MOP=0 (No downward routes are allowed). For this, no DAO messages are generated.

For downward routes (Instance-2), root generates DIO messages with MOP=2 (Storing mode). Subsequently, DAO messages are generated back to their immediate parents and routing state information is stored in parent node for downward traffic.

So, root is the same for both Instance-1 and Instance-2. Is this observation correct?

If my observation makes sense then there won’t be DAO messages, which were used in traditional RPL (RFC6550), for upward route with 2 DODAGs (asymmetric links).

If we construct peer to peer routes based on RFC6997, the story would be different from draft-thubert-roll-asymlink-02. In P2P-RPL (RFC6997), the source will act as a temporary root and multicast the DIO-RDO messages with Instance-1. Once, the destination is reached through DIO-RDO the data path from Destination to Source is created. Then we again need to initiate DIO-RDO messages with Instance-2 at destination for the data path from Source to Destination.

If this observation is true then P2P-RPL (RFC6997) will need to have two roots. Am I correct?

With Regards,
Satish

Hi,

With Regards,
Satish.

Hi Pascal,

Anand

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Feb 2016 16:00:08 +0000

Hello Satish

Hello everyone,

PT > correct

PT > This is probably a good approach, yes. Each DAG would be directional, that is based on metrics in one direction.

Cheers,

Pascal

Hi,

With Regards,
Satish.

From: Roll [mailto:[email-masked]] On Behalf Of S.V.R.Anand
Sent: 2016年2月2日 15:49
To: Pascal Thubert (pthubert); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Routing Over Low power and Lossy networks
Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...)

Hi Pascal,

Anand

> > > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>
>
> >
>
> > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>
>