Ouroboros

 This page is under construction  

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

The key objective of Ouroboros is to improve upon the architectural design of the Internet, as opposed to finding point solutions to any practical (or academic) engineering problems that exist in today's networks.

The methodology employs a physics-inspired reductionist approach towards figuring out the fundamental building blocks (which are functions defined by algorithms, not devices) and rules that govern packet networks as a whole. Rules that, when broken, cause the network to cease operation or impair scalability.

The aim is to come to a model which explains the fundamentals for network functions as elegantly as possible (this list is not exhaustive):

• 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
  • Byzantine fault tolerance (rogue elements)
• 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 a network implementation directly based on the model to validate these ideas.

Model

Main Article: Ouroboros model

The model consists of 2 functional elements:

The forwarding element and flooding element that form a unicast or broadcast layer respectively.

These functional elements are implemented as components of a small program, called Inter-Process Communication Processes (IPCPs). Besides these 2 functional elements, they house a number of management related functions.

There are 3 kinds of IPCPs:

• Unicast IPCPs, with at their core forwarding elements
• Broadcast IPCP, with at their core flooding elements
• Adaptation IPCPs, which reuse existing technology that maps to a forwarding element. Currently our adaptation IPCPs map
  • udp, wrapping the IP protocol as the forwarding element
  • eth, wrapping Ethernet as the forwarding element. We have 2 versions, one based on Ethernet II (DIX), and one based on IEEE 802.2 LLC.
  • local, which just passes packets over shared memory, similar to a loopback interface. It is mostly for testing purposes.

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.

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.

Key differences

Compared to OSI

• Not sure I want to do this...

Compared to RINA

Main Article: Ouroboros compared to RINA

RIB/CDAP is abstracted as a broadcast layer.

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

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 LoC/Id split

Main Article: Differences between Ouroboros and LoC/Id split