-
Notifications
You must be signed in to change notification settings - Fork 2k
minutes network task force feb 2015
Martine Lenders edited this page Feb 9, 2015
·
7 revisions
| 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 |
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
- 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 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
- 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
- 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
- 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
- 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
preloadandsendsemantic 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 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
- 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
- general steps for forwarding:
- 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
- look into next header field:
- packet received: not for me:
- setting header + options: just implement functions for this.
- packets are set network + transport header on socket/application layer
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.