Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IRATI Experimentation, US-EU FIRE Workshop

1,345 views

Published on

Presentation of the experimentation aspects of the IRATI project, carried out at the US-EU FIRE Workshop 2013

  • Be the first to comment

  • Be the first to like this

IRATI Experimentation, US-EU FIRE Workshop

  1. 1. Project experimentation Evaluation of the RINA prototype in the iLab.t virtual wall and Experimentatestbeds GENI-FIRE Workshop, Belgium, October 2013 Investigating RINA as an Alternative to TCP/IP
  2. 2. Project at a glance • What? Main goals – To advance the state of the art of RINAtowards an architecture reference model and specificationsthat are closerto enable implementations deployable in production scenarios. – The designand implementation of a RINA prototype on top of Ethernet will enable the experimentationand evaluation of RINA in comparison to TCP/IP. Who? 4 partners 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 IRATI - Investigating RINA as an Alternative to TCP/IP 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 2
  3. 3. 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. Ref. : J. Day: “Patterns in Network Architecture: A Return to Fundamentals, Prentice Hall, 2008. 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. 3
  4. 4. RINA Architecture • 1 DIF A 2 1 DIF B 2 1 2 DIF C 2 DIF E • 1 There’s asingle type of layer thatrepeats as many times as required by the network designer • Separation of mechanism from policy 2 1 2 DIF F All layers have the same functions, with different scope and range. – • 3 • DIF D 1 • 4 3 A structure of recursive layers that provide IPC (Inter Process Communication)services to applications on top 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
  5. 5. Architectural model System (Host) System (Router) Appl. Process Appl. Process Mgmt Agemt DIF IPC Process IPC Process IPC Process Mgmt Agemt Shim IPC Process Shim DIF over TCP/UDP Shim IPC Process Shim IPC Process System (Host) Shim DIF over Ethernet Mgmt Agemt Shim IPC Process IPC API Data Transfer SDU Delimiting Relaying and Multiplexing SDU Protection State Vector State Vector State Vector Data Transfer Data Transfer Data Transfer Layer Management Data Transfer Control Transmission Transmission Transmission Control Control Control Retransmission Retransmission Retransmission Control Control Control Flow Control Flow Control Flow Control CACEP RIB Daemon RIB Enrollment Authentication Flow Allocation CDAP Parser/Generator Resource Allocation Forwarding Table Generator Increasing timescale (functions performed less often) and complexity 6
  6. 6. Flow of RINA (IRATI) R&D and experimentation activities (feedback between activities not shown for clarity reasons) DIF creation Data transfer Manage ment Security Multiplexing Research on Application policies for discovery different Enrollment areas Routing Policy specs Resource allocation Design and development of simulators Study different use cases and deployment options Research on RINA reference model Core RINA specs Simul ators Use case analy sis Proto types Prototyping Java VM Linux OS Data and conclu sions Experiment ation and validation Different Platforms Android OS NetFP GA TCP/UDP /IP Coexisting VLANs with different technolog WiFi ies MPLS LTE
  7. 7. 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 Multi-island experiment on iLab.t virtual wall and i2CAT’s Experimentatestbed Single-island deployment with corresponding RINA DIFs IRATI - Investigating RINA as an Alternative to TCP/IP 7
  8. 8. 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 IRATI - Investigating RINA as an Alternative to TCP/IP 8
  9. 9. 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 OFELIA Interoperability between the PSOC and IRATI RINA prototypes IRATI - Investigating RINA as an Alternative to TCP/IP 9
  10. 10. 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 tosetup 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 StatusinformationontheVirtualMachinesandconnectivity 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 accesstotheInternet (interop with other RINA prototypes) 11
  11. 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
  12. 12. Thanks for your attention! Sergi Figuerola (sergi.figuerola@i2cat.net) Investigating RINA as an Alternative to TCP/IP

×