irati experimentation, us-eu fire workshop
DESCRIPTION
Presentation of the experimentation aspects of the IRATI project, carried out at the US-EU FIRE Workshop 2013TRANSCRIPT
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([email protected])