Hi, 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 specifications.
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, Martine [1] https://github.com/RIOT-OS/RIOT/issues/9286 [2] <https://github.com/RIOT-OS/RIOT/issues/9286> https://tools.ietf.org/html/rfc4944#section-5.3 [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/ [6] https://datatracker.ietf.org/doc/draft-bormann-lwig-6lowpan-virtual-reassembly/ [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 [10] https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-13#section-7 [11] https://datatracker.ietf.org/wg/lpwan/documents/
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
