The shim DIF, or how to overlay RINA on top of everything

One of the main concerns for deploying any new technological innovation is how easily it can coexist with the existing technology base. In networking, the painful migration process of IPv4 to IPv6 is a great example of this issue. In earlier posts and papers, we’ve argued that RINA doesn’t suffer from this problems: with a well-formed architecture and a proper understanding of layers there’s no need for migration,  just adoption. As shown in figure 1, RINA can be used above IP (and other network technologies), or below IP.

Figure 1. Different strategies for the deployment of RINA

In this post we’ll show how RINA can be overlayed on top of existing network technologies, focusing on IP overlays as an example.

The answer of this problem is rather simple: the shim DIF abstraction.  A shim DIF is not a real DIF; it just presents a given physical media or network technology as if it was a regular DIF. The purpose of the shim DIF is not to make a given technology to look like RINA, but to allow an application built to the RINA API (like an IPC Process in a “normal” DIF) to operate over the technology/physical media the shim DIF is wrapping without requiring changes. Figure 2 illustrates the concept. The IPC Processes of the green DIF are completely unaware if they are over an IP layer or an Ethernet layer: the only difference that they will notice is that the QoS capabilities of the underlying DIFs may be different.

Figure 2. Example illustrating the shim DIF concept, overlaying RINA on top of IP and Ethernet layers.

There are currently specifications and implementations for shim DIFs over IP layers, which i) wrap the IP layer with the IPC Process Interface; ii) map the names of IPC Processes of the layer above to IP addresses in the IP layer and iii) create TCP and/or UDP flows based on the QoS requested by the upper layer application process. In the near future, starting on January 2013 the FP7-funded project IRATI will define and implement equivalent functionality to present Ethernet layers as shim DIFs. Looking at a longer term, the same mechanism can be applied to overlay DIFs on top of any physical media.

The shim DIF abstraction allows the core components of a DIF to be developed as overlays of IP, and then to push these components down the current layer stack down to the physical media. During this trip through the current layers the core components of a DIF will remain the same, the only that will change is that new policies will be developed to adapt each DIF to its operational environment (which can be dominated by the requirements of supported applications, or by the characteristics of the supporting physical media).

This entry was posted in Uncategorized and tagged . Bookmark the permalink.