-
Notifications
You must be signed in to change notification settings - Fork 2.1k
RFC: Uniform network stack integration #13771
Description
Description
This PR summarizes the on-going efforts to provide a uniform experience when switching between different network stacks.
With this we should be able to:
- Have the same support for network devices in all network stacks (if the network stack support that kind of devices). LWIP, OpenThread and GNRC support IEEE802.15.4 devices, but only GNRC support of all them.
- Use the same API for sending/receiving data from the application in all network stacks.
- Use the same API for configuring a network stack.
Architecture
+-------------------------------------------------------+
| |
| Upper layers |
| |
+-------------------------------------------------------+
^ ^
| |
Sock Netif
| |
v v
+-------------------------------------------------------+
| |
| Network Stack |
| |
+-------------------------------------------------------+
^ ^
| |
N.S South-bound API N.S South-bound API
| |
v v
+----------------------+ +----------------------+
| | | |
| IEEE802.15.4 | | Ethernet |
| lower layer | | lower layer |
+----------------------+ +----------------------+
There are 3 key components that MUST be implemented by each network stack in order to have a uniform experience:
Sock
Depending on the supported layers (UDP, IPv6, IPv4), each network stack should implement sock_xxx members of the Sock API in order to be able to receive and send data from different layers (network, transport, etc).
The Sock API should use the North-bound API of the network stack for that purpose.
Netif
The network stack should implement the Netif API in order to configure the network stack (e.g setting addresses, setting the interface up, set LoRaWAN keys, get TX power, etc)
South-bound API
Each network stack has a different South-bound API to access the link layers and network device drivers. Some network stacks require direct access to the network device (OpenWSN, OpenThread), while others require access to a Link Layer (GNRC, LWIP).
Some network stacks have support for different link layers, while some others only for one (OpenWSN only supports IEEE802.15.4).
It's important to mention that South-Bound APIs are usually defined for a specific Link Layer technology or network device type. Some examples:
- The current
gnrc_netif_ieee802154expects an IEEE802.154 SubMAC ([RFC] The IEEE802.15.4 SubMAC #13376 ) to send/recv acknowledged data. - OpenWSN expects an IEEE802.15.4 Radio API
Current issues
If the netif identifier is independent of the network stack (#12738), both the implementation of netif and sock API are straightforward because network stacks have defined APIs.
However, South Bounds API are experiencing 2 problems:
Some lower layers are not well divided:
E.g for IEEE802.15.4 radios , the netdev implementation mixes transceiver and link layer logic. This creates problems for stacks that require "radio operations" (prepare, transmit, read) instead of "link layer operations" (send).
On the other hand, some stacks expect that the lower layer handle retransmissions, CSMA-CA and ACK features, but the behavior of the netdev API changes depending on the hardware accelerations present in the device.
Several tasks could be shared between South-bound API implementations
The reason why only a few set of radios are supported in LWIP and OpenThread is because each network stack has to initialize the radios and process their IRQ.
Although a network stack is free to do so, these chores could be unified using e.g event_thread module or similar.
Roadmap
- For each technology, define the boundaries and implement the missing pieces of each component of the lower network stack to make it compliant with South-Bound APIs.
- For example, the IEEE802.15.4 lower layers can be defined as a Radio Hardware Abstraction Layer, a SubMAC ([RFC] The IEEE802.15.4 SubMAC #13376) and hopefully a full IEEE802.15.4 MAC layer.
- Implement the South-Bound APIs with the components from 1.
- Implement
sockandnetifin all network stacks