Subject: [6lowpan] draft-bormann-6lowpan-ext-hdr-00.txt

From: Geoff Mulligan <[email-masked]>
Date: Thu, 03 Jul 2008 04:01:47 -0600

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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 3 Jul 2008 14:42:43 +0200

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-masked] [mailto:[email-masked]] 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,

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Jul 2008 12:53:53 +0200

> 1101xxxx, I was just wondering about the change.

Well, I thought NALP was "Not a Lowpan", so given that this packet  
*is* a Lowpan packet, the number space sounded inappropriate.

> This has the advantage that the headers don't have to be broken into

The pieces may not at all be artificial, though.
Having an escape value to use more than 16 bytes out of ~80 does sound  
like unneeded complexity to me.

> protocols and to extend it to another byte if the 6 lower bits are  

Let's do that when that other mesh protocol rings at the front door...

> excellent extension to 4944 and may be used by others.

ISA100 might still be able to use new input like this, if we agree  
that this is the way forward.

Gruesse, Carsten

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 7 Jul 2008 09:53:30 +0300 (EEST)

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Jul 2008 09:10:48 +0200

Hi Jukka,

> unrecognized header

indeed, this would normally be a consideration for an extension  
header, together with a regime for administration of an extension  
number space.
However, running the full gamut of protocol design considerations  
explicitly wasn't my objective here.
My assumption was that management of extensions and their semantics  
was part of setting up the network.

>   message containing it MUST be rejected, and an error message sent

If that is the objective, you might as well use NALP.

>   and the rest of the message processed as usual.

This is the assumption here.

>   processing, but not stored locally.

I'm not sure that is needed (or even possible, without imposing way  
more structure on the extension headers).

So my question to the list would be:
Is the minimal extension header I proposed the right approach or do we  
really have a requirement for the full benefits of extensibility and  
composability that a full-blown extension header approach would bring?

Gruesse, Carsten

---

From: Geoff Mulligan <[email-masked]>
Date: Tue, 08 Jul 2008 10:23:39 -0600

I think the minimal extension header you proposed is right, though I'm
still not convinced about breaking larger headers into pieces on 16 byte
boundaries.

	geoff