Ouroboros Data Transfer Protocol

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, 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.