minutes network task force feb 2015

Minutes from face-to-face meeting @ FU Berlin on February 5-6, 2015

	Names
Local participants	Hauke Petersen (FU Berlin)
	Martine Lenders (FU Berlin)
	Ludwig Ortmann (FU Berlin)
	Thomas Eichinger (FU Berlin)
	Cenk Gündoğan (FU Berlin)
	Jonas Remmert (PHYTEC)
	Emmanuel Baccelli (INRIA), partly
	Lotte Steenbrink (HAW Hamburg)
	Peter Kietzmann (HAW Hamburg)
Remote participants	Oleg Hahm (INRIA)
	Emmanuel Baccelli (INRIA), partly
	Martin Landsmann (HAW Hamburg), partly
	Arvid Picciani (Airfy), partly
	Jan Wagner*, partly*
Minute taker	Peter Kietzmann (05.02.15 only)
IRC scriber	TODO

Please note

These minutes can be understood as a short summarization of the Network Stack Task Force (NSTF) meeting on February 5(-6), 2015. You can also look up contents in the slide set used. The slides are neither complete nor are they meant to function stand-alone as network stack documentation - they are WIP!

In addition, the presentation about the new concept and the discussions from the 5th of February had been recorded and can be played here:

Thursday 5th of February, morning

Thursday 5th of February, afternoon

Preliminary suggested Agenda

• optimizations to the netdev interface
• optimizations to the netapi interface
• analysis of possible data loss using netapi in its current state
• how to pass data/headers/packets around the stack
• possible generalization and/or quotas in the packet buffer
• concepts of global protocol/module list and global protocol handler registry
• API definition for the neighbor table
• API definition for the forwarding table
• possible join for neighbor and forwarding table
• hooks for various routing protocols

Current state and motivation

• current network stack implementation needs refactoring
• multiple redundant buffers
• different APIs and wrappers
• monolithic architecture is not efficient and RIOT-like
• no IPv6 without 6LoWPAN
• no clarity which threads are called by whom
• porting new network devices is hard

Design principles, architecture & general concepts

• we aim for a n energy and memory-efficient solution but not the smallest possible in cause of versatility and functionality
• as we are developing for low power devices, throughput is not our focus
• we aim for a trimmable solution
• we aim for clear and easy-to-use interfaces between all network layers
• these general interfaces should cover heterogeneous hardware

Packet Buffer

• data and headers are stored in a central packet buffer (struct)
  • @Emmanuel Baccelli stated about memory corruption
• for data movement the packet buffer is passed around through pointers
  • @Oleg Hahm stated why passing all headers around is needed
• @Hauke Petersen stated that choosing a reasonable buffer size may be a great improvement comparing to the current implementation
• the proposed API was presented

Netreg

• central registry that connects all network stack modules
• modules/interfaces are registered in the netreg with their PIDs and known procedures
• any module can request the netreg for a PID of a thread that fulfills a special task
• the number of registered interfaces is set during compile time

Netdev

• network devices (e.g. transceivers) are mostly "similar" in their usage
• netdev provides a unified interface between device drivers and the MAC layer
• netdev provides a global list of options and states
• if any device can't handle with one, it just answers with a "don't know"
• this allows to extend the list of options without problems
• device drivers should run in thread context
• the low level receive procedure should not be done in interrupt context (for realtime reasons)
• rx interrupts should just signal that there is data to receive and inform another thread
• the informed thread should do the low level procedure when it is on schedule
• on top netdev there is the netapi interface which also allows to omit netdev
• this gives maximum flexibility
• @Oleg Hahm stated that the preload and send semantic of netdev might be not clear
• @Jan Wagner asked for a case where multiple MAC protocols might be used for one device
  • a solution for this might be to open multiple virtual devices for one physical device

Netapi

• netapi is an asynchronous IPC module for communication between all layers in the network stack
• it forces its connected modules to be in a common style
• with only one interface there is just one test needed

Discussion summary February 5th

• routing and neighbor discovery:
  • general steps for forwarding:
    • look into FIB, get PID for link layer + next hop address
    • translate next hop address to link layer address via NIB
    • send to link layer with given FIB
  • for proactive routing fine, but reactive does not work
    • solution: FIB knows that protocol is reactive, returns PID to routing event loop + next hop address == NULL if no address was found ⇒ network layer does not lookup NIB, but sends immediately to routing event loop which is now responsible for packet

Discussion summary February 6th

• demultiplexing of options/subtypes on example IPv6:
  • packet received: not for me:
    • check for extension headers to find possible source routing extension
    • if found: send to next hop and remove it from source routing extension
    • look into FIB (see February 5th)
  • packet received: for me:
    • look into next header field:
      • give to next protocol if corresponding demux context is registered
    • if extension header: Do the thing
    • if ICMPv6: give to ICMPv6 module
    • ICMPv6 demultiplexes packet:
      • give to next protocol if corresponding demux context is registered
      • if error: handle it
      • if echo: handle it
      • if ndp: give to ndp …… and so on
      • if rpl: give to rpl thread
• setting header + options: just implement functions for this.
• packets are set network + transport header on socket/application layer

Conclusion

A task list for the network stack refactoring can be found in this issue. Until the network stack is under refactoring, all modules will be perpended with ng_. When all modules are ready (this means reviewed and ACKed) there will be a changeover to the new network stack during one day/night.