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. The model has 5 layers: the application layer, the application end-to-end layer, the network end-to-end layer, the network forwarding layer and the transmission layer.
The layered model treats broadcast/multicast as distinct from unicast. Broadcast is implemented by a network flooding layer.
All of these layers are black boxes to eachother. The application layer requests network services using the Unicast API and/or Broadcast API. For unicast, the application end-to-end layer interfaces with the network-end-to end layer via the Network IPC API, which is invisible to the application itself. The network IPC API forms the demarcation line between 'the application' and 'the network'. The Broadcast API interfaces directly with the network flooding layer. Furthermore, a network (both of the unicast and broadcast variant) is seen as a distributed application, so it also inherits the application end-to-end layer, giving rise to a repeating network structure.
This page provides an overview of this model as it currently stands, and some insights in how it compares to other models such as the TCP/IP Internet, 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 (ARQ)
- Flow control
- Integrity (hash-based checks such as CRC32)
All the above functionality is optional, and if reliability (FRCP) is disabled, we call the service a raw flow.
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 uses the network IPC API to 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 network end-to-end layer at least needs to implement a minimal flow allocator if the tranmssion layer is a dumb link, but when the transmission layer wraps a legacy network technology, it may be beneficial to have all features of a network-end-to-end layer.
Broadcast model
The broadcast model has two main additions to the unicast model, the Broadcast API and the network flooding layer.
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 network IPC API between the application and network end-to-end layers is a single universal standard, then all the Layers (capital L) in this sandwich can be moved around at will. This is what we call a recursive network. The Ouroboros model hints very strongly 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. The Unicast IPCPs are equals as defined by mechanism (which functionality to implement, etc), but not identical as each mechanism can be implemented by different policies. As an example, the routing functionality can be link-state in one Layer, but path-vector in another Layer. Within the same Layer, they are also not identical, but some network-wide policies will need to be the same in all IPCPs in a Layer.
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 set of applications that would be designated as a 'multicast group', and
- The application then using 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
This section provides a high level architectural overview of the prime differences between the Ouroboros model and the 5-Layer Internet model associated with the TCP/IP protocol stack.
Some differences are directly apparent:
- The Transport Layer is replaced with two end-to-end layers, split between the network and the application,
- The Network Layer has two counterparts: the the network forwarding layer and network flooding layer,
- The Data Link Layer is missing altogether,
- The Physical Layer is now called the transmission layer.
Splitting the Transport Layer
The biggest difference is of course that functionality that is associated with the Transport Layer (the TCP/UDP protocols) is moved into two independent layers. The application end-to-end layer takes over ARQ and flow control, while the network end-to-end layer is in charge of congestion control and handling connection endpoints ('ports'). In TCP/IP these all these functions are unnecessarily entangled around the congestion window implementation.
Untangling the Network Layer
The network layer functionality is very similar between O7s and the Internet model. The main difference is that broadcast is split off in the O7s model, and that the network forwarding layer is does not hold references to the higher-level layers (so, no 'Protocol' field).
No Data Link Layer
When looking at the functionality that is usually associated with the Data Link Layer (multiplexing, mapping higher-level names to addresses) are already present in the network end-to-end layer. So, the Data Link Layer is actually a network end-to-end layer tailored to a physical medium.
Transmission Layer instead of Physical Layer
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.
Mixed and/or combined implementation
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, which may be useful for some particular use cases. However, from a model perspective, Unicast and Broadcast are always two distinct Layers, and mixing the implementation does not alter this fact.
Similarly, a program can be written that implements multiple IPCP modules internally, instead of starting up a process per 'IPCP'.