minutes network stack task force april 2015

Minutes from 2nd NSTF meeting on April 30th, 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).

Checksum and next header compression

RFC 6282 states:

  With this specification, a compressor in the source transport
  endpoint MAY elide the UDP Checksum if it is authorized by the upper
  layer.  The compressor MUST NOT set the C bit unless it has received
  such authorization.  Requiring upper-layer authorization ensures that
  the intended transport peer will have sufficient means to deal with
  any data corruption that occurs before reaching the destination.  The
  upper layer MUST NOT provide the authorization unless one of the
  following cases is satisfied:

  Tunneling:  In this case, 6LoWPAN is deployed as a wireless pseudo-
     fieldbus by tunneling existing field protocols over UDP.  If the
     tunneled Protocol Data Unit (PDU) possesses its own addressing,
     security and integrity check (e.g., IPsec Encapsulating Security
     Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the
     tunneling mechanism MAY authorize eliding the UDP checksum in
     order to save on the encapsulation overhead.

  Message Integrity Check:  In this case, either IPsec Authentication
     Header [RFC4302] or some other form of integrity check in the UDP
     payload that covers at least the same information as the UDP
     checksum (pseudo-header, data) and has at least the same strength.

How do we handle this?