Hello, For the newbies out here in 6LowPan land, what does HC1g refer to?
I assume it is part of some current draft proposed within IETF. Could you point me to the exact draft? Thks "The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum Robert Assimiti Executive Staff Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 [EMAIL PROTECTED] -----Original Message----- From: Jonathan Hui [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2008 4:01 PM To: Pascal Thubert (pthubert) Cc: 6lowpan; Jay Werb; [EMAIL PROTECTED]; Robert Assimiti Subject: Re: HC1g and HC2g Hi Pascal, -- Jonathan Hui Pascal Thubert (pthubert) wrote: > 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. Yup. The reason why I tied it to the eliding of L3 addresses is in the case where each 15.4 node is doing L3 forwarding and modifying the Hop Limit. I don't want a 15.4 node having to do a memmove() simply to insert a Hop Limit when forwarding it to the next hop. But I am fine with having a router that's forwarding to the outside world to eat this cost. Maybe the rule should state if more than one IP hop is taken in the PAN, then the Hop Limit must not be compressed. For the assumptions, yes, I'm continuing to assume that 15.4 nodes will operate in stub networks. > 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. I had originally proposed with HC1g to move HC2 after the compressed L3 header. In this scenario, putting NH into HC2 doesn't work because the position of HC2 depends on whether the Next Hop field appears in the compressed L3 header or not. If you look at the IPv6 header architecture, the Next Header field always describes what header is coming next. So it's a pretty well understood concept. In the 6LoWPAN adaptation layer, however, we did design it in the way you suggest. If we want flexibility in the HC1 header, I'd argue replacing VTF with a bit that expands the HC1 header by another byte and put the VTF bit there. I like reserving extra room in the HC2 header because I'd also like to make provisions for using stateful compression of the UDP ports. -- Jonathan Hui > 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 This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
