Subject: [6lowpan] 6lowpan fragmentation and future extensions [was RE: RFC 4944 fragmentation and future extensions]

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Feb 2010 14:34:29 +0100

Hi Jonathan

> Regardless of what we decide to do with the fragmentation header, I
would really like to see a clean separation between fragmentation and
header compression.  Note that saying "compressed offsets/lengths" is a
bit of a misnomer.  It's better to say that offsets and lengths simply
reflect the actual payload being fragmented (which may or may not use
header compression).

 I took off the reference to 4944 in the title because as you indicate,
we are talking about the benefits and consequences of the new HC, as
opposed to maintaining 4944. From Carsten's words and Pete's suggestion,
it would appear that we can leave RFC4944 as it stands, whether it is
widely used as is or gets slowly deprecated by the new HC. For the
subject at hand, that is how to handle fragments in the new HC / RPL
world,  I do agree with you, and with the model that you mentioned
before, that is that the 6LoWPAN compression should be a sublayer above
the fragment sublayer as opposed to be weirdly intertwined. 

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Feb 2010 14:49:34 +0100

On Feb 22, 2010, at 14:34, Pascal Thubert (pthubert) wrote:

> I do agree with you, and with the model that you mentioned

I think a previous message nicely listed the advantages and disadvantages of the usual layering vs. the weird one (compress a single fragment) we adopted in 4944.  But in any case, 4944 fragmentation also works with HC-new, so any new layering would only apply to a new fragmentation format, if we invent one.

Gruesse, Carsten