Software architecture overview
This page provides an overview of the software architecture and components of the IRATI prototype. For a more detailed explanation we direct the reader to FP7 IRATI's D3.1, D3.2 and D3.3. The software architecture of the IRATI prototype is shown in Figure 1.
The main components of the RINA implementation have been divided into four packages:
-
Daemons (rinad). This package contains two types of daemons (OS Processes that run in the background), implemented in C++.
- IPC Manager Daemon (rinad/src/ipcm). The IPC Manager Daemon is the core of IPC Management in the system, acting both as the manager of IPC Processes and a broker between applications and IPC Processes (enforcing access rights, mapping flow allocation or application registration requests to the right IPC Processes, etc.)
- IPC Process Daemon (rinad/src/ipcp). The IPC Process Daemons (one per running IPC Process in the system) implement the layer management components of an IPC Process (enrollment, flow allocation, PDU Forwarding table generation or distributed resource allocation functions).
-
Librina (librina). The librina package contains all the IRATI stack libraries that have been introduced to abstract from the user all the kernel interactions (such as syscalls and Netlink details). Librina provides its functionalities to user-space RINA programs via scripting language extensions or statically/dynamically linkable libraries (i.e. for C/C++ programs). Librina is more a framework/middleware than a library: it has its own memory model (explicit, no garbage collection), its execution model is event-driven and it uses concurrency mechanics (its own threads) to do part of its work.
-
Kernel components (linux/net/rina). The kernel contains the implementation of the data transfer / data transfer control components of normal IPC Processes as well as the implementation of shim DIFs - which usually need to access functionality only available at the kernel. The Kernel IPC Manager (KIPCM) manages the lifetime (creation, destruction, monitoring) of the other component instances in the kernel, as well as its configuration. It also provides coordination at the boundary between the different IPC processes.
-
Test applications and tools (rina-tools). This package contains test applications and tools to test and debug the RINA Prototype. Right now the rina-tools package contains the rina-echo-time application, which can work both in “echo” (ping-like behavior between two application instances) or “performance” mode (iperf-like behaviour).
Common functionalities that are used by both the IPC Process Daemon and the IPC Manager Daemon.
Since both the daemons are event-based distributed applications, a common event-loop class has been developed (rinad::EventLoop). The event-loop class currently intercepts only librina events - e.g. events that inform the daemons about flow allocation/deallocation, IPC process enrollment, application registration/deregistration.
The user of the event-loop class can associate a different handler for each possible librina event type, using the EventLoop::register_event() method. When the event-loop intercepts a librina event, it checks if the user has registered a handler for the type of the received event. If a handler is present, it is invoked, passing as arguments the event received and a user-provided pointer to the data model instance of the specific event consumer - e.g. the IPC Manager daemon or the IPC Process daemon.
The global configuration for the IRATI stack has a non-trivial nested structure that is reflected in the rinad::RinaConfiguration class. This class has been ported from a Java class (having the same name) defined in the Java IPC Manager code. Since this class contains plenty of information about the stack configuration in general - e.g. information about the IPC processes to be created, configuration of the DIFs - the rinad:RinaConfiguration class has been moved from the IPC Manager to the rinad common functionalities.
The rinad::IPCManager class is the main class in the program, which represents the IPC Manager data model and contains all the data and functionalities used by the IPC Manager threads. Since there is only one IPC Manager per processing system, only one rinad::IPCManager object is instantiated. The rinad::IPCManager class exposes a set of methods that can be used to perform configuration operations on the IRATI stack. The most important methods are used for: creation of IPC Processes, destruction of IPC Processes, assigning IPC Processes to DIFs, registering IPC Processes to DIFs and triggering the enrollment of an IPC Process to a DIF.
The first step the IPC Manager has to perform is the parsing of the JSON file that contains the configuration of the RINA prototype for that system. This is done at the very beginning of the program execution, before the script thread, the console thread and the event-loop are started. The purpose of the configuration parsing module is to fill the rinad::RinaConfiguration instance contained in the rinad::IPCManager instance, using the information contained in the configuration file.
The IPC Manager implements a CLI console via a dedicated thread. The currently available commands - which roughly resemble the rinad::IPCManager methods - are the following:
- help: Show the list of available commands or the usage of a specific command.
- exit or quit: Exit the console.
- create-ipcp: Create a new IPC process.
- destroy-ipcp: Destroy an existing IPC process.
- list-ipcps: List the existing IPC processes with associated information.
- list-ipcp-types: List the IPC process types currently available in the system.
- assign-to-dif: Assign an IPC process to a DIF.
- register-at-dif: Register an IPC process within a DIF.
- unregister-from-dif: Unregister an IPC process from a DIF.
- enroll-to-dif: Enroll an IPC process to a DIF.
- query-rib. Display the information of the objects present at RIB of an IPC Processs.
The IPCP Daemon is a container of different components that either provide general support functions (e.g. as encoding/decoding objects, generating/parsing CDAP messages or the RIB Daemon) or implement layer management functionalities (e.g. enrollment, flow allocation, namespace management, resource allocation or security management). The IPCP can interact with the IPC Manager Daemon (IPCM) via librina’s ExtendedIPCManager proxy class, which translates function invocations to NetLink (NL) messages towards the IPCM OS process. In a similar way the IPCP Daemon interacts with the data transfer components of the IPC Process via librina’s KernelIPCProcess proxy class, which translates function invocations to NL messages or system calls, addressed to the kernel.
The IPCM creates the IPCP OS process by forking and executing the IPCP executable (i.e. ipcp). Upon creation, the IPCP Daemon checks if it has enough information to start, initializes librina and creates an instance of each component; both the utility components (Encoder, CDAP Session Manager, RIB Daemon) and the ones implementing layer management functions (Enrollment, Resource Allocator, Namespace Manager, Flow Allocator and Security Manager). After they are successfully initialized, the IPC Process main class invokes the set_ipc_process method on each of them. The IPCP Daemon has the following internal components:
RIB Daemon. The IPCP mostly leverages librina-rib for implementing its own RIB Daemon.
Enrollment Task. The rinad::EnrollmentTask class is the entry point to the functions related to IPC Process neighbour discovery and management. The logic of the enrollment sequence is implemented in two separate state machines by the rinad::EnrollerStateMachine and the rinad::EnrolleeStateMachine classes (used by the member and joining IPC Processes, respectively).
Namespace Manager. The rinad::NamespaceManager class is the IPC Process component in charge of managing the DIF’s address namespace and takes part in maintaining the Directory Forwarding Table (DFT). The DFT is a distributed map matching application names (registered with the DIF) to the address of the IPC process they are registered with. The current implementation of the DFT is a fully replicated map whose updates are disseminated to all members of the DIF via a controlled flooding approach.
Flow Allocator. The rinad::FlowAllocator class is the IPC Process component responsible for managing the lifecycle of the flows provided by the DIF. Lifecycle operations include creation, destruction and monitoring of key flow parameters to ensure the flow provides an acceptable level of service (the current prototype implements only the creation and destruction operations). The rinad::FlowAllocator class defers the work of managing individual flows to instances of the rinad::FlowAllocatorInstance class.
Resource Allocator. The rinad::ResourceAllocator class is in charge of providing the entry point to the functions performed by the ResourceAllocator. There are a wide range of functions that can be performed by this component but the current IRATI implementation just provides the implementation of two of them: management of N-1 Flows and generation of the PDU Forwarding Table using routing.
The rinad::NMinusOneFlowManager class manages the allocation and deallocation of the N-1 flows used by the IPC Process as well as the registration of the ICP Process to one or more N-1 DIFs.
The PDU Forwarding Table Generator is responsible for the generation of the PDU Forwarding Table (PDUFT), obtained through the use of a specific (routing) policy. The PDUFT maps destination addresses and QoS identifiers to the port identifiers of N-1 flows. These flows connect the IPC Process to its neighbours in the DIF. The PDUFT is used by the RMT – a software component residing in kernel-space – in order to multiplex/demultiplex the PDUs. The IRATI stack implements a link-state based routing approach. It maintains a graph representing the current knowledge of the connectivity of the DIF. Each vertex of the graph represents an IPC Process while each vertex pair represents an N-1 flow interconnecting the corresponding IPC Processes. An algorithm - e.g. the Dijkstra’s shortest path - is applied to the graph in order to compute the routes from a source IPC Process to every other IPC Process in the DIF. These routes are used to fill the PDUFT with entries mapping an <address, QoS> pair to the list of N-1 ports that have to be used to reach the next hop in the path towards the destination. Security Manager. The security manager is the IPC Process component responsible for managing all the security-related behaviours (i.e. authentication, access control, SDU Protection, credential management, auditing). Within the scope of IRATI, the implementation just provides a trivial implementation of two access-control related functions.