Hi Jonathan: So a compressed packet will have a number of (LOWPAN_NHC + rest of option) in sequence.
>- What do people think of the basic support for IPv6 extension headers? I love it. I think that ROLL might need compressing routing headers and we could very well be deprecating mesh header altogether. >- What do people think about changing the length field to 1-octet >granularity? Rather positive since it save stuff -trailer pads - and is easy to do, not sure it's important >- What do people think about removing the length field from the hop-by- >hop/destination options headers? Rather negative for complexity reason, not sure it's important either. Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Hui >Sent: mardi 7 avril 2009 21:06 >To: [email protected] >Subject: [6lowpan] HC - IPv6 Extension Headers > > >Hi Everyone, > >During the WG meeting, we discussed the need to add support for IPv6 >extension headers. There are two points to supporting IPv6 extension >headers: >1) Allowing upper-layer header compression (e.g. UDP) in the presence >of IPv6 extension headers. >2) Allowing more compact forms of IPv6 extension headers. > > From the WG meeting, there seemed to be consensus that case 1 is >important to support. In particular, there are good use cases for IPv6 >extension headers in 6lowpan networks. The proposal to support case 1 >that was discussed in the meeting is as follows: > >The LOWPAN_NHC encoding for an IPv6 extension header involves a 7-bit >NHC identifier followed by a 1-bit NH field that indicates whether >the Next Header field is carried inline or the following header is >compressed using LOWPAN_NHC. The encoding follows the following format: > > 0 1 2 3 4 5 6 7 >+---+---+---+---+---+---+---+---+ >| 1 | 1 | 1 | 0 | 0 | Type |NH | >+---+---+---+---+---+---+---+---+ > >Type: > - 0: Hop-by-Hop Options Header > - 1: Routing Header > - 2: Fragment Header > - 3: Destination Options Header > >NH: Next Header > - 0: Full 8 bits for Next Header are carried in-line. > - 1: The Next Header field is compressed and the next header is >compressed using LOWPAN_NHC > >When LOWPAN_NHC is used for all IPv6 extension headers and the upper- >layer header, the end result is that the 8-bit Next Header field is >replaced by 8-bit LOWPAN_NHC encoding above. No other changes to the >IPv6 extension headers are required. > >The above is probably a good base level of support for IPv6 extension >headers. But now to address the second point: allowing more compact >forms of IPv6 extension headers. The main concern here is on the 8- >octet granularity of the Hdr Ext Len field in the Hop-by-Hop and >Destination Options headers, wasting up to 7 bytes of padding. There >are two ways we can overcome this: >1) Change the meaning of the Hdr Ext Len field to 1-octet granularity >when LOWPAN_NHC is in use. If Hdr Ext Len truly exceeds 255, then >LOWPAN_NHC cannot be used - a rare case, I think, but still needs to >be addressed. >2) Remove the Hdr Ext Len field all together, save another byte, and >rely on the length field of each option to reach the next header. The >downside is that one cannot simply jump to the next header without >going through each option. In practice, I don't see 6LoWPAN networks >including a large number of options. > >In both cases, Pad1 and PadN options cannot be elided unless they >appear at the end of the options list. This is to make sure that any >alignment requirements for the options are satisfied when expanding >the datagram. > >Note that changing the meaning of the Length field (Case 1) can also >be applied to the Routing Header. Finally, I don't think there is much >we can do with the Fragment Header. > >So some questions to guide the discussion: >- What do people think of the basic support for IPv6 extension headers? >- What do people think about changing the length field to 1-octet >granularity? >- What do people think about removing the length field from the hop-by- >hop/destination options headers? > >We are down to two open issues before we can LC the HC document (the >other being compression of multicast addresses). I'd like to resolve >these issues hopefully within the next week so that we can move >quickly towards LC. So send your thoughts! > >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
