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 adopts 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, so that is where the credit belongs. There is a section at the bottom of this page that highlights the relation between the O7s functional model and RINA.

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.

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:

1. 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.
2. Flow allocation: create shared state between the source and destination IPCP associated with a flow
   1. Generate a local Endpoint Identifier for a flow
   2. Map this local Endpoint Identifier to the peer address
3. 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

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 gathered 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 communication channel whose operation is not (and does not need to be) visible to O7s. This can be a physical medium (copper wire, wireless broadcast, machine RAM, ...) or a legacy technology such as Ethernet, IP, UDP, Bluetooth, ... 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.

Broadcast model

Relation to TCP/IP model

Ouroboros network model vs TCP/IP model

Relation to Location/Identifier split

Ouroboros network model vs Loc/Id split

Relation to Recursive Internet Architecure (RINA)

Ouroboros network model vs RINA model