Motivation

GNRC's 6LoWPAN has some quality defects in its design, that need to be addressed before @cgundogan can start porting ICNLoWPAN to RIOT. Also I have some issues with certain points in the code that in hindsight I would have done differently.

A model for the 6LoWPAN adaption layer

In a try to solve both problems in my motivation in one go I came up with a model for the 6LoWPAN adaption layer that drafts the different components of 6LoWPAN (fragmentation, IPHC, etc.) as layered sub-modules (in the following referred to as 6Lo modules) with a common API. In reviewing all the RFCs currently available on the adaption layer (RFC4944, RFC6282, RFC7400, RFC8025, RFC8138 (and also some drafts)) I identified 8 6Lo modules (which in turn of course can have their own sub-module). In the following the cursive ones are already implemented in RIOT and need to be refactored to this module:

• Mesh routing
• Fragmentation
• Uncompressed IPv6
• IPHC (This includes implementation for NHC and GHC (since it plugs into IPHC as an NHC format))
• Paging
• 6LoRH
• ICNLoWPAN
• GNRC dispatcher: this just delegates the finally processed datagram to the next layer in the network stack

I omitted HC1 since I believe there is no benefit in ever porting it, but if someone would plan to it would also be its own 6Lo layer.

Every 6Lo modules will provide two functions with the following prototype:

void send(gnrc_pktsnip_t *pkt, void *ctx, uint8_t page);
void recv(gnrc_pktsnip_t *pkt, void *ctx, uint8_t page);

For the more visual inclined, here is a UML diagram I threw together:

The context is there so e.g. the compression models can be handed the reassembly buffer so they can de-compress the packet directly in it instead of awkwardly returning some values by having 3 (!) return values to the compression decode function as it is currently the case (i.e. so we don't have to back-trace into a previous 6Lo layer, once the task of the next layer layer did its job).

How to proceed

I think moving over to this module shouldn't be too intrusive as it is pretty simple and most components are already in a shape that is quite similar. I think @cgundogan can divide most of the refactoring tasks among ourselves.

• Provide GNRC dispatcher (@miri64, gnrc_sixlowpan: Introduce 6Lo GNRC dispatch sub-layer #8512)
• Refactor IPHC / NHC (@miri64, gnrc_sixlowpan_iphc: refactor reception for #8511 #9484 and gnrc_sixlowpan_iphc: refactor sending for #8511 #9485)
• Refactor fragmentation (@miri64, gnrc_sixlowpan_frag: adapt for #8511 #9372)
• Provide paging module (@cgundogan ?)
• Refactor libICNL (@cgundogan, re-use parts of gnrc: generalize gnrc_sixlowpan to enable resuability #8218?)
• Provide GHC module (@A-Paul)

I'm going to open a project to track our process on that more dynamically.