Ouroboros Model: Difference between revisions
m (Dimitri moved page Ouroboros model to Ouroboros Model) |
(→Names) |
||
(18 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{Under construction}} | {{Under construction}} | ||
This pages provides an overview of the Ouroboros model, which summarizes our proposed organization of the | 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 == | |||
Ouroboros ''service names'' are the equivalent of Domain Names in DNS. Ouroboros ties service names to processes (not hosts). Multiple processes can bind to the same name, and multiple names can be bound to the same process. | |||
To communicate, a process requests a flow with as destination a certain service name. Like Domain Names in DNS, service names can be authenticated using public key cryptography (certificates). Service name certificates (if present) are stored in the directory of each layer and returned, together with a destination address as part of name queries. | |||
== 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 = | = Functional layering = | ||
Main page: [[Ouroboros Functional Layering]] | Main page: [[Ouroboros Functional Layering]] | ||
[[File: O7s Model_01.png|border|right|thumb|frame|Ouroboros network model - functional layering]] | |||
The model's functional layering underpinning Ouroboros has some distinct properties. | The model's functional layering underpinning Ouroboros has some distinct properties. |
Latest revision as of 06:20, 28 July 2024
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
Ouroboros service names are the equivalent of Domain Names in DNS. Ouroboros ties service names to processes (not hosts). Multiple processes can bind to the same name, and multiple names can be bound to the same process.
To communicate, a process requests a flow with as destination a certain service name. Like Domain Names in DNS, service names can be authenticated using public key cryptography (certificates). Service name certificates (if present) are stored in the directory of each layer and returned, together with a destination address as part of name queries.
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
The model's functional layering underpinning Ouroboros has some distinct properties.
- A clear distinction between unicast and broadcast (see the multicast conjecture).
- Unicast
- 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.
- The network end-to-end layer performs flow allocation/multiplexing, name-to-address resolution, and congestion avoidance.
- The network forwarding layer performs routing and hop-by-hop forwarding functions.
- 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.
- Broadcast
- The network flooding layer is completely stateless.
- 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.
- Unicast
- 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