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

["Pascal Thubert (pthubert)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Simon Duquennoy
Sent: mardi 19 janvier 2016 20:32
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: Tengfei Chang <[e-mail]>; [e-mail]; Routing Over Low power and Lossy networks <[e-mail]>; [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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.

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Simon Duquennoy
Sent: mardi 19 janvier 2016 18:53
To: Tengfei Chang <[e-mail]<mailto:[e-mail]>>
Cc: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> 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.

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

The picture below illustrates how the RH3 6LoRH works with draft 03 in a case like Root -> A -> B -> C -> leaf

[cid:image001.png@01D152A0.1C780E10]

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)


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

   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)


>  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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tisch



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