Ouroboros Functional Layering
This page is under construction
The Ouroboros model is the result of countless architectural refinements made while implementing the Ouroboros prototype. As this prototype started off as an implementation of principles outlined by the RINA architecture, the Ouroboros model has a lot of concepts and terminology in common with RINA. While this page uses the nomenclature as its own, it should be kept in mind that some of the overall concepts are not unique to O7s, but originated in RINA and should therefore be credited as such. There is a section at the bottom of this page that highlights the relation between the O7s model and the RINA model.
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)
- Integrity (hash-based checks such as CRC32)
- Reliability, implemented by the FRCP protocol
- Fragmentation
- In order delivery
- Discarding duplicate packets
- Automated-Repeat Request (retransmission of lost packets)
- Flow control
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.
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.
Network Forwarding layer
Transmission layer
Broadcast model
