Hi Jonathan: In a more general fashion, the hop limit can be elided over the first and the last L2 hops.
On the first hop, either the packet reaches onlink destination, or the router that terminates the 6LoWPAN compression can use a default Hop limit to forward to the world. On the last hop, whatever is is above 1 is as good as 1 since you're done with L3. So the rules can turn out to be: - LoWPAN node that originates the packet can elide the Hop limit. - router performing local delivery over the LoWPAN can elide the Hop Limit ; else the Hop limit MUST NOT be compressed With that set of rules in place I think we're fine with one bit. There are a number of assumptions behind about proxy and stubs, but I think we're OK. I still like the idea to move the NH to HC2. Even if it is an IP header field, it really talks about the HC2 content, and that balances the preserved bits leaving flexibility in HC1G. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: jeudi 6 mars 2008 17:57 >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: HC1g and HC2g > > >Hi Pascal, > >I think it's reasonable to incorporate some of your ideas into HC1g. UDP >checksums make sense. > >I also understand the motivation for eliding the Hop Limit field. But >I'd like to find a way to make it only a single bit. The motivation for >this is in the following paragraph. To me, eliding the Hop Limit field >only makes sense when communicating over a single IP hop. How about a >single bit states if the HLIM is elided or not, and can only be elided >when one of the L3 addresses are completely elided. The latter >restriction ensures that Hop Limit is only elided on the 6LoWPAN side >for a single IP hop. Am I missing a case here? > >If we can remove one bit from HLIM, then I think we can move the NH >field back into HC1. I would remove the L4C bit and say that if NH is >non-zero, then HC2 must be included. I believe NH is still part of the >L3 header, so it should remain in HC1. The S, D, L, and C fields in HC2 >should remain there because they are UDP specific. Also, I was proposing >to move HC2 to the start of the L4 header and putting the NH field there >seems strange to me. > >What do you think? > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> We've been discussing HC1g quite extensively. I'd wish to discuss >> variations on your initial proposal: >> >> ------------------------------------------------------ >> The LOWPAN_HC1g encoding as currently in the draft >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | SC | DC |VTF| NH |L4C| >> +---+---+---+---+---+---+---+---+ >> >> HC2g for UDP >> >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | S | D | L | reserved | >> +---+---+---+---+---+---+---+---+ >> >> >> ------------------------------------------------------ >> >> What seeems to be missing: >> >> - Hop limit compression (takes 2 bits) >> - UDP checksum compression >> >> >> My proposal includes to keep using the mesh header format for route over >> to carry the short addresses and hop limit. >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | SC | DC |VTF| Hlim |L4C| >> +---+---+---+---+---+---+---+---+ >> >> HLIM: >> 00 not compressed >> 01 placed in the mesh header to count PAN hops >> 10 fully elided, packet generated inside the PAN >> 11 fully elided, packet came in a stub >> >> >> >> HC2g for UDP >> >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | NH | S | D | L | C | rsvrd | >> +---+---+---+---+---+---+---+---+ >> >> C: checksum is compressed. >> >> Note1: with that new format you need an HC2g to be able to compress NH. >> I do not mind. >> Note2: if NH is 0 then the NH is placed after the HC2G as it is taken as >> an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 depends >> on that NH. >> >> What do you think? >> >> Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
