Hi Jonathan: >After some discussion with Carsten, it seems that we may need both bits >for Hop Limit compression. Current idea now is that 1-bit indicates >compression, another bit indicates whether the elided Hop Limit is 63 or >1. I originally thought we could do egress filtering based on the >destination address, but Carsten thought that it missed the point of the >Hop Limit. The cost is we utilize the reserved bit in the IPHC encoding >and remove any flexibility it could have provided.
You know I started exactly like Carsten. In the thread with you, we discussed that the router that performs a local delivery could elide the Hop limit without the additional bit because it expects that the packet will never appear at L3 again. There are a number of caveats to that approach, including proxy, and indirection. So I do feel safer if we stick to the 2 bits. This might look expensive but if we do the fast path HC3 that we discussed already, then the first bit will be easily defaulted due to the assumption that the LoWPAN is a stub, so the fast path clearly compresses the hop limit. So I'm all for the proposed change. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: mardi 11 mars 2008 13:28 >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble > > >Hi Pascal, > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >> Thanks a lot for this excellent draft. From the standpoint of >> ISA100.11a, it is going a long way in the right direction. I think it is >> actually ripe for election as WG document and you've got my vote for it. >> This is hardly surprising considering your earlier work on RFC 4944 and >> HC1G. > >Thanks. > >> I'll provide my detailed comments separately; the substance, though, is >> that: >> - we need to refine the Hop limit text as you point out > >After some discussion with Carsten, it seems that we may need both bits >for Hop Limit compression. Current idea now is that 1-bit indicates >compression, another bit indicates whether the elided Hop Limit is 63 or >1. I originally thought we could do egress filtering based on the >destination address, but Carsten thought that it missed the point of the >Hop Limit. The cost is we utilize the reserved bit in the IPHC encoding >and remove any flexibility it could have provided. > >> - we should be able to extend the concept of common prefix compress >> global addresses that result from states without being specific on how >> the addresses are passed on, which I understand is another charter item. > >Right. > >> - I'm still interesting in compressing the HCs, but that can be done >> separately. > >Sure. > >Thanks. > >-- >Jonathan Hui > >> >> Thanks again, >> >> Pascal >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Jonathan Hui >>> Sent: lundi 10 mars 2008 19:04 >>> To: 6lowpan >>> Subject: [6lowpan] New 6LoWPAN HC Draft Availble >>> >>> >>> 6LoWPAN WG, >>> >>> There's a new draft available that specifies a new header compression >>> format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It >> also >>> captures some of the discussion with Pascal last week. >>> >>> http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt >>> >>> Read it over before the WG meeting if you get a chance. Provide >> comments >>> or suggestions on the list. >>> >>> Thanks. >>> >>> -- >>> Jonathan Hui >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
