Application discovery in RINA networks

While in the current Internet architecture two applications that are able to discover each other are always assumed to be accessible through the same layer, this is not the case in the Recursive InterNetwork Architecture (RINA) networks. Although for two applications to communicate the source and the destination systems have to share a common layer, for discovering an application in RINA this is not a prerequisite. What discovering a requested application does require is finding which layers make it available, and then choosing an existing layer to join or creating a new one to enable the communication.

Figure 1 describes this problem in a graphical way. The web browser (application A) residing in host H3 requests to communicate with the web page (application B) on host H2. The question is which layers support application B and which one should be chosen for the communication between the two applications.

Fig. 1: Application discovery involves also discovery of the layers that support the requested application.

The current Internet architecture provides no answer to this question. First, names for layers are not part of the architecture making it impossible to describe layers. In addition, the only directory service in the Internet is the Domain name System (DNS), which provides synonyms of interface addresses. Information on the application names and the layers that make them available is not stored in some way. As a consequence, all discoverable applications are assumed to be accessible via the same layer instantiation, the same IP address space, whether a private network or public Internet.

RINA as a complete internetwork architecture does provide name for layers. The application responsible for discovering a requested application and also the layers (DIFs) that make it accessible is called Inter-DIF Directory (IDD). The IDD is a distributed application, a set of application processes executing in one or more than one processing systems, exchange information using IPC and maintain shared state. An example of an IDD application is illustrated in Figure 2. Each processing system that wants to make its applications discoverable from other applications will run an IDD that will maintain information on the applications running in the system and the layers that make them available.

Fig. 2: An example of an IDD application.

As it seems logical, when a request for communication with a particular application is done, first all the layers that the requesting system is a member of will be tried. If the requested application is not found, the IDD running on the system should simply ask its peers. The peers are not other than the IDD application processes executing in other processing systems that the reference system is able to ask, or in other words, the IDDs residing in systems that share a DIF with the reference system. So, the source IDD will form a request that will be forwarded from one peer to another until  the requested application is found (or some predefined condition is met to avoid infinite forwarding).

In the case that the requested application is found, the IDD will have first to verify that the requested application is still executing there and then that the requesting application is allowed to communicate with it. If both checks turn out to be positive, the next action for the IDD is to create a DIF that will support the communication between the two applications. Since a common DIF between the source and the destination systems does not exist, a new one will have to be created by either expanding (joining) an existing DIF or by creating a new one from scratch. The creation of the supporting DIF involves choosing a path from the source to the destination and coordination between the intermediate IDDs for the creation and the initialization of the new IPC application processes. Also, authorization control and investigation whether the required quality of service can be provided by all the systems across the path have to take place. Once the supporting DIF is in place, communication between the two applications can start.

Our understanding of the IDD is still  preliminary. However so far the implications it brings in network architectures seem of ample importance. It appears that it eliminates the need for layers with large address spaces and creates greater security by better compartmentalization without impairing reachability. Research on the topic is on-going in which DANA i2CAT is involved. The great news is that we expect other implications to emerge as we further explore the IDD’s properties. 😉

This entry was posted in Ongoing Projects, Research and tagged , , , . Bookmark the permalink.