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