Ouroboros

Ouroboros (abbreviated as O7s) is a work-in-progress packet-switched Internetwork model and prototype started by Dimitri Staessens and Sander Vrijders at IMEC / Ghent University early 2016.

Objectives

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or RINA, or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our main driver is to figure out the fundamental laws that govern packet networks as a whole. Laws that, when broken, cause the network to cease operation or become unscalable.

The aim is to come to a model that explains the fundamentals for the following network functions as elegantly as possible:

• best effort delivery of packets
• in-order delivery
• reliable delivery
  • re-transmission of lost packets
  • detection of unwanted packets
  • transmission of packets over diverse paths, possibly sending multiple copies, potentially using some erasure-coding scheme
  • transmission of packets over diverse networks, possible sending multiple copies, potentially using some erasure-coding scheme
• filtering out received duplicates
• multiple traffic classes with different scheduling priorities
• security
  • encryption
  • authentication
• flow control: sender does not send more traffic than a receiver can cope with
• congestion avoidance: total offered load to the network does not cause systematic delays (or loss) in packet delivery beyond the expected latency due to packet processing in nodes and propagation delays over the links.
• fragmentation of an application message into smaller network packets, and reassembly
• naming a service
• locating a process that provides access to the named service
• establishing an association between the process that consumes the service and the process that provides access to the service

The prototype is an implementation to validate these ideas.

Model

Main Article: Ouroboros model

The model consists of the following elements:

• Inter-Process Communication Processes (IPCPs)
  • Unicast IPCP, making up a unicast layer
  • Broadcast IPCP, making up a broadcast layer
  • Adaptation IPCPs, abstracting point-to-point and broadcast transmission media.

The unicast and broadcast IPCPs and unicast and broadcast layers are functional abstractions. In other words, this model can be mapped to, or used to analyze, any packet-switched network technology. The main takeaway from our research into Ouroboros is not that there are recursive and non-recursive networks. Our conjecture is that all packet-switched networks are functionally recursive. Just not all of them wrap the functionality of each network layer in the same set of API primitives, some combine functions, or omit functions, or agree on certain values for certain aspects.

Prototype

Main Article: Ouroboros prototype

• IRMd
• IPCPs
  • Unicast IPCP, making up a unicast layer
  • Broadcast IPCP, making up a broadcast layer
  • Adaptation IPCPs
    • Local
    • UDP
    • Ethernet
      • DIX
      • LLC
• Ouroboros library

History

Main Article: History of Ouroboros

The Ouroboros project has its roots in European-funded projects on RINA. After being involved in the RINA prototyping efforts as part of IRATI and PRISTINE, a decision was made by some OpenIRATI contributors to start their own RINA prototypes, one was rlite, the other Ouroboros. While it started as a RINA prototype, after finding numerous inefficiencies in RINA, Ouroboros diverged significantly from its base specifications, enough to warrant calling the model on which Ouroboros is based a different architecture alltogether.

Differences compared to TCP/IP

Main Article: Differences between Ouroboros and TCP/IP

• Decoupled flow control and congestion avoidance

• Only explicit congestion avoidance

Differences compared to OSI

Main Article: Differences between Ouroboros and OSI

• Not sure I want to do this...

Differences compared to RINA

Main Article: Differences between Ouroboros and RINA

RIB/CDAP is abstracted as a broadcast layer.

No "shim layers", all IPCPs implement a Flow Allocator.