Ouroboros Data Transfer Protocol
The Ouroboros Data Transfer Protocol (ODTP) is the hop-by-hop protocol that forwards packets to their destination, and is similar to the Internet Protocol, but with further simplifications.
ODTP is internal to the Data Transfer Component in the unicast IPCP. The details of this protocol do not need to be known outside these modules, not to the other components of a unicast IPCP, not to the IRMd, and definitely not to the upper layer application.
Protocol Header
The field widths are not that important, but an optimized version should take into account memory alignment. The Data Transfer Protocol has 3 fields associated with the Data Transfer Component (the network forwarding layer in the model), and 2 fields associated with the flow allocator (the end-to-end network layer in the model).
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .Fields associated with the network forwarding layer
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.
Fields associated with the network end-to-end layer
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 akin to the function of the (ephemeral) port field in UDP or TCP. Note that
- There is no reason for an N-layer protocol to know anything about the (N + 1)-Layer protocol it is transporting (nor the other way around).
- There are no well-known Endpoint IDs; every application flow has random EIDs and there is no relation between an EID and an application type.
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 locally by each endpoint IPCP during flow allocation.
While Ouroboros does not have well-known EIDs, it does have a notion of reserved EIDs for functions that are internal to an N-layer, such as the flow allocator and the directory. These EIDs should not be fixed, unique for the layer and can be communicated during Enrollment.
ECN
This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or 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 field in the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is agreed between IPCPs during 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. This is motivated by the following observations:
- Intermediate forwarding functions do not need to know the source address to forward a packet to the destination
- The rate of change of the source address (if at all) is generally much lower than the packet rate
- Since this field is not needed for forwarding, the source address is rife for abuse
The edge case where an application needs to send a single packet to a destination, or very infrequently, can be covered by piggybacking data on the first flow allocation message.
Protocol/Next Header
The protocol (IPv4) / Next Header (IPv6) field identifies the protocol on top of the Internet Protocol, which is a clear layer independence violation. ODTP has an Endpoint Identifier field that combines the Protocol and Port functions, and is (nearly) always 'ephemeral'.
Length
Not needed, because the syntax of the ODTP network forwarding layer protocol is agreed during enrollment.
Implementation
The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.