Ouroboros Model

From Ouroboros
Jump to navigation Jump to search

Under contruction This page is under construction  

This pages provides an overview of the Ouroboros model, which summarizes our proposed organization of packet networking functionality.

Elements of the model

The Ouroboros packet network model for unicast works as follows: To be able to communicate processes request flows to one another: server processes bind' to (service) names, the client process requests a flow to such a name. Flows are between flow endpoints, and the source and destination application read from and write to these endpoints.

The model for multicast works differently.

Processes

Processes are running software. No need for fancy buzzwords. A microservice component, a (monolithic) OS kernel, an open spreadsheet, a running background script, ... they are all nothing but processes.

Names

Names in Ouroboros are tied to processes. Multiple processes can bind to the same name, and multiple names can be bound to the same process.

Flows

Flows exist between two flow endpoints. They are very broadly defined and generalize a best-effort packet stream.

  • Data is sent as a packet at the source flow endpoint and arrives as a packet at the destination flow endpoint.
  • Flows are established over a Layer, which may consist of any number of forwarding processes called IPCPs.
  • Packets transmitted by the source have a non-zero probability to arrive at least once at the destination.
  • Packets can follow any path in the Layer
  • There is no correlation to be assumed between the path taken by different packets along the same flow
  • Packets may arrive out of order
  • Packets can be duplicated
  • Flows can be authenticated and/or encrypted.
    • The flow is authenticated before the flow endpoints are handed over to the server/client processes.
    • If encrypted, the encryption key(s) are passed to the process along with the flow endpoint.

Layers

To improve effiency of flows, Layers may try to

Connections

IRMd

IPCPs

Functional layering

Main page: Ouroboros Functional Layering

Ouroboros network model - functional layering

The model's functional layering underpinning Ouroboros has some distinct properties.

  1. A clear distinction between unicast and broadcast (see the multicast conjecture).
    1. Unicast
      1. The application end-to-end layer performs functionalities that require knowledge at the endpoint applications, but are not of concern to the network. These are automated repeat-request (ARQ), fragmentation and flow control. In addition, this layer also performs encryption, authentication and packet integrity (CRC). The data protocol associated with this layer is called the Flow and Retransmission control protocol (FRCP). It is considered an application protocol rather than a network protocol.
      2. The network end-to-end layer performs flow allocation/multiplexing, name-to-address resolution, and congestion avoidance.
      3. The network forwarding layer performs routing and hop-by-hop forwarding functions.
      4. The Unicast Layer is a distributed application that implements the network end-to-end layer and network forwarding layer functionalities. Since the elements of a Unicast Layer are also applications, they inherit the application end-to-end layer on a hop-by-hop basis.
    2. Broadcast
      1. The network flooding layer is completely stateless.
      2. The Broadcast Layer is a distributed application that implements the network flooding layer. Since the elements of a Broadcast Layer are also applications, they inherit the application end-to-end layer on a hop-by-hop basis.
  2. At the bottom of this network model, is the transmission layer. It is always accompanied by a (devolved) network end-to-end layer.

Network Layering and Recursion

Main Page: Network Layering