Lately there’s been a lot of talk about the Internet limitations, redesigning the Internet, clean slate approaches vs. evolutionary ones, and a lot of money in research funding is being allocated to the topic.
The current Internet architecture is based on a layered approach, where each layer provides a different function to the layers above. Figure 1 depicts the layers of the current Internet: physical (multiplexing and transmission over a physical media), link (error and flow control over physical links), network (relaying and multiplexing over different networks) , transport (host to host error and flow control) and application (whatever the application needs).
Some of the major problems of the current Internet architecture are:
- No built-in support for multihoming and mobility. The network has no way of telling that two IP addresses belong to the same host or router, because the IP address names the interface instead of naming the node.
- Routing does not scale well. The fact that the IP protocol names the interface and not the node implies that routing is done at the interface level (instead of the node level), which causes routing tables to be much bigger than they should. Routing is logically a two-step process: first a sequence of nodes to destination is computed and, at each hop, an appropriate path to the next node (i.e. point of attachment) is selected. However, in the current Internet routing directly computes a sequence of point of attachments.
- Network addresses are exposed to applications. The Internet doesn’t have a directory that provides a mapping of application names to node addresses, which forces the applications to do this job: they have to be aware of what node (even worse, what interface of what node) applications are in. There’s no need to say that this feature makes application mobility hard to deal with.
- Not a clean structure. The Internet architecture is based on different layers (black boxes) stacked one on top of the other, each one providing a different function to the layer above. Repeated functions done at different layers and the so-called layer violations (protocols in one layer that user information of another layer) provide some evidence that the current definition of layer does not hold.
- Complexity. Proliferation of different protocols that tend to provide similar functionality with slightly different features, or even the same functionality with a different configuration. This causes networks to be hard (and expensive) to manage.
- No built-in security. The architecture does not provide means to authenticate hosts and routers before entering a network, therefore a myriad of protocols and middleboxes (such as firewalls) have proliferated in order to provide some level of security to the network, at the price of increasing its complexity.
- No support for end to end QoS.
- Congestion control only done at the edges. The end hosts attached to the network are the responsible for providing congestion control (TCP), with no feedback from the network other than “packets are being dropped” or “big delays are being experimented” (which means the network is already congested). Apart from having the congestion controller as far as possible from where congestion occurs, relying solely on the end hosts to behave well to allow the network to operate without congestion is, at least, a risky strategy.
Fixing all these limitations with evolutionary changes would be inefficient if not impossible, therefore we should go back to the fundamentals to develop an architecture that provides a better network structure.
This is where RINA – the Recursive Internetwork Architecture – comes from. John Day developed the Inter Process Communication (IPC) model for networking in his book “Patterns in Network Architecture“. This model departs from the basic premise that “networking is IPC and only IPC”, and yields a recursive architecture that sees networking as a set of layers that provide IPC services to each other, each layer managing a range of bandwidth and quality of service.
The picture above illustrates the RINA architecture. Each layer -called Distributed IPC Facility DIF, each one in a different color in the picture- provides IPC services over a limited scope. First level DIFs operate on top of a physical medium (wireless in the example), and its policies are optimized to deal with the particularities of the physical medium. First level DIFs provide IPC services to second level DIFs, and so on. The protocols at each layer are the same, they just use a different configuration (i.e. policies) to fulfill the particular requirements of the layer.
The picture also shows that in the RINA architecture there are only three types of systems (boxes): hosts, border routers and internal routers. There is no need for middleboxes such as firewalls, NATs and others.
The RINA architecture provides the following features:
- Clean recursive architecture. Each layer is a distributed application, composed of a set of collaborating application processes that provide IPC services to the layer above. Therefore each layer has the same functions, it just operates in a different scope. Layers are called DIFs (Distributed IPC Facility) and can be seen as private networks.
- Complete naming and addressing. Applications request flows to other applications (“I’m application A and I want to connect to application B”), without having to know where the application is. Addresses are internal to the DIF, they are just synonyms of the names of the application processes that conform the DIF, optimized for routing.
- Multi-homing, mobility and multicast supported by the architecture, without the need for any special protocols.
- Better security. Applications need to authenticate with one another before being able to exchange information. Applications cannot communicate with the elements inside a DIF unless they are part of that DIF (which requires authentication).
- Support for QoS. Each DIF can define a set of “QoS” cubes and provide different qualities of service to its clients.
- A single data transfer protocol, configurable to operate in different scenarios. By separating the function (mechanism) from the configuration of the function (policy), all the current data transfer protocols can be recreated. This means that only one transport protocol is required, decreasing the complexity of the network in orders of magnitude.
- CDAP- Common Distributed Application Protocol. RINA provides the assembly language of distributed applications, a single application protocol that can be used to develop all the distributed applications. It is not a requirement to use it (any application protocol can be transported by RINA), but using it simplifies the development of distributed applications (RINA uses it internally).
- Congestion control. Each DIF can perform congestion control with feedback from all the application processes (i.e. network nodes) in the DIF. The recursive architecture allows the congestion control loop to have a shorter delay, resulting in an earlier detection and better isolation of the congested resources.
A group called the Pouzin Society has been created to foster the development and adoption of RINA, as well as to provide common standards for the parts of the architecture that need to be standardised.