High DAL Network Stack Overview for Geekfest 2024
From DDCIDeos
Jump to navigationJump to search
Overview for Geekfest '24: High-DAL UDP Stack
Context
- We've long have DAL-E stack (LwIP) supporting development tools.
- Customers are interested in networking usable for programs with specific needs.
- Specifically: Multiple customers asking for high-DAL stack that does UDP and/or TSN.
- Current potential launch customer wants UDP.
Goals
- Protocols: at least UDP, IP, ICMP, ARP, likely IGMP.
- APIs: sockets. Soon 653 ports.
- High DAL (DAL-A).
- Architecture accomodates TSN (later).
- Eliminate need to schedule a network server in a window, and eliminate surprising latencies.
- Later add more protocols (eg TCP).
Notes
- UDP provides few guarantees and high DAL doesn't change that.
- High-DAL stack not expected to replace DAL-E stack used for development.
- Hoping to base on code from existing stack (like LwIP).
Draft Design
- WORK IN PROGRESS!
- A partition / RMA process that's a network client imports "libnetstack.so"
- Each partition registers for the protocols/ports it will be using
- (Is this static configuration at OS startup??)
- Each partition receives only the frames for its protocols/ports
- Relies on SoC hardware that parses/filters/classifies frames and routes them to particular queues!
- Partition interacts with its hardware receive and transmit queues via PRL.
- No interaction with a server needed for steady-state communication
- libnetstack.so exports socket APIs to tasks in the partition; creates a task that handles:
- timers
- hardware receive queue
- Each partition registers for the protocols/ports it will be using
- One distinguished partition, the lite-server, handles the "global" protocols and shared state -- ARP, ICMP, IGMP, ..
- Some operations (eg, ARP request) become requests to lite-server, which performs operation and updates tables visible to all network client partitions.
- Refactoring ordinary stack responsibilities between network-client partition and lite-server (maybe some are shared?).
Current Activities
- Discuss: architecture/design.
- Investigate: Are there reasonable starting points -- open-source (eg LwIP), commercial.
- Draft: Tasks and scope.
Appendix: TSN
- TSN
- Is a collection of IEEE Ethernet standards.
- Aims to be a vendor-agnostic solution for deterministic Ethernet.
- Support time-critical networking with guarantees on availability and latency. (Focus on worst case.)
- Support sharing network with ordinary best-effort Ethernet traffic (that focuses on average performance).
- Not vendor agnostic yet.
- Schedule the bus bandwidth. Some classes of frames designated as scheduled (time sensitive) traffic, others designated as best-effort traffic. Switches and (TSN) end nodes receive the schedule and follow it.
- TSN needs
- Time synchronization (PTP)
- Configuration (generate schedule and distribute to end nodes and switches)
- Traffic scheduling (on end nodes and switches)
- How possible is it to support TSN without being wedded to particular vendors?
| Feature | IEEE Standard | Notes |
|---|---|---|
| Time synchronization | 802.1AS-2020, IEEE 1588 | .1AS is a profile of 1588. 1588 is PTP. |
| Scheduled traffic | 802.1Qbv | outbound frames. .1Q is VLANs. |
| Credit Based Shaper | 802.1Qav | Forwarding and Queuing for Time Sensitive Streams |
| Per-Stream Filtering and policing | 802.1Qci | PSFP. inbound frames |
| Frame preemption | IEEE 802.1Qbu, 802.3br | .3 is PHY/MAC |
| Frame replication/elimination for Reliability | IEEE 802.1CB | FRER |
| Cyclic queuing and forwarding | IEEE 802.1Qch | |
| Stream Reservation Protocol | 802.1 Qcc | Central Network Controller, Centralized User Configuration |
| MORE! |