Every computer science class that deals with networks explains the
7-layer OSI model.
Open Systems Interconnect (OSI) defines 7 layers, each providing an
abstraction for a certain function that a network application may
From top to bottom, the layers provide (roughly) the following
The application layer implements the details of the application
protocol (such as HTTP), which specifies the operations and data that
the application understands (requesting a web page).
The presentation layer provides independence of data representation,
and may also perform encryption.
The session layer sets up and manages sessions (think of a session
as a conversation or dialogue) between the applications.
The transport layer handles individual chunks of data (think of them
as words in the conversation), and can ensure that there is end-to-end
reliability (no words or phrases get lost).
The network layer forwards the packets across the network, it
provides such things as addressing and congestion control.
The datalink layer encodes data into bits and moves them between
hosts. It handles errors in the physical layer. It has two sub-layers:
Media access control layer (MAC), which says when hosts can transmit
on the medium, and logical link control (LLC) that deals with error
handling and control of transmission rates.
Finally, the physical layer is responsible for translating the
bits into a signal (e.g. laser pulses in a fibre) that is carried
This functional layering provides a logical order for the steps that
data passes through between applications. Indeed, every existing
(packet) network goes through these steps in roughly this order
(however, some may be skipped). There can be some small variations on
where the functions are implemented. For instance, TCP does congestion
control, but is a Layer 4 protocol.
However, when looking at current networking solutions, things are not
as simple as these 7 layers seem to indicate. Just consider this
realistic scenario for a software developer working remotely. Usually
it goes something like this: You connect to the company Virtual
Private Network (VPN), setup an SSH tunnel over the development
server to your virtual machine and then SSH into that virtual machine.
The use of VPNs and various tunneling technologies draw a picture
where the functions of Layers 2, 3, and 4, and often layers 5 and
6 (encryption) are repeated a number of times in the actual
functional path that data follows through the network stack.
Enter recursive networks.
The recursive network paradigm
The functional repetition in the network stack is discussed in
detail in the book “Patterns in Network Architecture: A Return to
Fundamentals”. From the observations in the book, a new architecture
was proposed, called the “Recursive InterNetwork
Architecture”, or RINA.
Ouroboros follows the recursive principles of RINA, but deviates
quit a bit from its internal design. There are resources on the
Internet explaining RINA, but here we will focus
on its high level design and what is relevant for Ouroboros.
Let’s look at a simple scenario of an employee contacting an internet
corporate server over a Layer 3 VPN from home. Let’s assume for
simplicity that the corporate LAN is not behind a NAT firewall. All
three networks perform (among some other things):
Addressing: The VPN hosts receive an IP address in the VPN, let’s
say some 10.11.12.0/24 address. The host will also have a public IP
address, for instance in the 188.8.131.52/16 range . Finally that host
will have an Ethernet MAC address. Now the addresses differ in
syntax and semantics, but for the purpose of moving data packets,
they have the same function: identifying a node in a network.
Forwarding: Forwarding is the process of moving packets to a
destination with intent: each forwarding action moves the data
packet closer to its destination node with respect to some
metric (distance function).
Network discovery: Ethernet switches learn where the endpoints are
through MAC learning, remembering the incoming interface when it sees
a new SRC address; IP routers learn the network by exchanging
informational packets about adjacency in a process called routing;
and a VPN proxy server relays packets as the central hub of a network
connected as a star between the VPN clients and the local area
network (LAN) that is provides access to.
Congestion management: When there is a prolonged period where a
node receives more traffic than can forward forward, for instance
because there are incoming links with higher speeds than some outgoing
link, or there is a lot of traffic between different endpoints towards
the same destination, the endpoints experience congestion. Each
network could handle this situation (but not all do: TCP does
congestion control for IP networks, but Ethernet just drops traffic
and lets the IP network deal with it. Congestion management for
Ethernet never really took off).
Name resolution: In order not having to remember addresses of the
hosts (which are in a format that make it easier for a machine to deal
with), each network keeps a mapping of a name to an address. For IP
networks (which includes the VPN in our example), this is done by the
Domain Name System (DNS) service (or, alternatively, other services
such as open root or namecoin). For Ethernet, the Address
Resolution Protocol maps a higher layer name to a MAC (hardware)
Recursive networks take all these functions to be part of a network
layer, and layers are mostly defined by their scope. The lowest
layers span a link or the reach of some wireless technology. Higher
layers span a LAN or the network of a corporation e.g. a subnetwork or
an Autonomous System (AS). An even higher layer would be a global
network, followed by a Virtual Private Network and on top a tunnel
that supports the application. Each layer being the same in terms of
functionality, but different in its choice of algorithm or
implementation. Sometimes the function is just not implemented
(there’s no need for routing in a tunnel!), but logically it could be