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

Ouroboros' main objectives are not in finding solutions to any practical or academic engineering problems that may exist in network architecures such as TCP/IP, OSI or RINA. Nor is it developed to add perceived missing functionality in existing network technologies.

Its 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. For instance, in IP over Ethernet, VLANs are typically used as a broadcast domain defining an IP subnet. In OSPF, an IP multicast network is used to define an OSPF area.

The key proposition of the Ouroboros model is not that there are recursive and non-recursive networks. Its 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.

Terminology

Ouroboros uses the word layer to describe both the recurring layering that make up the network, built of IPCPs (unicast layer, broadcast layer), as the functional layering within the applications and IPCPs (end-to-end application layer, application session layer). We have considered using the terms 'unicast network' and 'broadcast network', but then the network is composed of networks, which is not ideal either. However, and Ethernet or Wifi Network is also commonly referred to as a "Layer 2"...

The term IPCP is derived from RINA terminology (and RINA borrowed it from LINCS). While it is an accurate description in RINA, as it is a process that provides access to an "Inter-Process Communicaton service", in Ouroboros it is not that accurate. Terms like "forwarding process" or "routing process" also carry connotations.

These terminology issues are definitely confusing and suggestions to fix this terminology are welcomed.

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.