Ouroboros - User contributions [en]

Ouroboros Data Transfer Protocol

2022-06-05T09:24:29Z

Dstaesse: /* EID */

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into account memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. This endpoint uniquely identifies an application/service at the destination, so this field is not identical in function to the ''protocol'' or ''next header'' field in IPv4 or IPv6, but rather it more closely resembles the function of the (ephemeral) ''port'' field in UDP or TCP.

There is no reason for an N-layer protocol to know anything about the (N + 1)-Layer protocol it is transporting. Ouroboros does have a notion of ''reserved EID'' for functions that are ''internal'' to an N-layer, such as the [[Flow Allocator | flow allocator]] and the [[directory]].

The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields that are not present in ODTP ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed. None of the existing options in IPv4 or IPv6 are useful.

=== Length ===

Not needed, because there are no optional fields that apply only to some flows.

== Security ==

This protocol is secure as there are no unnecessary mutable fields. For comparison with IPv4 or IPv6, all the fields that are protected by IPSec are simply not present in our protocol.

Ouroboros Data Transfer Protocol

2022-06-05T09:12:53Z

Dstaesse: /* Protocol Header */

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into account memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields that are not present in ODTP ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed. None of the existing options in IPv4 or IPv6 are useful.

=== Length ===

Not needed, because there are no optional fields that apply only to some flows.

== Security ==

This protocol is secure as there are no unnecessary mutable fields. For comparison with IPv4 or IPv6, all the fields that are protected by IPSec are simply not present in our protocol.

Ouroboros Data Transfer Protocol

2022-06-05T09:08:55Z

Dstaesse: /* Notable fields not present in ODTP */

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields that are not present in ODTP ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed. None of the existing options in IPv4 or IPv6 are useful.

=== Length ===

Not needed, because there are no optional fields that apply only to some flows.

== Security ==

This protocol is secure as there are no unnecessary mutable fields. For comparison with IPv4 or IPv6, all the fields that are protected by IPSec are simply not present in our protocol.

Ouroboros Data Transfer Protocol

2022-06-05T09:08:39Z

Dstaesse: /* Notable fields not present */

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields not present in ODTP ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed. None of the existing options in IPv4 or IPv6 are useful.

=== Length ===

Not needed, because there are no optional fields that apply only to some flows.

== Security ==

This protocol is secure as there are no unnecessary mutable fields. For comparison with IPv4 or IPv6, all the fields that are protected by IPSec are simply not present in our protocol.

Ouroboros Data Transfer Protocol

2022-06-05T09:05:53Z

Dstaesse:

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields not present ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed. None of the existing options in IPv4 or IPv6 are useful.

=== Length ===

Not needed, because there are no optional fields that apply only to some flows.

== Security ==

This protocol is secure as there are no unnecessary mutable fields. For comparison with IPv4 or IPv6, all the fields that are protected by IPSec are simply not present in our protocol.

Ouroboros Data Transfer Protocol

2022-06-05T09:05:21Z

Dstaesse: /* Notable fields not present */

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields not present ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed. None of the existing options in IPv4 or IPv6 are useful.

=== Length ===

Not needed, because there are no optional fields that apply only to some flows.

== Security ==

This protocol is secure as there are no unnecessary mutable fields. All the fields that are protected by IPSec are simply not present in our protocol.

Ouroboros Data Transfer Protocol

2022-06-05T09:04:35Z

Dstaesse:

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields not present ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed. None of the existing options in IPv4 or IPv6 are useful.

=== Length ===

Not needed, because there are no optional fields that apply only to some flows.

=== Security ===

This protocol is secure as there are no unnecessary mutable fields.

Ouroboros Data Transfer Protocol

2022-06-05T09:01:59Z

Dstaesse: /* Notable fields not present */

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields not present ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed. None of the existing options in IPv4 or IPv6 are useful.

=== Length ===

Not needed, because there are no optional fields that apply only to some flows.

Ouroboros Data Transfer Protocol

2022-06-05T09:00:50Z

Dstaesse: /* Source address */

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields not present ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation | flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. Intermediate forwarding functions do not need to know the source address. Routing based on a host source address can't possibly scale, routing on prefixes is questionable, and spoofing source prefixes can't be avoided.

=== Options ===

Not needed

=== Length ===

Not needed

Ouroboros Data Transfer Protocol

2022-06-05T08:57:08Z

Dstaesse: /* Version */

The Ouroboros Data Transfer Protocol is the ''hop-by-hop'' protocol that forwards packets to their destination, and is similar to IPv6, with further simplifications.

== Protocol Header ==

The field widths are not that important, but an optimized version would take into memory alignment.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 5 fields in the Ouroboros network protocol are:

=== Destination address ===

This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

=== Time-to-Live ===

Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

=== QoS ===

Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

=== EID ===

The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen by the endpoint at flow allocation.

=== ECN ===

This field specifies Explicit Congestion Notification (ECN), and is, strictly speaking, part of the [[Flow Allocation Protocol]]. with similar intent as the ECN bits in the Type-of-Service field in IPv4 / Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

== Notable fields not present ==

=== Version ===

There is no need for a version of the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is shared between IPCPs on [[enrollment]].

=== Source address ===

Not needed

=== Options ===

Not needed

=== Length ===

Not needed

Ouroboros Data Transfer Protocol

2022-06-05T08:39:25Z

Dstaesse: /* Notable fields not present */

Ouroboros Data Transfer Protocol

2022-06-05T08:34:38Z

Dstaesse:

2022-06-02T06:33:00Z

Dstaesse:

{{Page in progress}}

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]]

[[File:Unicast-broadcast-20220601.png | right | 400px | Ouroboros network layers]]

The model consists of the following elements:

* [[Inter-Process Communication Process]]es (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.

[[File:Ouroboros-model-20220228.png | right | 400px | Ouroboros functional model]]

== 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]]''.

2022-06-01T11:30:04Z

Dstaesse:

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 ==

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or [[RINA]], or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our 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]]

[[File:Unicast-broadcast-20220601.png | right | 400px | Ouroboros network layers]]

The model consists of the following elements:

* [[Inter-Process Communication Process]]es (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.

[[File:Ouroboros-model-20220228.png | right | 400px | Ouroboros functional model]]

== 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]]''.

Ouroboros

2022-06-01T11:06:00Z

Dstaesse:

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 ==

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or [[RINA]], or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our 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]]

[[File:Unicast-broadcast-20220601.png | right | 400px | Ouroboros network layers]]

The model consists of the following elements:

* [[Inter-Process Communication Process]]es (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.

[[File:Ouroboros-model-20220228.png | right | 400px | Ouroboros functional model]]

== 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]]''.

Ouroboros

2022-06-01T10:59:14Z

Dstaesse: /* Model */

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 ==

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or [[RINA]], or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our 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]]

[[File:Unicast-broadcast-20220601.png | right | 400px | Ouroboros network layers]]

The model consists of the following elements:

* [[Inter-Process Communication Process]]es (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 main takeaway from our research into Ouroboros is not that there are recursive and non-recursive networks. Our 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]]

== 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]]''.

Ouroboros

2022-06-01T10:57:08Z

Dstaesse: /* Model */

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 ==

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or [[RINA]], or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our 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]]

[[File:Unicast-broadcast-20220601.png | right | 400px | Ouroboros network layers]]

The model consists of the following elements:

* [[Inter-Process Communication Process]]es (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. The main takeaway from our research into Ouroboros is not that there are recursive and non-recursive networks. Our 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]]

== 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]]''.

File:Unicast-broadcast-20220601.png

2022-06-01T10:54:17Z

Dstaesse:

Ouroboros

2022-06-01T10:52:14Z

Dstaesse: /* Model */

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 ==

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or [[RINA]], or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our 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 Process]]es (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. The main takeaway from our research into Ouroboros is not that there are recursive and non-recursive networks. Our 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 network model]]

== 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]]''.

Ouroboros

2022-06-01T10:49:32Z

Dstaesse: /* Model */

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 ==

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or [[RINA]], or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our 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]]

[[File:Ouroboros-model-20220228.png | right | 400px | Ouroboros network model]]

The model consists of the following elements:

* [[Inter-Process Communication Process]]es (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, not necessarily unique programs. In other words, this model can be mapped to, or used to analyze, any packet-switched network technology. The main takeaway from our research into Ouroboros is not that there are recursive and non-recursive networks. Our 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.

== 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]]''.

Ouroboros

2022-06-01T10:42:46Z

Dstaesse: /* Model */

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 ==

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or [[RINA]], or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our 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]]

[[File:Ouroboros-model-20220228.png | right | 400px | Ouroboros network model]]

The model consists of the following elements:

* [[Inter-Process Communication Process]]es (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, not necessarily unique programs. In other words, this model can be mapped to, or used to analyze, any packet-switched network technology. The main takeaway from our research into Ouroboros is not that there are recursive and non-recursive networks. Our 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.

== 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]]''.

Ouroboros

2022-06-01T10:38:35Z

Dstaesse: /* Model */

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 ==

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or [[RINA]], or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our 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]]

[[File:Ouroboros-model-20220228.png | right | 400px | Ouroboros network model]]

The model consists of the following elements:

* [[Inter-Process Communication Process]]es (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, not necessarily unique programs. In other words, this model can be mapped to, or used to analyze, any packet-switched network technology. The main takeaway from our research is not that there is such a thing as recursive vs non-recursive networks. All packet-switched networks are inherently recursive.

== 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]]''.