Hi Geoff and Carsten: I agree with Geoff it's a great idea and we need to move forward with it and work out the details. In particular we need to be consistent with the possibilities that can be encoded of destination options in IPv6 headers and specify whether the unrecognized option can be skipped or not.
What was decided at the ISA meeting in Nice is that 6LoWPAN is applied within the ISA100.11a Data Link as opposed to flat over 802.15.4 MAC. As a result 6LowPAN does not apply to the DL headers themselves so NaLP is not used there. There is no way for a node that does not have a DL layer to decrypt and parse the DL frames anyway. But ISA100.11a wishes to maintain the capability to relay a 6LowPAN packet between an ISA DL link and a plain 802.15.4 link. So ISA100.11a still wishes to converge with 6LoWPAN for the content of the frames. The new format can still be very useful for ISA100.11a, in particular to optimize the compression of the flow label which is still based on NaLP at this stage of the specification. Pascal >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Mulligan >Sent: jeudi 3 juillet 2008 12:02 >To: Carsten Bormann; 6lowpan >Subject: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt > >Carsten, > I think that this is a neat idea. As you state there may be many >layer 2 mesh implementations that need some sort of intermediate header >and for them all to use NALP seems like a bad idea. > >When we talked about this I thought we considered using the reserved >bits of NALP to carry the length value so that 0010xxxx would be the >extension header identifier and length. I'm not opposed to use >1101xxxx, I was just wondering about the change. > >I'm not sure I like the idea of splitting headers greater than 16 bytes >into two pieces with two extension headers. What about again using an >escape value of 1111 to indicate the length is 15 plus the next byte. >This has the advantage that the headers don't have to be broken into >artificial pieces. > >If we don't use the NALP reserved space, has anyone considered allowing >addresses in this space to be registered for specific layer 2 mesh >protocols and to extend it to another byte if the 6 lower bits are all 1 >- 00111111 > >Unfortunately, it seems though that at the last meeting in Nice ISA100 >decided NOT to utilize this idea that we had worked out and plan to >continue to just use NALP. Oh well, I think that this is still an >excellent extension to 4944 and may be used by others. > > geoff > > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
