Re: [Roll] [6tisch] Proposed improvement in RH3-6LoRH

Hi Pascal,

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.

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.

The above observations are not serious, but feels good to ponder over. 
Will be
happy to receive your comments.

Anand

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 > 
6tisch@ietf.org > 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.