Hi,
About the skipping of extension headers, in the NSIS protocol work we used
two flag bits (A&B) that tell a receiving node what to do when it parses
through a header and finds an unrecognized header:
AB=00 ("Mandatory"): If the object is not understood, the entire
message containing it MUST be rejected, and an error message sent
back.
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted
and the rest of the message processed as usual.
AB=10 ("Forward"): If the object is not understood, it MUST be
retained unchanged in any message forwarded as a result of message
processing, but not stored locally.
I wonder if something similar could be used in 6lowpan?
Cheers,
Jukka
On Thu, 3 Jul 2008, Pascal Thubert (pthubert) wrote:
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
