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

Hello Dale:

I agree... I think that the idea was to make sure that the buffer you prepare is big enough for the uncompressed form.

When Jonathan and I wrote a proposed rework we changed that as you suggest:
https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-02 
"
   In the following sections, the semantics of "datagram_tag,"
   "datagram_offset" and "datagram_size" and the reassembly process are
   changed from [RFC4944] Section 5.3.  "Fragmentation Type and Header."
   The size and offset are expressed on the compressed packet per
   [RFC6282] as opposed to the uncompressed - native packet - form.
"
The rework addressed the problems discussed in the attached slides, and which are still fully present today.
The work needs support to move on. Last I checked interest was really limited.

Note also this text in RFC 6282:
"

   Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6
   datagrams that do not fit within a single link frame.  Section 5.3 of
   [RFC4944] defines the fragment header's datagram_size and
   datagram_offset values as the size and offset of the IPv6 datagram
   before compression.  As a result, all fragment payload outside the
   first fragment must carry their respective portions of the IPv6
   datagram before compression.  This document does not change that
   requirement.  When using the fragmentation mechanism described in
   Section 5.3 of [RFC4944], any header that cannot fit within the first
   fragment MUST NOT be compressed.

"

Regards;

Pascal

-----Original Message-----
From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Dale R. Worley
Sent: mardi 25 octobre 2016 19:31
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: 6lo@ietf.org
Subject: [6lo] draft-gomez-6lo-optimized-fragmentation-header-00

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> 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

_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

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

Attachment: 6lo Fragment forwarding IETF 88 pthubert .pdf