minutes network stack task force april 2015

Minutes from 2nd NSTF meeting on April 30th, 2015

Local participants	Remote participants
Hauke Petersen	Peter Kietzmann
Martine Lenders	Lotte Steenbrink
Philipp Rosenkranz	Jonas Remmert
Cenk Gündogan	Lucas Jens
Kaspar Schleiser	Yannick Raoul
Matthias Wählisch
Thomas Schmidt
Oliver Hahm
Emmanuel Baccelli (minute taker)

Agenda

• Status of Network Stack Implementation and Release Plans
• FIB and Reactive Routing Protocols
• Application Layer Protocols
• Socket API
• Header Passing
• Multicast/Broadcast Link-Layer Address Resolution
• Link-Layer Address Length
• Checksum and next header compression
• Loopback destination address

---

Status of Network Stack Implementation and Release Plans

Let's start out with a small summary of the current state of the 'ng' network stack implementation (also have a look at the TODO list for details). Once we have the network stack in place, we need to think about how to switch over to it (remove the ng_ prefix). Proposal: Le's plan a release for the end of May, do a feature freeze one week earlier and have a dedicated Hack'n'Ack night to do the transfer.

Notes: netdev (function-based API) and netapi (common API with 4 commands get, set, snd, rcv) merged stack wise up to UDP we have "everything" to start testing, merged parts of every layer drivers for xBee, Atmel radios (IoT-LAB, SAMR21...) some stuff missing (only noMAC, NDP, ICMP, IPHC, next header compression)

Kaspar wants to slightly update netdev, but should not change much (slightly more modularization and less dependency)

Jonas is working on MAC layer (802.15.4 compliant). Questions about where to place the CSMA implementation: in the driver? In the MAC?

Cenk working on RPL integration in the new network stack. There is a lack of standardization for non-storing mode (ROLL working group work in progress), but there is no show stopper to start integrating other RPL modes of operation.

Lotte is working on AODVv2 (mostly adapting to the moving target, i.e. the spec in progress). But it makes no sense to start integrating AODVv2 in the new network stack before NDP is merged and reliable.

Emmanuel: maybe it's also fine to use NHDP?

Conclusion:

• NDP is a top priority
• need to document the use of netdev and netapi (basically: this is the default way to go to interface with the new network stack).

Plans for the release:

• target end of May
• Feature freeze one week before
• Dedicated Hack&Ack session to switch over from old network stack to new network stack (remove all the "ng_" stuff)

Features for the release:

• mandatory : NDP (minimal subset including address resolution)
• mandatory : ICMP (in review)
• mandatory : RPL (integration about to start, focus on storing mode first)
• mandatory : FIB
• mandatory : good support for IoT-LAB, SAMR21, xBee and native (ng_nativenet).
• mandatory : example applications working out of the box, minimum: RPL/UDP multi-hop, UDP (single-hop), microCoAP.
• mandatory : Socket API wrapper.
• mandatory : basic import of microCoAP.
• ADDED mandatory : explicit support for border router (e.g. Pi with 15.4 radio module)
• ADDED mandatory? : new low-level driver model
• ADDED mandatory: port of existing CCN-lite to netapi
• ADDED mandatory: port of existing OpenWSN to netdev
• optional : cc1100 driver
• optional : device driver CC2538 radio (Zolertia PR? Hexluthor PR? available hardware at FU OpenMote) optional
• optional : Freescale KW20XX device driver (Jonas?)
• optional : device driver CC2420? (Kevin? locally we have only MSP430 boards, so need to have first low level drivers for SPI, GPIO etc.)
• optional : nrf SOC and nrf (cheap version)
• optional : fix suboptimal support for SAMR21 (e.g. lowest frequency by default)
• optional : one MAC layer.
• optional : Auto-init (already there board specific) also for network stack.

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.

Notes:

Principle: No buffering in the stack. No blocking of the network stack If no route available, drop the packet

• Issue1: the application is not informed about unreachability (shortcoming of the netAPI architecture, based on fire & forget) Hauke mentioned an existing concept(s) to overcome this?
• issue2: assign a routing protocol per prefix
• Issue2bis: assign per prefix/destination behaviour (what protocol is triggered if no FIB entry is there? Is default route used?)
• Issue3: where to store/handle source route? FIB indicates next hop, but who injects the source route in the header?
• Issue4: default route 0.0.0.0 must be put in if default router is known through 6LoWPAN
• Issue5: rename call to register routing protocol to the FIB to being non-reactive specific

Discussed suggestion: another module, independent of the FIB and from the routing protocol, which stores the source routes

Conclusion:

• need for a Routing Information Base (RIB), in case source routing is used (e.g. RPL non-storing mode) No clear concept where to instantiate that and how the information is injected in the header

• mechanism to have signalling back up the stack (e.g. destination unreachable back to the application). Idea: asynchronous signal concept based on PID associated with payload, to which to signal the result of the sending. go the POSIX way? Not mandatory feature for next release.

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)?

notes: Kaspar: need to think about other network stacks (CCN-lite, Kaspar's stack, OpenWSN), which are focusing on extremely low memory footprint. NetAPI + packet buffer is too fat (based on messaging, one thread per layer, flexible but more RAM hungry, not fitting class 0 devices) POSIX socket is also too fat

Question: how to design the co-existence of multiple network stacks? Kaspar: leaner API at the driver level (already some concept developed for that), and leaner API at the application layer

Conclusion: need for a socket design team / task force? Starting after the release.

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?

microCoAP is too under-documented microCoAP is incomplete (just a server, no observe, clumsy to deal with buffers) microCoAP is a one man project, but still active and on GitHub libCoAP: too fat. Feedback to Olaf? Suggested approach based on recent experience: develop microCoAP further? But to be discussed.

Conclusion: first agree on our application layer interface, then look at this.

Header Passing

this 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.

Notes: All is well, Oleg is satisfied ;)

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

Due to added support of ethernet and IPv4, we need to distinguish between multicast and broadcast, IPv4 and IPv6. For now the logic for address resolution is happening in the link layer. It's not super clean for the layering, but it works.

Conclusion: leave it as is for now.

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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes: Conclusion is to set longest addresses and truncate later as needed.

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).

Notes: Conclusions are: No extension of NetAPI, but an additional network configuration option. Change the name of netconf to something else not conflicting with RFC 6241.

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?

Notes: add an network conf option to ask if there is an upper layer checksum is needed?

Conclusion: never compress checksum, for now.

Loopback address

Notes: Conclusion is that the network layer is responsible for handling loopback. There will be no loopback interface.