Experiment 1: Management of multi-layer converged service provider networks

The first experiment in WP4 is devoted to the experimental study of the management of converged RINA operator networks. It is expected that the commonality present in all the layers of RINA will greatly facilitate the job of the Network Manager, who can use the same model with a few variations (the policies in each DIF) to configure the multiple layers of the network. T4.2 will compare the amount of information required to configure and monitor heterogeneous multi-layer RINA networks to current packet networks, as well as the number of message exchanges between the Manager and the Management Agents to perform the most common actions in the operation of a service provider network (addition and configuration of systems, detection of failures and/or malfunctions, reconfiguration of systems, deployment and provisioning of network services).

T4.2 will also experiment with the idea that network management should be “monitor and repair” but not “control”. This task will use a series of pre-defined network strategies to deal with different network operational conditions (e.g., “low load, all systems up and running”, “average load, few system down”, etc). These strategies will configure a number of policies in the different layers, designed to be effective for a particular set of operational conditions. T4.2 will assess in practice the feasibility of this approach in RINA networks, analysing the trade-offs in measuring the network operational conditions and the effects of transient periods in-between network reconfigurations. The complexity of the management strategies will be compared to that of defining similar approach in current multilayer packet networks.

Experiment 2: Deploying resilient, virtualised services over heterogeneous physical media

This experiment will explore different RINA features that impact the deployment of resilient, virtualised services over heterogeneous physical media. RINA’s strengths in naming and addressing, multi-homing and mobility will be experimentally analysed within this task, since they are key properties for the efficient operation of networks over heterogeneous (wired/wireless) physical media. Experiment 2 will study how addressing nodes instead of interfaces reduces the size of the routing and forwarding table sizes and contributes to create more stable networks (due to a reduced number of routing updates compared to the interface addressing case). Naming the node is also the most cost-effective solution to the multi-homing problem, as T4.3 will demonstrate by comparing RINA’s approach to other multi-homing solutions designed for the Internet in terms of simplicity and effectiveness (number of in-flight packets lost while switching from a failed interface to another one, time to switch to another interface).

T4.3 will also quantify how well RINA networks handle mobility, experimenting with seamless handovers between lower-level DIFs that don’t break the flows provided to applications or other higher-level DIFs. Experimentation with routing policies tailored for mobility (that produce routing updates more frequently), will explore good trade-offs for the maximum size of a DIF given a certain mobility rate (maximum size will be limited by the time to disseminate the routing updates when a handover happens). Another key area for converged networks to effectively exploit heterogeneous physical media is the ability to customize the retransmission and flow control policies to the characteristics of each medium. T4.3 will study the behaviour of RINA networks with customised transport policies for wired and wireless links, comparing their effectiveness in terms of achieved throughput, delay or response to congestion to heterogeneous transport designs in current networks.

Experiment 3: End-to-end service provisioning across multiple network service providers

Experiment 3 will analyse the benefits provided by the RINA IPC API as an abstraction for distributed applications but also for service provisioning between different operators. Unlike in the current Internet, applications don’t need to specify what protocols whey will be using or bind sockets to well-known port-ids. The explicit flow allocation procedure in RINA enables applications to allocate a flow to a destination application by just specifying its name and a number of technology-agnostic parameters that define a contract for an acceptable level of service. This mechanism and relationship is also used between layers so that an upper layer can communicate its requirements to a bottom layer in a technology-agnostic way, freeing layers from divulging internal details to other layers and opening the door to end-to-end quality of service. T4.4 will make an experimental study on how all this infrastructure can be used to setup flows across multiple provider networks with end-to-end guarantees on the level of service experienced by the flow. Proper policies to select a QoS cube from the requirements specified at the flow level by the application are a key element.

T4.4 will also assess the cost of improving the quality of flows by introducing new features in the transport protocols in RINA compared to the current Internet. It is expected that RINA’s separation of mechanism from policy – which allows for a better re-use of common transport mechanisms – will introduce a high gain in efficiency and reduce the size of specifications and code duplication. In addition to the design and implementation costs, T4.4 will also analyse the deployment costs, identifying the changes required in both applications and networking functions.

Finally Experiment 3 will study a unique property of the RINA architecture, not supported by today’s internetworks: the capability of locating applications in multiple DIFs by name, and to dynamically create new end-to-end DIFs on top of existing ones in response to flow allocation requests for remote applications not initially sharing a DIF with the application that requested the flow. T4.4 will analyse the information that needs to be exchanged across different management domains in order to i) locate an application and ii) setup a new multi-provider DIF. The task will also look into the timescales required for these actions, and how different application search strategies or DIF creation approaches may influence these timescales.

Experiment 4: Studying the effects of (Distributed) Denial of Service (D)DoS attacks inside and over RINA networks

This task will carry out an experimental analysis of the effects of current DDoS attacks in RINA networks, comparing the resiliency of RINA networks to this type of attacks with the current state of the art. T4.5 will group the attacks under study in two main categories: attacks to the network infrastructure itself (DDoS to DIFs) and attacks to the applications (DAFs) supported by the DIFs. In both cases experiments will take into account the assumptions that are required for an attacker to launch an effective attack, the mechanisms in the network that allow the network operator to detect the attacks and the tools available to counter-measure these attacks. Examples of the attacks that will be investigated are: data transfer attacks (such as connection opening or closing attacks), attacks to the layer management infrastructure (routing, namespace management, enrolment, etc.), flow allocation flooding attacks or traffic flooding attacks (causing congestion in the network or the servers hosting the targeted applications).

The Key Performance Indicators that will be used to evaluate the resiliency of RINA against each type of DDoS attack are: the difficulty in preparing and executing a successful attack (what information is required by the attacker, how difficult is to obtain this information); the harm that the attack can cause (measured in a scale that goes from no appreciable consequences for other users to the disruption of one or more applications or DIFs); the difficulty in detecting the attack by the network operator (what information has to be monitored, an idea of the computational cost of analysing that information) and the cost-effectiveness of the counter-measures that the operator can deploy to mitigate the attack (can the attack be completely de-activated or only partially, how much time and resources it will take).