Ouroboros

Rebuilding packet networks from the ground up.

Example Multi-Layer Ouroboros network (visualized using Rumba)

Computer networking is a lot more complicated than it needs to be.

Ask anyone who has moved a rack of servers. The machines move in an afternoon; the network takes the rest of the week.

Ouroboros (O7s for short) is a prototype packet-switching technology built on the premise that none of this complexity is fundamental. It is a redesign of the Internet model, from the programming interface almost down to the wire, with one goal: networks that are simple to set up, simple to understand and simple to run.

It is an alternative to TCP/IP, but it is perfectly happy to run on top of it.

Why not just fix the layer model?

Every networking course starts with the same picture: a stack of layers, seven in the textbook, five in practice. Physical at the bottom, then link, network, transport and application, each with its own job and its own protocols. TCP/IP is the set of protocols that fills in the slots. The trouble is that the picture is wrong, and everything built on it inherits the flaws.

Real networks don't fit the picture. VLANs, MPLS, tunnels, VPNs and overlays are networks inside networks, and the model has no slot for them, so they end up as "layer 2.5" with their own ad-hoc rules. If IP is the network layer, what is ICMP, which runs on top of IP and is also in the network layer? When the examples don't fit the model, it is the model that is wrong.

The layers are welded together. On paper, a layer only talks to its neighbors. In practice, the Ethernet frame says which network protocol it carries, the IP packet says which transport protocol, the port number says which application, and the socket interface bakes the IP address format into every program. Nothing can be replaced on its own. That is why adding IPv6 became a decades-long slog, and why the core protocols haven't changed in thirty years.

Security has no layer. The model has no notion of who you are talking to. Names are an afterthought, and the network delivers any packet from anyone to any open port. So security is bolted on at every layer separately, from Wi-Fi encryption to IPsec to TLS to application logins, and the gaps in between are where the attacks live: forged source addresses, amplification, port scanning. Deploying a service on the Internet means venturing into a lawless warzone, and defending it is a perpetual arms race.

And the industry is built around the picture. Standards bodies, vendors, teams and research groups all sit along the same layer boundaries, and Conway's Law takes care of the rest: no change that crosses a layer ever gets made. Every so often a single BGP misconfiguration takes a global service offline for hours, and the answer is always another box strapped to the side of the network, a NAT, a firewall, a load balancer, a VPN, and never a fix to the model.

These are not bugs to patch. They are consequences of the model. There is no incremental path to fix the Internet starting from the five-layer stack.

What Ouroboros does instead

One kind of layer, used at every level. Ouroboros replaces the five fixed layers with a single design that repeats. A layer names its services, addresses its members, forwards packets and sets up flows, and it is itself built on flows from the layer below. Whether a layer runs over Ethernet, over UDP or over another Ouroboros layer, it looks the same, is configured the same way and offers the same service upward. The picture at the top of this page is such a stack. Learn it once.

Names, not addresses. A service has a name, and that is all a client needs to know. The name is bound to a process, not to a location; the layer's directory keeps track of where the service is.

Flows, not sockets and ports. An application asks the system for a flow to a name and says what it needs: how much delay it can tolerate, whether every byte must arrive, whether the peer must be authenticated, whether the data must be encrypted. The system does the rest and hands back a descriptor to read and write. Six function calls cover the whole application interface.

Trust before the first byte. The keys needed to authenticate a service come from the naming system, not from the other end of the connection. A flow is authenticated, and if requested encrypted, before the application sees any data. Endpoint identifiers are random and live only as long as the flow, so there is nothing to scan for, and forged packets get an attacker nothing: replies go to the stored peer, not to the forger.

One configuration file per machine. Applications carry no network configuration. A single file tells the system which layers to join and which names to serve, and every application on the machine inherits it.

What the prototype already shows

The prototype runs in user space on Linux, *BSD and OS X. It is a proof of concept to toy around with, not production software, but the core claims of the model are running code. The tutorials walk through the prototype:

• Names and flows work as described. Bind a name to a process, allocate a flow to it, ping (01). Two processes on the same machine need no network layer at all.
• Layers stack. Multi-node layers are bootstrapped, joined and connected (02), run over Ethernet (04) or UDP/IP (05), and are set up from a single configuration file (03).
• Security is part of the handshake. Servers, clients and the daemons joining a layer authenticate with certificates (06); flows are encrypted and re-keyed on the wire (07).
• Reliability is a service, not an application feature. A reliable flow repairs a lossy link with retransmission (08).
• Congestion control is built in, for everyone. Flows share a bottleneck fairly without a single dropped packet, and no flow can opt out (09). Loss recovery and congestion control run as separate loops on a lossy, delayed link. (10).
• Anycast and load balancing between several instances of a service come for free from the naming model (02, 05).

The implementation overview has the status per component. A quick overview vs TCP can be found here: Ouroboros_and_TCP/IP.

There's a lot more to be done, but there's only one way to eat an elephant: one bite at a time.

Where it comes from

Ouroboros builds on two decades of European research into future networks, including the Recursive InterNetwork Architecture (RINA), and on four decades of hindsight about what went wrong with the Internet. In 2016, after working on the IRATI kernel prototype of RINA, we started over from scratch in user space, to steer around issues we saw in the RINA model and to keep the barrier to entry low. We have been taking the prototype forward in our spare time ever since; the full history has the details.

Dig deeper

A word of warning: if VLANs, subnets and BGP are your daily bread and butter, some of this will sound awkward at first, and some of the terminology could use an overhaul. Once the penny drops, it should prove rewarding.

• Ouroboros Functional Layering: the model behind the prototype
• Ouroboros Tutorials: hands-on, from a single machine to a lossy, congested link
• Ouroboros Implementation Overview: what is done and what is missing
• Glossary: the vocabulary
• History of Ouroboros: where it came from
• Source code on Codeberg
• Questions? Ask on our matrix channel, or pick another means of contact.