minutes network stack task force april 2015

Minutes from 2nd NSTF meeting on April, 2015

	Names
Local participants
Remote participants
Minute taker	tbd

Proposed Agenda

• FIB and Reactive Routing Protocols
• Application Layer Protocols
• Socket API
• Header Passing
• Multicast/Broadcast Link-Layer Address Resolution
• Link-Layer Address Length

---

FIB and Reactive Routing Protocols

Though we had kind of a solution in the last NSTF meeting we came to the conclusion that this would not up-hold for nodes with multiple reactive routing protocols.

Socket API

Pure POSIX vs. adaption layer: With the netapi as layer between transport layer protocols and the application (layer) it seems weird why we would need our own socket layer between the POSIX sockets and our own. Why not take the more effective way and use POSIX sockets by default if one wants to use sockets (as far as porting of libs and apps goes you need to use POSIX sockets anyways)?

Application Layer Protocols

• microcoap does not provide an API for generating CoAP requests, what's the best way to implement and integrate such an API?

Header Passing

Disclaimer: his is a detail discussion, the outcome might be integrated in later versions of the network stack

• Oleg raised the question in #2575 whether passing of lower layer headers down the stack is really a good idea?
• Oleg also had concerns about our approach to checksum calculation with pseudo headers, also due to blurring of layer borders.

Multicast/Broadcast link-layer Address Resolution

• The solution Martine came to in #2600 seems somewhat elegant and effective, but maybe someone has an even better idea

Link-Layer Address Length

(vs. sl2ao/tl2ao length): When parsing the Source/Target link-layer address option Martine ran into the problem that one does not necessarily know the length of the link-layer address here because it is derived from the option's length which is given in units of 8 byte, and not byte.

Comparison: 16-bit address and MAC-48 (1 unit):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length (1) |            16-bit short       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length (1) |               MAC-48          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          MAC-48 (cont)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

EUI-64 (2 units)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length (2) |               EUI-64          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          EUI-64 (cont)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        EUI-64 (cont)          |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Expand netapi by OPT_ADD and OPT_REMOVE

Two benefits (according to Martine):

1. clearer handling of list-like options (e. g. IPv6 addresses associated to an interface.
2. Consolidate current boolean options to a bit field and interpret ADD/REMOVE as set/unset and SET as bit-complete assignment for option flags (resulting in less context changes for un/setting of multiple options of this type).