Subject: [6lo] Proposed improvement in RH3-6LoRH

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 Jan 2016 17:54:05 +0000

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 (that's in the case with a single subnet and all addresses differ only by the last 2 bytes). I'm willing to add it in the next revision.

Any opposition?

Pascal

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 19 Jan 2016 09:27:59 +0100

HI Pascal,

Thanks for the figures! I have some comments inline with blue text.

On Mon, Jan 18, 2016 at 6:54 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> 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.
>

What if the B and C address can be compressed to one byte(RH3-6LoRH type
0)?
When leaving the root the format would like:
*RH3-6LoRH type 4    IPv6 Prefix (64bits)   A's suffix (64bits)
 RH3-6LoRH type 0      B's suffix (8bits)    C's suffix (8bits)*
should node A need to extend the address of B address when the packet
leaving A? Like:
*RH3-6LoRH type 4    IPv6 Prefix (64bits)   B's suffix (64bits)
 RH3-6LoRH type 0      C's suffix (8bits)*

>
>
> Proposal: we could consider that the 128bits source of the IP header
> before the RH3 is the reference to start with.
>
I have no comments with the proposal. Just want to mention in the currently
version of draft (version 3) , it says : (in section 5)
...

   If some bits of the first address in the RH3-6LoRH header can be
   derived from the final destination in the LoWPAN_IPHC, then that
   address may be compressed; otherwise it is expressed as a full IPv6
   address of 128 bits.  Next addresses only need to express the delta
   from the previous address.

...
How to understand this combining with the proposal? (Or this is the point
we are going to replace by the proposal? Let me know)

>
>
> 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.
>
That's great! Could I confirm when the packet is inside a RPL domain where
IP in IP is elided, the source destination in IPHC is the reference?

>
>
> So this simple proposal saves up to 16 octets (that’s in the case with a
> single subnet and all addresses differ only by the last 2 bytes). I’m
> willing to add it in the next revision.
>
I don't know how to calculate the saved bytes. For this case, will the
format looks like this?
RH3-6LoRH type 1    A's suffix (16bits)     B's suffix (16bits)   C's
suffix (16bits)

> Pascal
Thanks for the proposal!

>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jan 2016 10:00:11 +0000

Hello Tengfei:

Basically the change proposal accounts for the assumption that the last segment may be different, which comes with the idea of supporting non RPL leaves. If you look at it the original RH4 (RFC 6554) makes a difference for the last hop.

Also, the root is the one computing the 6LoRH so it is easier for it to take its own address as reference.

Finally the text is unclear about which bits from the destination are to be used.

All in all, using the root as reference makes more sense than using the final destination as I had initially proposed. So the new proposal is not a merge but an instead, with clarifying text about the process I showed in the picture.

More answers  inline:
Dear all

What if the B and C address can be compressed to one byte(RH3-6LoRH type 0)?
When leaving the root the format would like:
RH3-6LoRH type 4    IPv6 Prefix (64bits)   A's suffix (64bits)    RH3-6LoRH type 0      B's suffix (8bits)    C's suffix (8bits)

Ø  Pascal If A’s address is the same as B and C for the first 120 bits then this format is correct : )> Pascal

should node A need to extend the address of B address when the packet leaving A? Like:
RH3-6LoRH type 4    IPv6 Prefix (64bits)   B's suffix (64bits)    RH3-6LoRH type 0      C's suffix (8bits)

Ø  Pascal: That is correct. Note that there is no separation between prefix in suffix in the type 4. So the drawing applies for all types if you consider that the prefix length is 64, 96, 112 or 120 depending on the type of the next RH. With the proposal, if the root has the same /120 prefix as A, B and C then we have a single type 0 with A, B and C in it.
Proposal: we could consider that the 128bits source of the IP header before the RH3 is the reference to start with.
I have no comments with the proposal. Just want to mention in the currently version of draft (version 3) , it says : (in section 5)
...

   from the previous address.
...
How to understand this combining with the proposal? (Or this is the point we are going to replace by the proposal? Let me know)

Ø  Pascal: proposal is to replace. That text was unclear and more complex to implement.  And fails to optimize for leaves that are not configured like the mesh.
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.
That's great! Could I confirm when the packet is inside a RPL domain where IP in IP is elided, the source destination in IPHC is the reference?

Ø  Pascal: Yes. The only case where IP in IP is elided is when the source is the root. The root would still be the reference. The text I proposed says the Source of the header that is placed before the RH3, and I meant in the non-compressed form. With RPL as it stands today this is always the root.
So this simple proposal saves up to 16 octets (that’s in the case with a single subnet and all addresses differ only by the last 2 bytes). I’m willing to add it in the next revision.
I don't know how to calculate the saved bytes. For this case, will the format looks like this?
RH3-6LoRH type 1    A's suffix (16bits)     B's suffix (16bits)   C's suffix (16bits)

Ø  Pascal: Yes. In that case you save 14 bytes in A’s address plus the RH3-6LoRH type 4 which is 2 additional bytes, 16 total.
Any opposition?

Pascal

Thanks for the proposal!

Ø  Pascal: Do you vote for it? I’m asking because the plugtest is coming.

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 19 Jan 2016 13:59:44 +0100

Hello Pascal,

Thanks a lot for the detailed answer! I think it solves all my concern. I
will vote for it!

Tengfei

On Tue, Jan 19, 2016 at 11:00 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Tengfei:
>
>
>
> Basically the change proposal accounts for the assumption that the last
> segment may be different, which comes with the idea of supporting non RPL
> leaves. If you look at it the original RH4 (RFC 6554) makes a difference
> for the last hop.
>
>
>
> All in all, using the root as reference makes more sense than using the
> final destination as I had initially proposed. So the new proposal is not a
> merge but an instead, with clarifying text about the process I showed in
> the picture.
>
>
>
> More answers  inline:
>
> Dear all
>
>
>
> Ø  Pascal: That is correct. Note that there is no separation between
> prefix in suffix in the type 4. So the drawing applies for all types if you
> consider that the prefix length is 64, 96, 112 or 120 depending on the type
> of the next RH. With the proposal, if the root has the same /120 prefix as
> A, B and C then we have a single type 0 with A, B and C in it.
>
> I have no comments with the proposal. Just want to mention in the
> currently version of draft (version 3) , it says : (in section 5)
>
> ...
>
> Ø  Pascal: proposal is to replace. That text was unclear and more complex
> to implement.  And fails to optimize for leaves that are not configured
> like the mesh.
>
> Ø  Pascal: Yes. The only case where IP in IP is elided is when the source
> is the root. The root would still be the reference. The text I proposed
> says the Source of the header that is placed before the RH3, and I meant in
> the non-compressed form. With RPL as it stands today this is always the
> root.
>
> Ø  Pascal: Yes. In that case you save 14 bytes in A’s address plus the
> RH3-6LoRH type 4 which is 2 additional bytes, 16 total.
>
> Any opposition?
>
>
>
> Pascal
>
>
>
> Thanks for the proposal!
>
>
>
>
>

---

From: Simon Duquennoy <[email-masked]>
Date: Tue, 19 Jan 2016 18:53:19 +0100

Hi Pascal,

One thing that bugs me is that RH3-6LoRH seems to be an alternative to RH3
rather than a strict compression of it. For instance, a RH3 using different
cmpri and cmpre values, or using non power-of-two, can not be compressed
with 6LoRH. And the discussion on copying the prefix form the DAG root is
also a departure from RH3.
Am I missing something?

Thanks,
Simon

On Tue, Jan 19, 2016 at 1:59 PM, Tengfei Chang <[email-masked]>
wrote:

>> Ø  Pascal: proposal is to replace. That text was unclear and more
>> complex to implement.  And fails to optimize for leaves that are not
>> configured like the mesh.
>>
>> 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.
>>
>> That's great! Could I confirm when the packet is inside a RPL domain
>> where IP in IP is elided, the source destination in IPHC is the reference?
>>
>> Ø  Pascal: Yes. The only case where IP in IP is elided is when the
>> source is the root. The root would still be the reference. The text I
>> proposed says the Source of the header that is placed before the RH3, and I
>> meant in the non-compressed form. With RPL as it stands today this is
>> always the root.
>>
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jan 2016 19:15:34 +0000

Hello Simon:

You can get different cmpri and cmpre values, by placing 2 different RH3-6LoRH header. Having as many 6LoRH headers allows you to compress that even more, like having intermediate cmprx values should you need that.

But ultimately what we compress is the RH0 format with the rules of RH3, knowing that apart from the rules RH3 is just a compression of RH0.

And then 6LoRH can enable a better compression when coalescing from the root’s address.

I agree that we placed an artificial limit with the power of 2, to avoid consuming too much type space. But if the power of 2 does not much the real world use cases and needs, now is a good time to change it.

Do you have an opinion on that?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Duquennoy
Sent: mardi 19 janvier 2016 18:53
To: Tengfei Chang <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; Routing Over Low power and Lossy networks <[email-masked]>; [email-masked]
Subject: Re: [6lo] [6tisch] Proposed improvement in RH3-6LoRH

Hi Pascal,

One thing that bugs me is that RH3-6LoRH seems to be an alternative to RH3 rather than a strict compression of it. For instance, a RH3 using different cmpri and cmpre values, or using non power-of-two, can not be compressed with 6LoRH. And the discussion on copying the prefix form the DAG root is also a departure from RH3.
Am I missing something?

Thanks,
Simon

On Tue, Jan 19, 2016 at 1:59 PM, Tengfei Chang <[email-masked]<mailto:[email-masked]>> wrote:
Hello Pascal,

Thanks a lot for the detailed answer! I think it solves all my concern. I will vote for it!

Tengfei

On Tue, Jan 19, 2016 at 11:00 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Tengfei:

More answers  inline:
Dear all

>  Pascal If A’s address is the same as B and C for the first 120 bits then this format is correct : )> Pascal

>  Pascal: That is correct. Note that there is no separation between prefix in suffix in the type 4. So the drawing applies for all types if you consider that the prefix length is 64, 96, 112 or 120 depending on the type of the next RH. With the proposal, if the root has the same /120 prefix as A, B and C then we have a single type 0 with A, B and C in it.

>  Pascal: proposal is to replace. That text was unclear and more complex to implement.  And fails to optimize for leaves that are not configured like the mesh.

>  Pascal: Yes. The only case where IP in IP is elided is when the source is the root. The root would still be the reference. The text I proposed says the Source of the header that is placed before the RH3, and I meant in the non-compressed form. With RPL as it stands today this is always the root.

>  Pascal: Yes. In that case you save 14 bytes in A’s address plus the RH3-6LoRH type 4 which is 2 additional bytes, 16 total.
Any opposition?

Pascal

Thanks for the proposal!

>  Pascal: Do you vote for it? I’m asking because the plugtest is coming.

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jan 2016 19:17:31 +0000

Cool!

I’ll add some text about that.

The other thing that is missing is the text that describe the operation that I drew, which is implicit at best in the current draft.

What about:
“
Upon reception, the router checks whether the address in the first entry of the
first RH3-6LoRH one of its own addresses. In that case, router MUST consume that
entry before forwarding, which is an action of popping from a stack, where the
stack is effectively the sequence of entries in consecutive RH3-6LoRH headers.

Popping an entry of an RH3-6LoRH header is a recursive action performed as
follows:
> If the Size of the RH3-6LoRH header is 1 or more, indicating that there
  are at least 2 entries in the header, the router removes the first entry and
  decrements the Size (by 1).

> Else (meaning that this is the last entry in the RH3-6LoRH header),
  if there is no next RH3-6LoRH header after this then the RH3-6LoRH is removed.

> Else, if there is a next RH3-6LoRH of a Type with a larger or equal value,
  meaning a same or lesser compression yielding same or larger compressed forms,
  then the RH3-6LoRH is removed.

> Else, the first entry of the next RH3-6LoRH is popped from the next RH3-6LoRH
  and coalesced with the first entry of this RH3-6LoRH.

At the end of the process, if there is no more RH3-6LoRH in the packet, then
the processing node is the last router along the source route path.
“

Cheers,

Pascal

From: Tengfei Chang [mailto:[email-masked]]
Sent: mardi 19 janvier 2016 14:00
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]; Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [6tisch] Proposed improvement in RH3-6LoRH

Hello Pascal,

Tengfei

More answers  inline:
Dear all

Any opposition?

Pascal

Thanks for the proposal!

---

From: Simon Duquennoy <[email-masked]>
Date: Tue, 19 Jan 2016 20:32:09 +0100

Hi Pascal,

I feel we need to make sure any valid RH3 can be compressed with 6LoRH.
This way, RPL implementations do not need to be aware of 6LoRH.
For the compression level, we could maybe optionally carry a full value
inline (or well, it's only 4 bits..).
As for using the root's address as reference for compression, although the
idea makes sense, I'm afraid it makes it complicated to compress RH3, where
the prefix is copied from the IPv6 destination.

Thanks,
Simon

On Tue, Jan 19, 2016 at 8:15 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Simon:
>
>
>
> You can get different cmpri and cmpre values, by placing 2 different
> RH3-6LoRH header. Having as many 6LoRH headers allows you to compress that
> even more, like having intermediate cmprx values should you need that.
>
>
>
> But ultimately what we compress is the RH0 format with the rules of RH3,
> knowing that apart from the rules RH3 is just a compression of RH0.
>
>
>
> I agree that we placed an artificial limit with the power of 2, to avoid
> consuming too much type space. But if the power of 2 does not much the real
> world use cases and needs, now is a good time to change it.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Simon Duquennoy
> *Sent:* mardi 19 janvier 2016 18:53
> *To:* Tengfei Chang <[email-masked]>
> *Cc:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked];
> Routing Over Low power and Lossy networks <[email-masked]>; [email-masked]
> *Subject:* Re: [6lo] [6tisch] Proposed improvement in RH3-6LoRH
>
>
>
> Hi Pascal,
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jan 2016 15:34:04 -0500

Simon Duquennoy <[email-masked]> wrote:
    > I feel we need to make sure any valid RH3 can be compressed with 6LoRH. This
    > way, RPL implementations do not need to be aware of 6LoRH.

I'm sensitive to your need, but I'm not sure it's worthwhile.

What kind of awareness do you feel is required?
There needs to be some communication of what are the interesting prefixes.
I don't see this as a problem.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Simon Duquennoy <[email-masked]>
Date: Tue, 19 Jan 2016 21:54:40 +0100

Any level of awareness is too much, IMO a RPL implementation should
run unmodified yet benefit from 6LoRH.
For instance, if RPL produces a RH3 with cmpri of 6 and cmpre of 10,
we end up with two RH3-6LoRH, each with its own "size unit", which has
to be power of two -- we end up with a compressed possibly larger than
the original.
Another example is when more than two RH3-6LoRH are included to
benefit from a variety of compression levels: in such case, it is not
even possible to translate the compressed back into a standard RH3.

Generally speaking 6lowpan offers one-to-one mappings between
compressed and original headers, I think it is a pity that 6LoRH
doesn't.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jan 2016 20:54:31 +0000

Hello Simon:

I understand that RFC 6554 uses the destination in the IP header as the reference to compress. That address is actually the endpoint of the current segment, IOW the next hop if we use strict source routing as we do today in non-storing mode. So the current text in the draft that uses the final destination does not have the same reference as 6554 either. And the final destination may have a different prefix than the core of the mesh, so using addresses in the mesh like RFC 6554 and the new proposal do seems a better idea. RFC 6554 is emulated in the current draft by representing the first address in full, since that is the end of the current segment in the 6LoRH format. But to compress it, we need a reference, thus the idea to use the root as opposed to the final destination.

I’d suggest that optimizing the compression work from the RH3 format to the 6LoHR format is a non-goal, there is no need to go back and forth between formats. Most current implementations (please correct me but I understand that only ZigbeeIP really made the effort) do not have the IP in IP encaps at the root correctly implemented. They have the current segment end point implemented in an IPHC and they insert a RH3 after it without IP-in-IP. The insertion involves a weird game of swapping addresses to set the destination in the IPHC. When people move to the correct IP in IP form, I expect that they will not implement the IPHC RH3 IPCH form but the 6LoRH right away. Which does not involve the weird swapping game.

Basically to go from RH3 to 6LoRH or the other way around you have to pass via a RH0-like format, similar what you to do a video codec translation. It is not impossible but it is cumbersome. This is mostly because the game of IP header and RH0 was cumbersome to start with. I suggest to add some text to explain that more clearly as a justification for the new format.

Proposed text:

“

In the non-compressed form, when the root generates or forwards a packet in
non-Storing Mode, it needs to include a Routing Header type 3 (RH3) {{RFC6554}}
to signal a strict source-route path to a final destination down the DODAG.
All the hops along the path, but the first one, are encoded in order in the RH3.
The last entry in the RH3 is the final destination and the destination in the
IPv6 header is the first hop along the source-route path. The intermediate hops
perform a swap and the Segment-Left field indicates the active entry in the
Routing Header {{RFC2460}}. The current destination of the packet, which is the
termination of the current segment, is indicated at all times by the destination
address of the IPv6 header.

The handling of the RH3-6LoRH is different: there is no swap, and a forwarding
router that corresponds to the first entry in the first RH3-6LoRH upon reception
of a packet effectively consumes that entry when forwarding. This means that the
size of a compressed source-routed packet decreases as the packet progresses
along its path and that the routing information is lost along the way. This also
means that an RH3 encoded with 6LoRH is not recoverable and cannot be protected.

When compressed with this specification, all the remaining hops MUST be encoded
in order in one or more consecutive RH3-6LoRH headers. Whether or not there
is a RH3-6LoRH header present, the address of the final destination is indicated
in the LoWPAN_IPHC at all times along the path. Examples of this are provided in
{{examples}}.

The current destination (termination of the current segment) for a compressed
source-routed packet is indicated in the first entry in the first RH3-6LoRH.
In strict source-routing, that entry MUST match an address of the router that
receives the packet.

The last entry in the last RH3-6LoRH is the last router on the way to the final
destination in the LLN. It is typically a RPL parent of the final destination,
but it can also be a router acting at 6LR {{RFC6775}} for the destination host.

“

Is that reasonable?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Duquennoy
Sent: mardi 19 janvier 2016 20:32
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Tengfei Chang <[email-masked]>; [email-masked]; Routing Over Low power and Lossy networks <[email-masked]>; [email-masked]
Subject: Re: [6lo] [6tisch] Proposed improvement in RH3-6LoRH

Hi Pascal,

I feel we need to make sure any valid RH3 can be compressed with 6LoRH. This way, RPL implementations do not need to be aware of 6LoRH.
For the compression level, we could maybe optionally carry a full value inline (or well, it's only 4 bits..).
As for using the root's address as reference for compression, although the idea makes sense, I'm afraid it makes it complicated to compress RH3, where the prefix is copied from the IPv6 destination.

Thanks,
Simon

On Tue, Jan 19, 2016 at 8:15 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Simon:

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Simon Duquennoy
Sent: mardi 19 janvier 2016 18:53
To: Tengfei Chang <[email-masked]<mailto:[email-masked]>>
Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] [6tisch] Proposed improvement in RH3-6LoRH

Hi Pascal,

Thanks,
Simon

Tengfei

More answers  inline:
Dear all

Any opposition?

Pascal

Thanks for the proposal!

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jan 2016 21:10:30 +0000

Hello Simon:

Could we take some examples? If possible most of them reasonably realistic? We"ll see the outpout of both methods. 

Again I have nothing against allowing the precision of the byte in the compression, but then is that a real world problem worth wasting types in the 6LoRH? I'd think not for the first 6 actets of the prefix.

I agree with you for the goal
"
Any level of awareness is too much, IMO a RPL implementation should run
unmodified yet benefit from 6LoRH.
"
But the draft does not achieve it as you prescribe. 

The 6LoRH is designed to enable the insertion of a RH3, the addition a RPI, or the IP in IP encapsulation, or any combitnation thereof, without changing a bit in the packet encoded with RFC 6282 (with the restrictive assumption that the RPL artifacts are always encoded with 6LoRH).

I think there is value in:
- preserving the RFC6282 handlers without a change
- manipulating easily the headers induced by RPL without touching the original packet and in particular without the swap of destination address with RH.

Isn't that worht something?

Pascal

> -----Original Message-----
> Sent: mardi 19 janvier 2016 21:55
> To: Michael Richardson <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked];
> Routing Over Low power and Lossy networks <[email-masked]>; Tengfei Chang
> <[email-masked]>; [email-masked]
> Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
> 
> Any level of awareness is too much, IMO a RPL implementation should run
> unmodified yet benefit from 6LoRH.
> For instance, if RPL produces a RH3 with cmpri of 6 and cmpre of 10, we end
> up with two RH3-6LoRH, each with its own "size unit", which has to be
> power of two -- we end up with a compressed possibly larger than the
> original.
> Another example is when more than two RH3-6LoRH are included to benefit
> from a variety of compression levels: in such case, it is not even possible to
> translate the compressed back into a standard RH3.
> 
> compressed and original headers, I think it is a pity that 6LoRH doesn't.
>

---

From: Simon Duquennoy <[email-masked]>
Date: Tue, 19 Jan 2016 22:39:38 +0100

> Again I have nothing against allowing the precision of the byte in the compression, but then is that a real world problem worth wasting types in the 6LoRH? I'd think not for the first 6 actets of t…

OK the effectiveness of the compression wasn't my main concern anyway,
it was rather on the mapping between RH3 and RH3-6LoRH.

> Isn't that worht something?

Yes I see much value in both the above!
But I feel these goals could equally be achieved with simple
compression of the standard RH3 header, rather than a redesign.
I'm mostly worried about the fact that RPL implementations will have
to produce 6LoRH headers, i.e. be 6lowpan-specific and play with
6lowpan compression from a layer above.

BTW the new text you suggested above makes sense to me, it does clarify things.

Thanks,
Simon

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jan 2016 16:39:46 -0500

> to be power of two -- we end up with a compressed possibly larger than

It's just that *RPL* doesn't produce the RH3...
The RPL produces a routing table for the "kernel", and the kernel produces
the RH3, and it's right there that the 6LoRH should be happening.  I'd rather
like the headers for the 6LoRH to be precomputed and attached to the routing
entry, and that's what I'd do on machine with a bit more ram.

    > compressed and original headers, I think it is a pity that 6LoRH

It's true that not all RH3 headers can be as efficiently compressed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jan 2016 16:42:20 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > destination does not have the same reference as 6554 either. And the final
    > destination may have a different prefix than the core of the mesh, so using
    > addresses in the mesh like RFC 6554 and the new proposal do seems a better
    > idea. RFC 6554 is emulated in the current draft by representing the first
    > address in full, since that is the end of the current segment in the 6LoRH
    > format. But to compress it, we need a reference, thus the idea to use the
    > root as opposed to the final destination.

Simon, is it the fact that the root is present here that makes you feel that
it's linked?

---

From: Simon Duquennoy <[email-masked]>
Date: Tue, 19 Jan 2016 22:50:07 +0100

Not really. It was rather my view of the architecture that differs a
bit from what you describe in your previous mail.
For me RPL produces the RH3 and then passes the packet down the stack
for compression. Or for incoming packets, first there is
decompression, then the IPv6 packet with its headers and extension
headers are passed up to RPL etc. If find it odd to force upper layers
to work on 6lowpan compressed formats.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jan 2016 17:06:22 -0500

> bit from what you describe in your previous mail.

okay.

    > to work on 6lowpan compressed formats.

RPL is the thing in RFC6550, a routing protocol, that runs over ICMP ND messages.

I think the thing you are describing is the IPv6 stack, and you don't like
that the IPv6 stack has to interact with the link adaptation layer.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Simon Duquennoy <[email-masked]>
Date: Wed, 20 Jan 2016 08:43:40 +0100

Right, I'm using the wrong wording, I counted RFC6554 as RPL, sorry
for the confusion.

What I don't like:
- IPv6 stack interacting with the adaptation layer
- No one-to-one mapping between a RH3-6LoRH and a RH3

If I'm not mistaken, everything else in 6lowpan offers this one-to-one
mapping, and that allows the IPv6 stack to work independently of
6lowpan (i.e. the same stack runs both in 6lowpan environment or not).
I also find this property nice, conceptually, as one can produce any
IPv6 packet and easily derive its compressed form, and back. One
header maps to one compressed header with all its fields compressed,
etc.

If I'm the only one to think this is an issue, I'm ready to close the issue.

Thanks,
Simon

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Jan 2016 07:48:31 +0000

Well, if there is such interaction, it does not come from the RH3 compression but from the IP in IP compression that allows to elide a well-known root. This means that if the root is not that well-known, like the node participate to multiple DODAGs, then the RPI must be included together with RH3. Which is mandated by RPL for that reason, nothing very new there. 

With the current specs, for a packet with a RH3, the source in the IPv6 header when uncompressed is always the root. When 6LoWPAN decompresses the packet, it has to restore the root address first. 

And the proposal says use that as reference for decompression of the next entries in the RH3, as opposed to the final destination in the (inner) IP header.

The change is a slight improvement, since it addresses the case where the leaf does not belong to the same compression domain as the RPL mesh nodes, and avoids having to dig into the inner IP header.
IOW, with the change, the intermediate routers can process a packet without looking at the inner IP in IP.

In the future, if we allow nodes that are different from the root to write an RH3, then we'll have to decide if we use the source of the packet or the  root as reference. I'd probably still use the root so we can compress the source using the root as reference.

Cheers,

Pascal

> From: Michael Richardson [mailto:[email-masked]]
> Sent: mardi 19 janvier 2016 23:06
> To: Simon Duquennoy <[email-masked]>
> I think the thing you are describing is the IPv6 stack, and you don't like that
> the IPv6 stack has to interact with the link adaptation layer.
> 
> --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Jan 2016 07:54:31 +0000

Our messages crossed, Simon. 

> - IPv6 stack interacting with the adaptation layer

I'm not sure I agree with that (see my other mail), but if you're correct I really what to dig that and fix it.  Please read the other email I just sent and if you still see that the mapping is not there then please refine what the issue is exactly.

> - No one-to-one mapping between a RH3-6LoRH and a RH3

We can reconstruct an RH0 form from RH3 and from RH3-6LoRH, and recompress an RH0 into both as well. I fail to see what the problem is though I do hope that implementations never need to play that game. When the packet goes up the stack, the RH3-6LoRH should be gone, removed by the last router (which may be collocated).

Would you be willing to participate to the next 6TiSCH interim? We'll discuss that topic since it impacts the plugtest.

Cheers,

Pascal

> Sent: mercredi 20 janvier 2016 08:44
> Right, I'm using the wrong wording, I counted RFC6554 as RPL, sorry for the
> confusion.
> 
> What I don't like:
> mapping, and that allows the IPv6 stack to work independently of 6lowpan
> (i.e. the same stack runs both in 6lowpan environment or not).
> IPv6 packet and easily derive its compressed form, and back. One header
> maps to one compressed header with all its fields compressed, etc.
> 
> > I think the thing you are describing is the IPv6 stack, and you don't
> > like that the IPv6 stack has to interact with the link adaptation layer.
> >
> > --

---

From: Simon Duquennoy <[email-masked]>
Date: Wed, 20 Jan 2016 09:08:13 +0100

Yes let me participate to the next 6TiSCH interim. I'll be also at the plugtest.
Will be much easier over voice ;)
Thanks,
Simon

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Jan 2016 08:14:53 +0000

Cool

Let us update the agenda to make more room then.

Could you please prepare a slide or 2 illustrating what the problem is?

Also I'd like to provide examples at the call. If you have some that illustrate your issues please send them on the lists so I can provide the 6lorh form to compare.

Thanks a bunch Simon!

Pascal

> Le 20 janv. 2016 à 09:08, Simon Duquennoy <[email-masked]> a écrit :
>

---

From: Simon Duquennoy <[email-masked]>
Date: Wed, 20 Jan 2016 14:33:30 +0100

Will do, talk to you on Friday!
Thanks,
Simon
Le 20 janv. 2016 09:14, "Pascal Thubert (pthubert)" <[email-masked]> a
écrit :

> Also I'd like to provide examples at the call. If you have some that
> illustrate your issues please send them on the lists so I can provide the
> 6lorh form to compare.
>
> Thanks a bunch Simon!
>
> Pascal
>
> >> I'm not sure I agree with that (see my other mail), but if you're
> correct I really what to dig that and fix it.  Please read the other email
> I just sent and if you still see that the mapping is not there then please
> refine what the issue is exactly.
> >>
> >>
> >> We can reconstruct an RH0 form from RH3 and from RH3-6LoRH, and
> recompress an RH0 into both as well. I fail to see what the problem is
> though I do hope that implementations never need to play that game. When
> the packet goes up the stack, the RH3-6LoRH should be gone, removed by the
> last router (which may be collocated).
> >>
> >> Would you be willing to participate to the next 6TiSCH interim? We'll
> discuss that topic since it impacts the plugtest.
> >>
> >> Cheers,
> >>
> >> Pascal
> >>
> >>
> for the
> 6lowpan
> >>>> RPL is the thing in RFC6550, a routing protocol, that runs over ICMP
> ND
> >>> messages.
> >>>>
> >>>> IETF ROLL WG co-chair.
> http://datatracker.ietf.org/wg/roll/charter/
> >>>>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Jan 2016 20:45:33 +0000

Dear all

The current text in 6LoRH lacks explanation for the process illustrated below.

Is the following correct?

## Coalescence {#RH3-6LoRH-coalescence}

An IPv6 compressed address is coalesced with a reference address by overriding
the N rightmost bytes of the reference address with the compressed address,
where N is the length of the compressed address, as indicated by the Type of the
RH3-6LoRH header in {{RH3LoRHtype}}.

The reference address MAY be a compressed address as well, in which case
it MUST be compressed in a form that is of an equal or greater length than
the address that is being coalesced.

A compressed address is expanded by coalescing it with a reference address. In
the particular case of a Type 4 RH3-6LoRH, the address is expressed in full and
the coalescence is a complete override as illustrated in {{RH3Coalesce}}.

~~~~

RRRRRRRRRRRRRRRRRRRR reference address, may be compressed or not

              CCCCCCC compressed address, shorter than or as reference

 RRRRRRRRRRRRRCCCCCCC Coalesced address, same compression as reference
~~~~
{: #RH3Coalesce title='Coalescing addresses.'}

## Popping Headers {#RH3-6LoRH-popping}

Else (meaning that this is the last entry in the RH3-6LoRH header), and
if there is no next RH3-6LoRH header after this then the RH3-6LoRH is removed.

## Forwarding {#RH3-6LoRH-forwarding}

When receiving a packet with a RH3-6LoRH, a router determines the IPv6 address
of the current segment endpoint.

If strict source routing is enforced and thus router is not the segment endpoint
for the packet then this router MUST drop the packet.

If this router is the current segment endpoint, then the router pops its address
as described in {{RH3-6LoRH-popping}} and continues processing the packet.

If there is still a RH3-6LoRH, then the router determines the new segment
endpoint and routes the packet towards that endpoint.

Otherwise the router uses the destination in the inner IP header to forward or
accept the packet.

The segment endpoint of a packet MUST be determined as follows:

The router first determines the Compression Reference as discussed in
{{RH3-6LoRH-coalescence}}.

The router then coalesces the Compression Reference with the first entry of the
first RH3-6LoRH header as discussed in {{sig-comp-ref}}. If the type of the
RH3-6LoRH header is type 4 then the coalescence is a full override.

Since the Compression Reference is an uncompressed address, the coalesced IPv6
address is also expressed in the full 128bits.

~~~~

Packet as received by node A
----------------------------
  Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA AAAA
  Type 1 RH3-6LoRH Size = 0                  BBBB
  Type 2 RH3-6LoRH Size = 1             CCCC CCCC
                                        DDDD DDDD

 Step 1 popping BBBB the first entry of the next RH3-6LoRH
Step 2 next is if larger value (2 vs. 1) the RH3-6LoRH is removed

  Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA AAAA
  Type 2 RH3-6LoRH Size = 1             CCCC CCCC
                                        DDDD DDDD

 Step 3: recursion ended, coalescing BBBB with the first entry
Step 4: routing based on next segment endpoint to B
Packet as received by node B
----------------------------
  Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA BBBB
  Type 2 RH3-6LoRH Size = 1             CCCC CCCC
                                        DDDD DDDD

 Step 1 popping CCCC CCCC, the first entry of the next RH3-6LoRH
Step 2 removing the first entry and decrementing the Size (by 1)

  Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA BBBB
  Type 2 RH3-6LoRH Size = 0             DDDD DDDD

Step 3: recursion ended, coalescing CCCC CCCC with the first entry
Step 4: routing based on next segment endpoint to C
Packet as received by node C
----------------------------

  Type 3 RH3-6LoRH Size = 0   AAAA AAAA CCCC CCCC
  Type 2 RH3-6LoRH Size = 0             DDDD DDDD

Step 1 popping DDDD DDDD, the first entry of the next RH3-6LoRH
Step 2 the RH3-6LoRH is removed

  Type 3 RH3-6LoRH Size = 0   AAAA AAAA CCCC CCCC

Step 3: recursion ended, coalescing DDDD DDDDD with the first entry
Step 4: routing based on next segment endpoint to D
Packet as received by node D
----------------------------
  Type 3 RH3-6LoRH Size = 0   AAAA AAAA DDDD DDDD

Step 1 the RH3-6LoRH is removed.
 Step 2 no more header, routing based on inner IP header.

{: #RH3fwd title='Forwarding packets with RH3-6LoRH.'}

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 18 janvier 2016 18:54
To: [email-masked]
Cc: [email-masked]; Routing Over Low power and Lossy networks <[email-masked]>
Subject: [6tisch] Proposed improvement in RH3-6LoRH

Dear all

Any opposition?

Pascal

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Jan 2016 17:47:09 -0500

> On Jan 19, 2016, at 2:32 PM 1/19/16, Simon Duquennoy <[email-masked]> wrote:
> 
> Hi Pascal,
> 

Along the same lines: suppose a node that does not employ 6LoRH builds a datagram D using an RH3 header that cannot be compressed by 6LoRH.  Now, how does an intermediate node that is configured to use 6LoRH on an interface over which D is forwarded correctly apply 6LoRH in such a way that the original D can be reconstructed at the eventual destination?

- Ralph

> On Tue, Jan 19, 2016 at 8:15 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> Hello Simon:
> 
> 
> 
> On Tue, Jan 19, 2016 at 1:59 PM, Tengfei Chang <[email-masked]> wrote:
> 
> Hello Pascal,
> 
> 
> 
> On Tue, Jan 19, 2016 at 11:00 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Tengfei:
> 
> 
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Jan 2016 17:47:09 -0500

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Jan 2016 07:24:45 +0000

Hello Ralph:

6LoRH can compress all RHs. If people have the same 75 bits in all addresses and then the compression will use type 3 with the alignment to 8 Octets. This will cause a waste of 11bits per address, these bits being known and yet transmitted. If we could align down to the bit we'd get a better compression. But it would take half of the type space to signal.

The point here is whether an the alignment to 1 2 4 8 16 Octets are enough for real world use cases or whether we should consume more type space.

Or else we could devise a different system but then it is more then high time to do it, and certainly too late for the plugtest. An example of a different system would be the each address has a prefix length of what's common with the previous address. We found that in the real world people align all addresses the same way so the factorization in 6LoRH was found more efficient.

Cheers,

Pascal

> Le 21 janv. 2016 à 00:20, Ralph Droms <[email-masked]> a écrit :
> 
>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Sat, 23 Jan 2016 14:06:27 +0530

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 > 
[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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 23 Jan 2016 09:04:27 +0000

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.

inside the RPL domain. The automatic assumption of a well known root may not apply

?  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:
> 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<http://www.mailscanner.info/>, and is
believed to be clean.

---

From: "S.V.R.Anand" <[email-masked]>
Date: Sun, 31 Jan 2016 10:17:47 +0530

Hi Pascal,

Sorry for the long delay in responding your mail! I am opening up a new 
thread
as you suggested since the topic on retaining or dropping addresses is 
really
interesting.

Thanks a lot for the detailed response for my innocuous observation on using
the reverse address for the sake of using a symmetrical path. Never realized
the security implications! Thanks for the reference to P2P RPL.

Here is my further take on the topic.

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.

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.

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 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.

Am I making sense ?

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