> >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.
[Pascal] I would not use must :) but I see what you're saying. If you have RFD types of devices they wouldn't know what to expect. They can be configured to do one way or the other for a given deployment. Note that with the single bit, we can not detect the case where a packet bounces from one router to another due to improper L2 operation but stays within the PAN. > >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. > [Pascal] Remember I took great care to place the expanded NH after HC2. So that it works (see the note at the very bottom of this mail). Just that when you read HC2, if the HC bits are 0 you need to read the full HC after HC2 to parse the bits in HC2. I do think it's still cleanly putting L4 things together - and TLV is also a well understood concept ;) >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. [Pascal] But will that be enough anyway? Hard to know what to reserve for this so I'd do whatever seems right with what I have. I'd rather expand HC2 later with whatever room you need when you know more precisely what it is you need and leave VTF in place right now... Pascal > >-- >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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
