-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Uniform network stack integration #13771
Comments
Thanks for the work. I hope to find some time looking at it and giving you feedback. |
@jia200x We just had a longer discussion again about exchanging layers. Can we extend this issue with information about the contents of Apart from that it would be helpful to clarify layer names. EDIT: From my understanding the Layers are well defined. Therefore you architectural picture should reflect these layers. IMO the network stack should include all layers. However in your picture there is at least the link layer not included, and the physical layer missing. I think it would be good to step back a bit and have a complete picture with all network stacks (including some internal details about the APIs), that features all layers. |
WIP - Trying do define layers, and seeing what implementations are there.
|
You are right with the layers approach. The thing is, I just tried to reflect how to integrate existing network stacks (OpenThread, LWIP, OpenWSN, GNRC) into RIOT. So, I just assumed that a "Network Stack" is a block with a southbound API that requires "some glue code" to interact with the OS and a northbound API to interact with the user. However, we should indeed define entry points for each layer. A user should be able to access higher network stack layers (IP, UDP) as well as lower network stack layers (MAC, PHY). |
This is a good overview, thanks! Some comments:
For instance, GNRC provides entry points to L2 (via
|
Sure, I will update the picture to be more specific |
Here's a follow up of the diagram to clarify what I meant (I'm not sure how to include
Some comments:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
side not to this: as discussed with @miri64 maybe it could be interesting to add some kind of L2 sockets (e.g sock_ieee802154, sock_lora, etc). Linux follows a similar approach for IEEE 802.15.4 devices. |
Can we change that to use typed functions? That possibly just return "ENOTSUP"? |
I think it's feasible and would probably force us to have a cleaner integration in the end. The only problem I see, is the fact we have too many divergent NETOPTs in the network interface that might end up in way too many functions. On the other side, we could just define primitives for the network interface (up/down, MTU, l2 technology, etc) and start thinking of layer specific functions that receive a network interface. E.g
It might look tedious, but we have to do this anyway with a generic What do you think? |
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:
Architecture
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:
gnrc_netif_ieee802154
expects an IEEE802.154 SubMAC ([RFC] The IEEE802.15.4 SubMAC #13376 ) to send/recv acknowledged data.Current issues
If the
netif
identifier is independent of the network stack (#12738), both the implementation ofnetif
andsock
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
sock
andnetif
in all network stacksThe text was updated successfully, but these errors were encountered: