Hi Pascal, Thanks for sharing your thoughts.
By assuming the first 5 bits in HC1 are '1', you're staking a claim that mesh-under link-local communication within a PAN is going to be most common case and the one we've "shot for". If link-local is all we focus on, then we are missing the point of IP. Frankly, I don't see much benefit of IP if communication is limited to the PAN. W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN nodes will communicate via route-over using routable addresses (e.g. ROLL). This brings us back to a broader topic of route-under vs. mesh-under. While both will probably exist for some time, it raises the question of whether 6LoWPAN implementations can support one or do they have to support both. W.r.t compressing Hop Limit, I don't quite understand why you're using a bit in HC3 to indicate where the message originated. If you're assuming link-local communication, then messages shouldn't be forwarded across links anyway. I do agree that there is work to do on compression and agree that there are cases where HC1 and HC2 are not sufficient. This is why I've been working, albeit slowly, on HC1g. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Dear 6LoWPANers, > > Though HC1 and HC2 provide us with the capability to express any > combination of compression, the most expected (or at least shot for) > case does not lead to a better compression of the HC headers themselves. > > Seems that we could define an HC3 that would compress the pair of HC1 > and HC2 for that best case. My proposal for doing this would be to: > > - define a new dispatch > | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and > transport > > - define HC3 itself to: > > - implicitly say that the first 5 bits of HC1 are all ones > - carry HC1 bits 5 and 6 (Next Header) > - replace HC2 so bit 7 of HC1 is useless > - provide transport specific bits such as those defined for > HC-UDP, > then again assuming a predefined best case if room is missing > > An example of what the HC3 octet could be: > > bits 0 1 2-3 > 4-7 > > +------------------+-------------+-----------------+-------------------- > ---------------------+ > | reserved | reserved | Next Header | transport > specific control bits | > > +------------------+-------------+-----------------+-------------------- > ---------------------+ > > Next header: as defined in HC1, bits 5 and 6 > > transport specific control bits for UDP: > bit 4 echoes HC-UDP bit 0 on UDP source port > bit 5 echoes HC-UDP bit 1 on UDP destination port > bit 6 echoes HC-UDP bit 2 on UDP length > bit 7 is reserved > > What do you think? > > Pascal > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
