HC1g refers to a (now expired) draft that attempted to provide effective header compression for non-link-local communication.
HC1g has been replaced with the 6lowpan-hc draft that I posted to the mailing list earlier today. -- Jonathan Hui Robert Assimiti wrote: > 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
