Ouroboros Functional Layering
This page is under construction
The Ouroboros model is the result of countless architectural refinements made during the (still ongoing) implementation of the Ouroboros prototype. This page provides an overview of this model as it currently stands, and some insights in how it compares to other models such as TCP/IP, Location/Identifier split and the Recursive InterNetwork Architecture (RINA).
As this prototype started off as an implementation of principles outlined by RINA, the Ouroboros model inherits a lot of concepts and terminology from RINA. As such, that's where the credit for those ideas goes.
Unicast model
Unicast API
The Unicast API provides the interface for an application to create, manage and destroy unicast flows and read and write from and to these flows. The API is network-agnostic and provides application primitives for synchronous and asynchronous Inter-Process Communication. It supports message-based and (byte)stream-based communication.
Application End-to-End layer
The application end-to-end layer provides the functionality to establish flows and make packet transmission on that flow reliable and secure. Unicast flows are initiated by a client process towards a server process, identified by a service name.
The application end-to-end layer can provide the following operations:
- Encryption (Public key or symmetric key)
- Authentication (validation/verification of certificate chains, HMAC)
- Reliability, implemented by the FRCP protocol
- Fragmentation
- In order delivery
- Discarding duplicate packets
- Automated-Repeat Request (retransmission of lost packets)
- Flow control
- Integrity (hash-based checks such as CRC32)
Establishment of the flow, authentication and symmetric key distribution are implemented using a 2-way handshake each. If the MTU allows, the authentication and symmetric key exchanges can be piggybacked onto the flow establishment request/reply in a single combined 2-way exchange, so within a 1 Round-Trip Time. See Flow Allocation for more details.
The application end-to-end layer provides the interface into the network end-to-end layer below.
Network End-to-End layer / Flow Allocator
The network End-to-End layer is responsible for creating a network flow in a suitable Unicast Layer between two Unicast IPCPs (designated the source and destination IPCP) that implements a client flow (between two end-user processes, designated the client process and server process). The source and destination IPCP reside in the same systems as the respective client and server end-user processes.
We often refer to the Network End-to-End layer as the flow allocator after the core component in the IPCP that implements it.
It provides three core functions:
- Name-to-address resolution: given a service name, find an address for a suitable IPCP that can serve as a destination for the network flow. The directory service holds this mapping for the layer.
- Flow allocation: create shared state between the source and destination IPCP associated with a flow
- Generate a local Endpoint Identifier for a flow
- Map this local Endpoint Identifier to the peer address
- Congestion avoidance: Monitor the network flow for congestion and police throughput as needed.
The network-layer flow allocation exchange maps the application-requested QoS to a network traffic class. The application-level request/response is carried over by the network-level request/response handshake to fit the complete flow allocation process (application-level and network-level) within a single round-trip.
The network end-to-end layer provides the interface for the application end-to-end layer on top, so these two layers always go hand-in-hand.
Network Forwarding layer
The network forwarding layer is responsible for forwarding Ouroboros Data Transfer Protocol packets from the source IPCP to the destination IPCP, based on their addresses and QoS class.
The forwarding function takes the destination address and decides on which flow(s) to forward the packet, usually implemented as a table (forwarding table). In order to do this, distance information needs to be available at each IPCP, which we call the routing dissemination function.
Transmission layer
At the bottom we find the 'Transmission layer', which is the abstraction for a point-to-point communications channel whose operation is completely independent to all other components of O7s. This can be the wire protocol over a physical medium (copper wire, wireless broadcast, machine RAM, ...) or a network technology such as Ethernet, IP, UDP, Bluetooth, ... to allow constructions as O7s-over-UDP, O7s-over-Ethernet.
This transmission layer is coupled to its own specifically tailored network end-to-end layer to interface with the application end-to-end layer above (as these 2 end-to-end layers always go hand-in-hand). This special network end-to-end layer at least needs to implement a minimal flow allocator.
Broadcast model
Broadcast API
The Broadcast API provides the interface for an application to join and leave broadcast flows, and read and write from and to such flows. The API is network-agnostic and provides application primitives for synchronous and asynchronous IPC. It supports message-based and (byte)stream-based communication. QoS for Broadcast flows is (inherently) limited when compared to the options available for Unicast Flows. A Broadcast flow maps directly to the concept of a Broadcast Layer (see below).
Network Flooding layer
The network flooding layer is responsible for flooding packets from the input data transfer flow to all other data transfer flows. This operation is in essence stateless.
The network flooding layer interfaces with an application end-to-end layer to provide the data-transfer flows that make up the links of the Broadcast Layer, which typically form a tree (but a Directed Acyclic Graph is a sufficient condition).
Layers and recursive networking
As an application end-to-end layer pairs with a corresponding network application end-to-layer, and the network flooding and network forwarding layers are part of a network application, it is clear that the Ouroboros Unicast Model gives rise to a 'ham-and-cheese sandwich' structure that can be stacked repeatedly. If the API between the application and network end-to-end layers is a single universal standard, then the Layers (capital L) in this sandwich can be switched around at will. This is what we call a recursive network. The Ouroboros model hints at recursion, but does not require it.
Unicast Layer
The Unicast Layer consists of a three-layer application that contains implementations of a network end-to-end layer and a network forwarding layer (and inherits the application end-to-end layer). This (abstract) application is called a Unicast IPCP.
Broadcast Layer
The Broadcast Layer consists of a two-layer application that contains implementations of a network flooding layer (and inherits the application end-to-end layer). This (abstract) application is called a Broadcast IPCP.
Multicast is not a distinct concept in the O7s model, but rather the combination of 2 processes:
- Enrolling a Broadcast IPCP in a Broadcast Layer that consists of other Broadcast IPCPs in systems that are home to the applications what would colloquially be called a 'multicast group', and
- The application then joining in that Broadcast Layer.
0-Layers
A Unicast 0-Layer is a Layer consisting of two-layer applications that implement a - possibly tailored and limited - network end-to-end layer to interface with applications (using the Unicast API) above. Examples of these are IPCPs to run O7s over UDP, Ethernet, RAM, etc.
A Broadcast 0-Layer is a two-layer application that implements a - possibly tailored and limited - network flooding layer to interface with broadcast applications (using the Broadcast API) above. This is not shown in the model figures, but it is the trivial case of an O7s application over a 'legacy' broadcast technology. Examples are IPCPs implementing flooding over RAM, or wrapping Ethernet or IP Broadcast.
Relation to TCP/IP model
Main Page: Ouroboros and TCP/IP
Relation to Location/Identifier split
Main Page: Ouroboros and Loc/Id Split
Relation to Recursive InterNetwork Architecure (RINA)
Main Page: Ouroboros and RINA
Notes on Layering
The model as explained above shows Broadcast Layers over Unicast Layers, and Unicast over Unicast Layers. What about the other options?
Unicast over Broadcast
From the perspective of the O7s Layers, the general case of Unicast over Broadcast -- by which we mean that some data packets will be flooded to multiple next-hop IPCPs -- brings with it that Unicast IPCPs would have to be able to identify whether arriving data packets are for them or not. This problem inherently has limited scalability and its utility within O7s is as of yet unclear and requires some further study. In absence of compelling reasons to add this, we currently haven't added this to the general model. This does not imply that a Unicast Layer can not use dedicated Broadcast Layers to implement certain functionalities - an example is routing dissemination in the network forwarding layer.
Since Ethernet does implement unicast over a broadcast domain, we have a dedicated page discussing how Ethernet maps to Ouroboros.
Broadcast over Broadcast
The case where one Broadcast Layer makes use of another Broadcast Layer is also technically feasible. Its utility is also still unclear, which is why it's not currently elaborated on in the model, but allowing this will have little impact.
The One Layer
Why not merge broadcast and unicast functionality in a single Layer? This is definitely feasible and anyone is free to implement such an IPCP that does both. The net outcome will be a Layer that has a a broadcast network as well as a unicast network at the full scope of that Layer. This could be useful for some particular use cases, and surely engineers who find them will write many papers about the peculiars of each of these cases and why implementing them in mixed program is more optimal. However, from a model perspective, Unicast and Broadcast are always two distinct Layers, and mixing the implementation does not alter this fact.