Supporting applications. The vast majority of distributed applications today use the Sockets API to request communication services, either directly or via some higher-level software framework that internally uses Sockets. The Sockets API does not abstract the communication service provided from its implementation very well: network addresses are exposed and the application developer has to explicitly choose the transport protocol that will provide the communication service. This fact makes the introduction of new transport technologies very challenging, since it is not transparent for the application developer. Hence, two strategies are possible to enable legacy application support: i) modifying the application code that interacts with the network so that it talks to the IPC service API (or even to another network API that is truly technology agnostic) or ii) writing a Sockets emulator that maps the calls to the Sockets API to calls to the IPC service API.
ARCFIRE’s deliverable D3.1 describes a design and implementation of an IPC service API for RINA that is very close to the file API defined in the POSIX standard. Flows are modelled as file descriptors that can be allocated, read, written and closed by applications. ARCFIRE researchers have ported two applications from sockets to this POSIX-like IPC service API: the Ngnix web server and the Dropbear SSH server. The porting of each application involved rewriting about 300-400 lines of code, which is a relatively small effort.
Porting applications to the IPC service API has the advantage that such applications can leverage the features of a generic IPC network architecture (application naming, protocol independence, capability to request QoS options for the communication service). However, the cost of modifying an application to deploy it over a RINA network may be too high in many cases. A sockets emulator is the best option for those scenarios. This piece of software replaces the implementations of the Sockets operations in the standard C library by calls to an IPC service API (such as the RINA POSIX-like API). An initial implementation of a Sockets emulator has been started here.
Overlays: shim DIFs. DIFs can be deployed over existing layers of protocols as an overlay. The adaptation of an existing protocol to a DIF is carried out via a shim DIF. The task of a shim DIF is to put as small as possible a veneer over a legacy protocol to allow a DIF to use it unchanged. The shim DIF wraps the underlying protocol layer with the IPC service interface. The goal is not to make legacy protocols provide full support for the DIF and so the shim DIF should provide no more service or capability than the legacy protocol provides.
The IRATI project defined shim DIFs to overlay RINA on top of Ethernet (with and without VLANs), TCP and UDP, and shared memory for VM-Hypervisor communication. ARCFIRE has also specified and implemented a shim DIF to overlay RINA on top of WiFi. The shim DIF abstraction has proven an effective tool to overlay RINA on top of existing network technologies.
DIFs as a multi-protocol transport. DIFs can also be used as an underlay technology that can efficiently transport IP, Ethernet or flows belonging to other protocols with the adequate level of service. Using this approach DIFs can be used as an alternative or a replacement to MPLS in a variety of scenarios such as datacentre network fabrics, BGP-free service provider backbones, Metropolitan Area Networks delivering Carrier Ethernet services, etc. DIFs can provide services such as point-to-point flows, IP VPNs, Ethernet VPLS instances, etc. ARCFIRE researchers have developed an “IP over RINA” daemon that allows the establishent of IP VPNs using RINA as an underlying transport.
Transport layer gateways. The PRISTINE and ARCFIRE projects have worked in the TCP-RINA gateway, a daemon that acts as a proxy/gateway between a TCP/IP network and a RINA network. On the one side, the gateway accepts TCP connections coming from a TCP/IP network and proxies them by allocating RINA flows towards the proper server applications in the RINA network. On the other side, the gateway accepts flow allocation requests coming from the RINA network and proxies them to a TCP server by means of new TCP connections. The gateway can be easily extended to support the relaying of other transport protocols such as UDP.