Investigating RINA as an Alternative to TCP/IPInvestigating RINA as an Alternative to TCP/IP

Project experimentation

Evaluation of the RINA prototype in the iLab.t virtual wall and Experimenta testbeds

GENI-FIRE Workshop, Belgium, October 2013

IRATI - Investigating RINA as an Alternative to TCP/IP

Project at a glance

• What? Main goals– To advance the state of the art of RINA towards an architecture

reference model and specifications that are closer to enable implementations deployable in production scenarios.

– The design and implementation of a RINA prototype on top of Ethernet will enable the experimentation and evaluation of RINA in comparison to TCP/IP.

2

Budget

Total Cost 1.126.660 €

EC Contribution 870.000 €

Duration 2 years

Start Date 1st January 2013

External Advisory Board

Juniper Networks, ATOS, Cisco Systems, Telecom Italia, BU

5 activities: WP1: Project management WP2: Architecture, Use cases and

Requirements WP3: Software Design and

Implementation WP4: Deployment into OFELIA

testbed, Experimentation and Validation

WP5: Dissemination, Standardisation and Exploitation

Who? 4 partners

RINA is an..

Innovative approach to computer networking using inter-process

communications (IPC), a set of techniques for the exchange of data among multiple threads in processes running on one or more

computers connected to a network.

3

The RINA principle:

Networking is not a layered set of different functions but rather a single

layer (DIF) of distributed IPC’s that repeats over different scopes.

Ref. : J. Day: “Patterns in Network Architecture: A Return to Fundamentals, Prentice Hall, 2008.

RINA Architecture

• A structure of recursive layers that provide IPC (Inter Process Communication) services to applications on top

• There’s a single type of layer that repeats as many times as required by the network designer

• Separation of mechanism from policy

• All layers have the same functions, with different scope and range.– Not all instances of layers may need all functions, but don’t need more.

• A Layer is a Distributed Application that performs and manages IPC (a Distributed IPC Facility –DIF-)

• This yields a theory and an architecture that scales indefinitely, – i.e. any bounds imposed are not a property of the architecture itself.

4

1 2 3 4

1 2 1 2 3 1 2

1 21 2

DIF A

DIF BDIF C

DIF D

DIF E DIF F

Architectural model

DIF

System (Host)

IPC Process

Shim IPC Process

MgmtAgemt

System(Router)

Shim IPC Process

Shim IPC Process

IPC Process

MgmtAgemt

System(Host)

IPC Process

Shim IPC Process

MgmtAgemt

Appl. Process

Shim DIF over TCP/UDP

Shim DIF over Ethernet

Appl. Process

IPC API

Data Transfer Data Transfer Control Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection

Transmission Control

Retransmission Control

Flow Control

RIB Daemon

RIB CDAP Parser/Generator

CACEP Enrollment

Flow Allocation

Resource Allocation

Forwarding Table Generator

Authentication

State VectorState VectorState Vector

Data Transfer Data Transfer

Transmission ControlTransmission Control

Retransmission Control

Retransmission Control

Flow ControlFlow Control

Increasing timescale (functions performed less often) and complexity

6

Flow of RINA (IRATI) R&D and experimentation activities(feedback between activities not shown for clarity reasons)

Research on RINA

reference model

Core RINA specs

Research on policies for

different areas

Data transfer

Management

Security

Routing Resource allocation

Enrollment

Application discovery

MultiplexingDIF

creation

Policy specs

Design and development of

simulators

Simulators

Prototyping

Different Platforms

Java VM

Linux OS

Android OS

NetFPGA

Coexisting with

different technolog

ies

TCP/UDP/IP

VLANs

WiFi

LTEMPLS

PrototypesStudy different

use cases and deployment

options

Use case analy

sis

Experimentation and validation

Data and

conclusions

IRATI - Investigating RINA as an Alternative to TCP/IP

Phase 1: Basic Functionality - UNIX-like OS

• Ongoing• Validate basic RINA functionality • Define the requirements of a RINA deployment within a local area

network (weak security requirements, support of legacy applications, best-effort QoS, flat addressing scheme)

• The target platform will be Debian with RINA in the kernel stack

Single-island deployment with corresponding RINA DIFs

Multi-island experiment on iLab.t virtual wall and i2CAT’s Experimenta

testbed

7

IRATI - Investigating RINA as an Alternative to TCP/IP

Phase 2: Scalability and JunOS

• Planned July 2014• Target different deployment scenarios

– single network provider with different network hierarchies, different levels of QoS, multiple network service providers, etc

• Assume that all the networks are either RINA or Ethernet capable (i.e. no IP)

• The UNIX- like OS and JunOS will be the target platforms of this phase

Single island with Juniper router and multiple RINA nodes within the Virtual Wall

8

IRATI - Investigating RINA as an Alternative to TCP/IP

OFELIA

Phase 3: IP gateway and interoperability

• Planned Dec 2014• Interoperability between RINA prototypes, developed outside

of the project and deployed in a RINA network surrounded by an IP network

• At this stage we will collaborate with the Pouzin Society through Boston University

Interoperability between the PSOC and IRATI RINA prototypes9

Requirement IRATI

Resource discovery Availability of nodes, potential VM capabilities (CPU, memory, HD, interfaces), being able to design the L2 connectivity graph between virtual interfaces, VLAN tagging support

Resource reservation All resources available at once.

Resource provisioning Instantiation of VMs and configuration of L2 switches (creation of the required VLANs) to setup the connectivity between VMs. Configuration of the VLANs in the interfaces of the VMs would be nice to have.

Experiment control Experimenters log into the different VMs to setup different configurations of the RINA software, execute different test applications, etc.

Monitoring Monitoring of traffic per VLAN, as well as the resource utilization of the virtual machines (CPU, memory, virtual interfaces). Utilities for easily capturing and crafting ARP and Ethernet frames would be nice to have.

Permanent storage The virtual machines hosting the IRATI prototype require 15-20 GB of storage to host the OS, RINA binaries plus traces, logs and state.

Identity management Allow different experimenters within the project to setup independent slices

Authorization Individual access to different slices (some of them can be shared between multiple researchers)

SLA management --

First Level Support Status information on the Virtual Machines and connectivity amongst them, plus ability to request for corrective actions if something breaks

Dataplane interconnection

For RINA over Ethernet: L2 interconnection with VLAN-tagging support, would be nice to be able to choose different loss and delay distributions for the links. For RINA over TCP/UDP: L3 interconnection (IPv4 at a minimum, IPv6 nice to have), with access to the Internet (interop with other RINA prototypes)

11

Investigating RINA as an Alternative to TCP/IP 12

Federation issue: VLAN transparency• IRATI requires VLAN tags as a DIF name

• The iLab.t virtual wall uses VLANs to separate experiments.

• The central switch does not support double tagging (802.1ad), all frames with Ethertype 0x8100 are dropped by the central switch. VLANs cannot be used inside experiments.

– Solution: patched the linux kernels (version 3.9.6) and NIC device drivers of the machines to use Ethertype 0x7100 instead of 0x8100 for 802.1Q traffic inside vwall.

• Need an additional machine to do “Ethertype translation” between the i2CAT Experimenta and iLab.t virtual wall testbeds.

Investigating RINA as an Alternative to TCP/IPInvestigating RINA as an Alternative to TCP/IP

Thanks for your attention!

Sergi Figuerola(sergi.figuerola@i2cat.net)