User:Stationarytraveller/Recursive InterNetwork Architecture

Recursive InterNetwork Architecture (RINA) is a network architecture based on the fundamental principle that networking is only Inter-process communication (IPC), meaning application processes that communicate.

Main Principles

Networking provides the means by which processes on separate computer systems communicate, generalizing the model of local inter-process communication (IPC). In an operating system, to allow two processes to communicate, IPC requires certain functions such as locating processes, determining permission, passing information, scheduling, and managing memory. Similarly, two application processes residing on different systems communicate and share state information by utilizing the services of a Distributed IPC Facility (DIF). A DIF is an organizing structure, grouping together application processes that provide IPC service and are configured under the same policy. A DIF can be seen as what we generally refer to as a "layer". According to this view, networking is not a layered set of different functions but rather a single layer of distributed IPC that repeats over different scopes, i.e. providing the same functions/mechanisms but tuned under different policies to operate over different ranges of the performance space (e.g. capacity, delay, loss). Thus, a basic principle of RINA architecture is the separation of policy and mechanism. Any two application processes in different systems are able to communicate using the services provided by a DIF, and DIFs of higher layers are able to use the services provided by DIFs of lower layers, forming a recursive structure.

An example of Recursive InterNetwork Architecture with 3 levels of DIFs.

Components of an IPC Process

Each IPC process executes routing, transport, security/authentication and management functions and provides an API (IPC API) to the client layer that uses the IPC services provided. The components of an IPC process responsible for providing these functions can be categorized under two main categories, IPC Data Transfer and IPC Management.

IPC API

Each IPC process provides the layer above with a set of primitives to provision IPC services. The IPC API provides four operations:

• Allocate: Allocate communication resources to support a flow between source and destination application processes with a certain quality of service. A portId is returned as a handle for the allocation.
• Send: Sends an amount of data to the destination application process on the specified port. The amount of data passed across two layers to be transferred to the destination is referred to as a Service Data Unit (SDU). An SDU may be fragmented or combined with other SDUs.
• Receive: Receives an SDU from the destination application process in the specified port.
• Deallocate: Terminates the flow and frees all the communication resources allocated to it.

IPC Data Transfer

The IPC Data Transfer consists of the SDU Delimiting task, the Error and Flow Control Protocol (EFCP), the relaying and multiplexing tasks and the SDU protection task:

• SDU Delimiting: Mechanisms used to indicate the beginning and the end of SDUs. Delimiting can be done using a special bit pattern to denote the start and the end of the SDU or using a length field in the PCI that can be used to calculate the end of the SDU.
• Error and Flow Control Protocol (EFCP): A data transfer Protocol based on Delta-T . EFCP is split into two independent protocol machines (DTP and DTCP), loosely coupled through a state vector. Data Transfer Protocol (DTP) machine implements mechanisms that are tightly coupled to the transported SDU, such as fragmentation, reassembly, sequencing, concatenation, separation. The Data Transfer Control Protocol (DTCP) machine implements mechanisms that are loosely coupled to the transported SDU, such as transmission control, retransmission control and flow control. The string of octets exchanged between two protocol machines is referred to as Protocol Data Unit (PDU). PDUs comprise of two parts, Protocol Control Information (PCI) and user data. PCI is the part understood by the DIF, while the user data is incomprehensible to the DIF and is passed to its user.
• Relaying Task: The role of this task is to forward the PDUs passing from this IPC process to the destination Protocol Machine (PM) by checking the destination address in the PCI.
• Multiplexing Task: Mapping of the flows of PMs belonging to a higher layer onto flows of PMs belonging to a lower layer.
• SDU Protection: Mechanisms to protect the SDU from byte errors and to provide confidentiality and integrity. Mechanisms such as Data Corruption Protection, checksums, hop count, Time To Live and encryption are included.

IPC Management

The IPC Management consists of the Flow Allocator component, authentication mechanisms, the Common Distributed Application Protocol (CDAP), the Resource Allocation, the Resource Information Base (RIB) and the RIB Daemon:

• Flow Allocator (FA): A component responsible for responding to allocate requests and for managing each new flow that passes from this IPC process.
• Authentication: Security related functions such as authentication, access control and protection against tampering and eavesdropping by the lower layers.
• Common Distributed Application Protocol (CDAP): The application protocol, similar to an assembly language used to build all the distributed applications. CDAP is a descendant of common management information protocol (CMIP) and allows to perform operations on objects such as read, write, create, delete, start and stop.
• Resource Information Base (RIB): A database that stores all the information available to the IPC process represented as objects, such as mappings of addresses, resource allocation information, connectivity information, security credentials and others.
• Resource Allocator (RA): A component that manages resource allocation and monitors the resources in the DIF by sharing information with other IPC processes and observing the performance of supporting DIFs.
• RIB Daemon: A generalisation of event management and routing update. The RIB Daemon is responsible for responding to requests for information from other members of the DIF, notify them periodically or upon certain events on the current value of specific information, as well as reply to external requests for information. In addition, RIB Daemon ensures that the other management tasks have the information they require.

Features

• A 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 over a different scope. The recursive structure of the distributed IPC model allows it to scale indefinitely, thus it avoids current problems of growing routing tables.
• A complete naming and addressing schema RINA adopts and extends Jerome Saltzer's view for providing a naming and addressing schema. Applications request flows to other applications without having to know where the requested application is. Addresses are internal to a DIF, they are just synonyms of the names of the application processes that conform the DIF, optimized for routing.
• Multi-homing, mobility and multicast are supported inherently by the architecture without the need for any special protocols at little or no cost.
• A single error and flow control protocol Error and Flow Control Protocol (EFCP), which can be configured in order to meet the different needs of the transport service each time.
• A single application protocol Common Distributed Application Protocol (CDAP), which can be used to develop all the distributed applications.
• A secure network Applications need to authenticate with one another before being able to exchange information. Applications are not allowed to communicate with the elements inside a DIF unless they are members of that DIF, which requires authentication.
• Quality of Service Each DIF can support a set of QoS classes and provide service guarantees to its clients.
• A competitive marketplace RINA creates the robust feedback needed for a healthy marketplace. Each DIF can be configured to not only provide the traditional services of lower networking layers but also application-support services. This removes the barrier created by the Transport Layer in the current Internet, opening potential new markets for ISPs to provide IPC services directly to their customers, leveraging their expertise in resource management of lower layers and creating new competition with “host” providers.

History

RINA was proposed by John Day (computer scientist) in his book “Patterns in Network Architecture: A return to fundamentals” .

See also

• Inter-process communication (IPC)

Further reading

• Day J., Matta I. and Mattar K.: Networking is IPC: A Guiding Principle to a Better Internet. In: Proc. of ReArch08, Madrid, Spain, 2008

• Mattar K., Matta I., Day J., Ishakian V. and Gursun G.: Declarative Transport. A Customizable Transport Service for the Future Internet. In: Networking Meets Databases (NetDB), Montana, USA, 2009

• Ishakian V., Matta I. and Akinwumi, J.: On the cost of supporting mobility and multihoming. In: GLOBECOM Workshops, IEEE, pp. 310–314, 2010

External links

• Pouzin Society website
• RINA at Computer Science Department of Boston University
• RINA prototype at i2CAT Foundation website