Investigating RINA as an Alternative to TCP/IP Investigating 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

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  Contribu5on   870.000  €  

Dura+on   2  years  

Start  Date   1st  January  2013  

External  Advisory  Board  

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

5  ac+vi+es:  

  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  

IRATI - Investigating RINA as an Alternative to TCP/IP

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:  “PaOerns  in  Network  Architecture:  A  Return  to  Fundamentals,  Pren5ce  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   2  1   2  

DIF  A  

DIF  B  DIF  C  

DIF  D  

DIF  E   DIF  F  

Naming and addressing in RINA

•  All application processes (including IPC processes) have a name that uniquely identifies them within the application process namespace.

•  In order to facilitate its operation within a DIF, each IPC process within a DIF gets a synonym that may be structured to facilitate its use within the DIF (i.e. an address).

  The scope of an address is the DIF, addresses are not visible outside of the DIF.

  The Flow Allocator function of the DIF finds the DIF IPC Process through which a destination Application process can be accessed.

  Because the architecture is recursive, applications, nodes and PoAs are relative   For a given DIF of rank N, the IPC Process is a node, the process at the layer N+1 is an

application and the process at the layer N-1 is a Point of Attachment.

1   2   3   4  

1   2   1   2   3   1   2  

1   2  1   2  

DIF  A  

DIF  B  DIF  C  

DIF  D  

DIF  E   DIF  F  

5  

Architectural model

                                                                                                                         DIF  

System  (Host)  

IPC  Process  

Shim  IPC  Process  

Mgmt  Agemt  

System  (Router)  

Shim  IPC  Process  

Shim  IPC  Process  

IPC  Process  

Mgmt  Agemt  

System  (Host)  

IPC  Process  

Shim  IPC  Process  

Mgmt  Agemt  

Appl.    Process  

Shim  DIF    over  TCP/UDP  

Shim  DIF    over  Ethernet  

Appl.    Process  

IPC  API  

Data  Transfer   Data  Transfer  Control   Layer  Management  

SDU  Delimi+ng  

Data  Transfer    

Relaying  and  Mul+plexing  

SDU  Protec+on  

Transmission  Control  

Retransmission  Control  

Flow  Control  

RIB  Daemon  

RIB   CDAP  Parser/Generator  

CACEP   Enrollment  

Flow  Alloca+on  

Resource  Alloca+on  

Forwarding  Table  Generator    

Authen+ca+on  

State  Vector  State  Vector  State  Vector  

Data  Transfer    Data  Transfer    

Transmission  Control  Transmission  Control  

Retransmission  Control  

Retransmission  Control  

Flow  Control  Flow  Control  

Increasing  +mescale  (func+ons  performed  less  oVen)  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  

Rou+ng   Resource  alloca+on  

Enrollment  

Applica+on  discovery  

Mul+plexing  DIF  

crea+on  

Policy  specs  

Design  and  development  of  

simulators  

Simulators  

Prototyping  

Different  PlaYorms  

Java  VM  

Linux  OS  

Android  OS  

NetFPGA  

Coexis+ng  with  

different  technolog

ies  

TCP/UDP/IP  

VLANs  

WiFi  

LTE  MPLS  

Prototypes  Study  different  

use  cases  and  deployment  op+ons  

Use  case  analysis  

Experimenta+on  and  valida+on  

Data  and  

conclusions  

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    

Mul=-­‐island  experiment  on  iLab.t  virtual  wall  and  i2CAT’s  Experimenta  

testbed  

IRATI - Investigating RINA as an Alternative to TCP/IP 7  

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  mul=ple  RINA  nodes  within  the  Virtual  Wall  

IRATI - Investigating RINA as an Alternative to TCP/IP 8  

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  prototypes  

IRATI - Investigating RINA as an Alternative to TCP/IP 9  

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

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/IP 12

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

Thanks for your attention! Sergi Figuerola

(sergi.figuerola@i2cat.net)