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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 1 Nov 2016 21:46:27 +0100

Hi Dale,

Thanks for your e-mail, and sorry for the late response.

Well, Pascal already replied, so I'll just add some additional comment
(inline):

> "Carles Gomez Montenegro" <[email-masked]> 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.

Thanks!

> 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.

Well, the text is the same as in RFC 4944. I get your idea, but
datagram_size was actually defined as the size of the uncompressed IPv6
packet.

I understand that the advantage was that the receiver could determine
exactly how much buffer space was needed for the packet reassembly.

Cheers,

Carles

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