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

[Simon Duquennoy <[e-mail]>]

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]>
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]> 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
>>
>>
>>
>> [image: 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]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>
>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>
>