|
|
| Line 2: |
Line 2: |
|
| |
|
| '''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. | | '''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 build a packet network technology that reduces the complexity and tediousness of network configuration and (micro-)service deployment and maintenance.
| |
|
| |
| Meeting this objective requires significant improvements over the '''architectural design''' of the Internet, as opposed to engineering point solutions to any practical (or academic) problems that exist in today's Internet stack.
| |
|
| |
| 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]]
| |
|
| |
| [[File:ouroboros-scalingtime.png | right | 400px | Ouroboros network layers]]
| |
|
| |
| The model consists of 2 functional elements:
| |
|
| |
| The [[forwarding element]] and [[flooding element]] that form a [[Unicast Layer | unicast]] or [[Broadcast Layer | broadcast layer]] respectively.
| |
|
| |
| These functional elements are implemented as components of a small program, called [[Inter-Process Communication Process]]es (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.
| |
|
| |
| [[File:Ouroboros-model-20220228.png | right | 400px | Ouroboros functional model]]
| |
|
| |
|
| |
| 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 ==
| |
|
| |
| There are three conjectures that are unique to the Ouroboros networking model:
| |
|
| |
| 1) packet networks are composed of only two fundamental objects that each harness a well defined algorithm, called FORWARDING and FLOODING, organised in distributed application (layers) called unicast and broadcast.
| |
|
| |
| 2) The boundary of application and networking in current networking models is wrong: most of the functionality of TCP (except for congestion control) is an application, not networking.
| |
|
| |
| 3)
| |
|
| |
|
| |
| === 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]]''.
| |
|
| |
| === Compared to TCP/IP ===
| |
| ''Main Article'': [[Ouroboros compared to TCP/IP]]
| |
|
| |
| * Decoupled flow control and congestion avoidance
| |
|
| |
| * Only explicit congestion avoidance
| |
|
| |
| === Compared to LoC/Id split ===
| |
| ''Main Article'': [[Ouroboros compared to LoC/Id split]]
| |
This page is under construction