[6lo] draft-gomez-6lo-optimized-fragmentation-header-00

[[e-mail] (Dale R. Worley)]

"Carles Gomez Montenegro" <[e-mail]> writes:
> This document proposes a more lightweight and compact 6LoWPAN
> fragmentation header, compared with the one defined in RFC 4944.

This seems like an improvement to me, though I'm new here.

But this is a good time to ask my newbie question:  I see this
definition of the "datagram size" field:

   datagram_size: This 11-bit field encodes the size of the entire IP
   packet before link-layer fragmentation (but after IP layer
   fragmentation).  For IPv6, the datagram size SHALL be 40 octets (the
   size of the uncompressed IPv6 header) more than the value of Payload
   Length in the IPv6 header [RFC4944] of the packet.  Note that this
   packet may already be fragmented by hosts involved in the
   communication, i.e., this field needs to encode a maximum length of
   1280 octets (the required by IPv6).

Naively, it seems to me that link fragmentation is at a layer lower than
link compression (e.g., LOWPAN_IPHC), so this datagram_size value is the
length of the IPv6 packet (possibly an IPv6 fragment) as compressed by
LOWPAN_IPHC.  If that is so, the above text isn't quite right, as
e.g. the compressed packet might be shorter than the (reconstructed)
Payload Length in the IPv6 header.

Now maybe I'm wrong, and "datagram size" is the length of the
uncompressed IPv6 packet, but then I don't see how the receiver is to
know when all of the fragments have arrived.

Dale