Ouroboros Packet Network Architecture

• Ouroboros Packet Network is a clean-slate, recursive packet-switching architecture that decomposes networking functions into minimal, composable building blocks.
• The architecture distinguishes unicast and broadcast layers to enable flexible, performance-driven service composition with quality-of-service contracts.
• A user-space prototype demonstrates its minimal API, header minimization, and efficient performance metrics across various network scenarios.

Ouroboros is a clean-slate, recursive packet-switching architecture designed to decompose the fundamental mechanisms of networking—such as routing, naming, forwarding, reliability, and congestion control—into minimal, composable building blocks, while enforcing a strict separation of concerns and providing uniform, technology-agnostic APIs. Unlike traditional protocol stacks defined by function (e.g., link, network, transport), Ouroboros layers are distinguished solely by their scope: each is a distributed application composed of Inter-Process Communication Processes (IPCPs), recursively stacked, with unicast and broadcast mechanisms realized as logically distinct, composable layers. This model removes artificial boundaries between protocol classes and enables flexible, explicit composition of network services across all scales—from single-machine links to global networks. A functioning user-space prototype demonstrates the architecture’s API uniformity, header minimization, protocol decoupling, and performance across several quality-of-service classes (Staessens et al., 2020).

1. Recursive Layering by Scope

Ouroboros replaces traditional function-based layering (such as OSI or TCP/IP) with recursive layering by scope, building on the observation from RINA (Day 2008) that all network layers fundamentally provide the same mechanisms but for different sets of participants. Each Ouroboros layer is formally represented as a connected subgraph of a digraph $G=(V, A)$, with network topology captured by vertices (IPCPs) and arcs (potential flows). A given layer spans a participant set distinguished purely by scope, not function: no a priori distinction exists between a “Layer 2” and a “Layer 4”; only the members of the layer differ.

Layers recursively stack, such that a layer of wider scope may use as substrate several narrower-scope layers, themselves potentially recursively defined down to the hardware, virtual interfaces, or intra-machine communication. Each layer exposes a common packet-delivery service interface upwards and acts as a client of the flow allocation interface from a next-lower layer.

2. Unicast and Broadcast Layer Separation

A distinctive Ouroboros design decision is the separation of unicast and broadcast as fundamentally different mechanisms, in contrast to conventional architectures that conflate multipoint communication with either unicast overlays or in-network multicast. This separation results in two disjoint classes of layers:

• Unicast Layers: Provide a point-to-point packet-delivery service, called a “flow”, between two endpoint IPCPs under a negotiated quality-of-service (QoS) contract (e.g., fixed delay, loss, bandwidth, ordering). Unicast forwarding is performed with local tables ensuring acyclic, loop-free paths towards the destination, in which every hop strictly decreases distance according to a defined metric.
• Broadcast Layers: Realize many-to-many delivery via stateless or stateful flooding. Each broadcast flow is instantiated over a set of IPCPs, and packets arriving are retransmitted on all outgoing arcs except the incoming one, optionally with loop-suppression fields (source ID and sequence number). Broadcast layers are used for link-state advertisement dissemination, service discovery, and group communication.

Unicast and broadcast layers can be stacked independently—e.g., unicast layers may employ an underlying broadcast layer for link-state updates, but applications are free to select, compose, or bypass either as direct substrates.

3. Layer Interfaces and Primitives

Ouroboros defines a minimal and uniform set of interface primitives for both unicast and broadcast layers. These are exposed through a technology-agnostic application API with the following core operations:

• flow_alloc: Allocate a unicast flow to a named destination and QoS specification.
• flow_accept: Accept a unicast flow request, blocking until a client connects.
• flow_join: Join a named broadcast flow within a broadcast layer.
• flow_dealloc: Tear down (deallocate) an existing flow.
• flow_write / flow_read: Transmit or receive data on a flow.
• fccntl: Flow and connection control operations (e.g., nonblocking modes, fragmentation, window control).

Internally, unicast IPCPs use a six-function RPC-like API towards their flow allocators, including registration, query, and flow management. Broadcast IPCPs implement only flow joining, with stateless flooding obviating the need for routing tables.

API Operation	Applicable Layer	Description
flow_alloc	Unicast	Allocate flow to destination
flow_accept	Unicast	Accept and establish flow from client
flow_join	Broadcast	Join or send in broadcast layer

4. Naming, Addressing, and Anycast

Ouroboros implements a strict one-time naming model. A name is an opaque string (service, endpoint, etc.), whereas an address is a compound sequence corresponding to the ordered data-transfer protocol machines (DTPMs) traversed inside IPCPs. Each address component is drawn from a partially ordered namespace, and an address is presented as $$(\mathtt{name}_1 \in \mathcal{A}_1, \mathtt{name}_2 \in \mathcal{A}_2, \ldots)$$.

• Prefix-Based Addressing: A packet for address $(X, Y, Z)$ must match a DTPM chain at each level before advancing.
• Names and DHT Mapping: Names are hashed (default SHA3-256), and a DHT directory returns one or more addresses for each hash, mediating flow setup, service bindings, and discovery.
• Anycast and Relative Location: By design, anycast is realized when a name’s hash resolves to multiple addresses; the DHT can select the closest or least-loaded service instance. Routing is geodesic, built on each IPCP’s distance table, ensuring loop-free forwarding.

5. Routing, Forwarding, and Congestion Control

The architecture enforces a clean separation between routing (distributed computation of next hops) and forwarding (per-packet lookup):

• Routing: In a unicast layer, any routing algorithm is acceptable provided that neighbor selections $H(v) \subseteq N(v)$ for each source–destination pair enforce acyclicity, uniqueness of source/sink, and monotonic decrease in a chosen distance function $d$. The reference implementation uses a link-state protocol (similar to OSPF) with Dijkstra’s algorithm, optionally collecting Loop-Free Alternates for resilience.
• Forwarding: Each incoming packet’s destination is matched by a radix trie or hash table keyed on $(\text{level},\text{Dst DTPM},\text{QoS class})$; computational complexity is $O(\ell)$ with typical header depths $3\!-\!5$ fields.
• Congestion Control: Marked with ECN-style bits in the data-transfer header, congestion detection and control is handled independently of flow control, with end-hosts dynamically adjusting the FRCP (Delta-t-based) congestion window. Link weights in routing incorporate both bandwidth allocation and measured load.
• Broadcast Layer Routing: No routing table is necessary; stateless flooding is default, with stateful suppression of duplicates and loops implemented as needed.

6. Prototype Implementation and Performance

A full user-space prototype targeting POSIX systems is implemented as:

• A core C library, exposing the application API, event handling (kqueue), QoS management, and FRCP mechanisms.
• An IPC Resource Manager daemon (IRMd) managing host registry, process tables, and acting as central orchestrator for flow allocations.
• Seven IPCP daemons supporting unicast, broadcast, Ethernet over 802.2 and Ethernet II, UDP tunneling, loopback, and a NetFPGA-based “raptor” L1 proof-of-concept.
• Supporting CLI and diagnostic tools for process registration, network enrollment, TUN device instantiation, and test applications.

Performance benchmarks (Xeon servers, 10 GbE LAN):

• Raw QoS unicast, no fragmentation: average 0.043 ms RTT over 4 hops, 0% loss, occasional out-of-order.
• Voice QoS: 1% loss and timeouts under overload.
• Data QoS: 0.048 ms RTT, no losses or reordering.

7. Design Insights and Future Directions

Ouroboros enforces complete decoupling of mechanism from policy. Each layer is unaware of underlying technologies (Ethernet, IP, Wi-Fi, etc.), treating them as interchangeable flow allocation layers. The data-transfer header is minimal, with only five fields (TTL, destination address, QoS class, ECN, endpoint ID), and all necessary mutable state is explicit. Policy dimensions (e.g., link-state vs. geographic routing; DHT vs. database for name directory; stateless vs. stateful broadcast) are abstracted from the mechanism, permitting replacement or evolution without impact on application interfaces.

The architecture’s explicit distinction of unicast and broadcast layers eliminates the need for traditional multicasting, reducing complexity typically associated with overlays and middleboxes. Recursive code and mechanism reuse (FRCP, QoS scheduling, event handling, allocation) applies uniformly to all scope levels.

As network environments confront scaling (e.g., BGP growth, IPv4 exhaustion, middleware proliferation, and mobility), using self-contained, configurable, recursively stacked scopes, as in Ouroboros, is presented as a pathway towards coherent, future-proof packet networking. The implications include convergence on a single uniform API, flexible composition of network services, and a principled approach to layer deployment and service orchestration (Staessens et al., 2020).