Triggered by an issue a short while ago [1], and the necessity for IPv6
fragmentation/reassembly that crystalized out of that, I remembered that
Cenk and Jose were in the talks of a general fragmentation/reassembly
library for GNRC. Is this still on the table? If yes, I think we should
discuss this, so I collected some requirements from the existing

Currently, I'm aware of three types of fragmentation/reassembly that are of
interest for RIOT:

1. 6Lo fragmentation [2] for local/personal-area-based link-layers that
don't support fragmentation themselves and which adoption is handled by the
6lo working group [3] (AFAIK this only includes IEEE 802.15.4 and PLC
[which is currently in draft stage [4]). This also includes ICNLoWPAN [5].
Fragmentation is handled hop-by-hop, but there are also solutions put
forward [6] [7], to allow fragment forwarding. Fragments are distinguished
between 1st fragments and subsequent fragments, and are identified for
reassembly by tuple of link-layer source address, link-layer destination
address, datagram size, and a sequential datagram tag (created by the
source node). For mesh-under mode, the soruce and destination address are
replaced with the originator's and and final destination's address from the
mesh header. In case of 6Lo fragmentation, the first header always needs to
include all compressed headers (ICNLoWPAN does not have this restriction)
and the overall datagram size denotes the size *before* compression*.
Fragments might be received out of order.
2. IPv6 fragmentation [8] for IPv6 packets that are larger than the path
MTU. Fragmentation is handled end-to-end, so the fragments are identified
by a tuple of IPv6 source address, IPv6 destination address and a Fragment
identifier, which generation is up to the source and for which some example
algorithms are provided in [9]. Notable fragment types first fragment,
subsequent fragment and last fragment. All IPv6 extension headers and the
upper layer header need to fit into the first fragment. Fragments might be
received out of order.
3. Lastly there is SCHC F/R [10] for wide-area-based link-layer that don't
support fragmentation themselves and which adoption is handled by the lpwan
working group [11] (like e.g. LoRAWAN or SigFox). It assumed fragments are
not delivered out of order and provides several reliability modes. Due to
latter there are several types of fragments (which I'm not quite sure yet
how they interact with each other, but maybe some people more knowledgeable
in LPWAN can interject here). Fragments are identified by a tuple of the
link-layer source address (if present), the link-layer destination address
(if present), the Rule ID (which describes the type of fragment header
format) and a sequential datagram tag (if present). Again lpwan people,
please fill in the holes, I might have left.

As can be seen, there are some similarities, which is why I think a common
library could be useful to avoid code duplication and reduce overall
codesize, but there are also several differences that need to be dealt with.

Kind Regards,

[1] https://github.com/RIOT-OS/RIOT/issues/9286
[2]  <https://github.com/RIOT-OS/RIOT/issues/9286>
[3] https://datatracker.ietf.org/wg/6lo/documents/
[4] https://datatracker.ietf.org/doc/draft-hou-6lo-plc/
[5] https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnlowpan/
[7] https://datatracker.ietf.org/doc/draft-watteyne-6lo-minimal-fragment/
[8] https://tools.ietf.org/html/rfc8200#section-4.5
[9] https://tools.ietf.org/html/rfc7739#section-5
[11] https://datatracker.ietf.org/wg/lpwan/documents/
devel mailing list

Reply via email to