> On Jan 19, 2016, at 2:32 PM 1/19/16, Simon Duquennoy <[email protected]> wrote: > > 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..).
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 > 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 protected]> 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: [email protected] [mailto:[email protected]] On Behalf > Of Simon Duquennoy > Sent: mardi 19 janvier 2016 18:53 > To: Tengfei Chang <[email protected]> > Cc: Pascal Thubert (pthubert) <[email protected]>; [email protected]; Routing > Over Low power and Lossy networks <[email protected]>; [email protected] > 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 protected]> > 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 protected]> 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 > > > > <image001.png> > > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo > > > > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
