Successfully reported this slideshow.
Your SlideShare is downloading. ×

Irati goals and achievements - 3rd RINA Workshop

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 27 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Irati goals and achievements - 3rd RINA Workshop (20)

Advertisement

Irati goals and achievements - 3rd RINA Workshop

  1. 1. IRATI objectives, outcomes and lessons learned The IRATI project: objectives, outcomes and lessons learned 3rd international RINA Workshop. Ghent. January 2015 Eduard Grasa (Fundació i2CAT) on behalf of the IRATI team
  2. 2. Quick facts about the project IRATI objectives and outcomes 2 • 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. 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, TRIA Network Systems 5 activities:  WP1: Project management  WP2: Arch., Use cases and Req.  WP3: SW Design and Implementation  WP4: Deployment into OFELIA  WP5: Dissemination, Standardisation and Exploitation Who? 5 partners From 2014
  3. 3. Main goals • Linux/OS RINA implementation over Ethernet, which can be a platform for research and future RINA-based products IRATI objectives, outcomes and lessons learned 3 1 • Experimental evaluation of the RINA implementation and comparison with the TCP/IP networking stack 2 • Advance the SotA of RINA specifications: work out new ones, debug and enhance existing ones 3 • Increase RINA awareness in sci/tech community and contribute to the development of its standardization strategy 4
  4. 4. LINUX/OS RINA IMPLEMENTATION IRATI objectives, outcomes and lessons learned 4 1
  5. 5. • … but can also be the basis of RINA-based products – Tightly integrated with the Operating System – Capable of being optimized for high performance – Enables future hardware offload of some functions – Capable of seamlessly supporting existing applications – IP over RINA RINA implementation goals • Build a platform that enables RINA experimentation … – Flexible, adaptable (host, interior router, border router) – Modular design – Programmable – RINA over X (Ethernet, TCP, UDP, USB, shared memory, etc.) – Support for native RINA applications IRATI objectives, outcomes and lessons learned 5 1 2 3 4 5 1 2 3 4 5
  6. 6. Some decisions and tradeoffs IRATI objectives, outcomes and lessons learned 6 Decision Pros Cons Linux/OS vs other Operating systems Adoption, Community, Stability, Documentation, Support Monolithic kernel (RINA/ IPC Model may be better suited to micro-kernels) User/kernel split vs user-space only IPC as a fundamental OS service, access device drivers, hardware offload, IP over RINA, performance More complex implementation and debugging C/C++ vs Java, Python, … Native implementation Portability, Skills to master language (users) Multiple user-space daemons vs single one Reliability, Isolation between IPCPs and IPC Manager Communication overhead, more complex impl. Soft-irqs/tasklets vs. workqueues (kernel) Minimize latency and context switches of data going through the “stack” More complex kernel locking and debugging
  7. 7. High-level software arch. IRATI objectives, outcomes and lessons learned 7
  8. 8. Open source IRATI IRATI objectives, outcomes and lessons learned 8 • IRATI github side • http://irati.github.io/stack • Hosts code, docs, issues • Installation guide • Experimenters (tutorials) • Developers (software arch) • Mailing list for users and developers • irati@freelists.org • Procedures to contribute under discussion, doc ongoing
  9. 9. Planned contributions to (open) IRATI IRATI objectives, outcomes and lessons learned 9 Open IRATI FP7 IRATI project • Merge last contributions (new kernel workflow, DTCP, DU Protection, fixes) Feb/March 2015 FP7 PRISTINE project • Software Development Kit (RPI) • Simple configuration tools • Management Agent • Enhanced CDAP and RIB libraries • Several IPCP Policies • Bug fixes • Faux sockets? Network Manager? Contribs during 2015 and 1H 2016 G3+ OC winner IRINA project • Traffic generation modules for test apps, bug fixes April/May 2015 You • Lots to do! Let’s talk!
  10. 10. EXPERIMENTAL EVALUATION OF THE RINA IMPLEMENTATION IRATI objectives, outcomes and lessons learned 10 2
  11. 11. Comparison to TCP/IP Not an excuse, but … • What is a meaningful comparison today? – Raw performance – Stability/bugs IRATI objectives, outcomes and lessons learned 11 Contributors Time Specs Deployed RINA Prototype 8-10 (partial) 1.5 years Experimental IRATI Linux networking stack 100s 20+ years Stable for years Millions of systems – Structure/complexity of implementation – Flexibility/adaptability of design – Programmability of implementation – Application interface
  12. 12. RSVP Daemon VPN software Structure and flexibility (RINA vs TCP/IP) • RINA: As many IPCPs as you wish; single point of management of the stack; configurable to be a router or a host; no protocols -> policies • TCP/IP stack: TCP/UDP over IP over Ethernet (fixed configuration). If routing or resource reservation external software has to be added; if more layers VPN software has to be added; disperse config utils IRATI objectives, outcomes and lessons learned 12 IPCP (data transfer) IPCP (layer mgmt) Shim IPCP IPC Manager App KIPCM App Sockets TCP/UDP IP / Ethernet Traffic control Config. toolsRouting Daemon
  13. 13. RSVP Daemon VPN software Programmability (RINA vs TCP/IP) • RINA: Policies programmable in each IPCP: delimiting, EFCP syntax, flow control, rtx. control, addressing, routing, resource allocation, multipexing, authentication, authorization, TTL, encryption, CRC, etc. • TCP/IP stack: Fixed syntax, protocols not programmable, have to develop full new protocols to try new things (* with OF now you can “program” the forwarding table) IRATI objectives, outcomes and lessons learned 13 IPCP (data transfer) IPCP (layer mgmt) Shim IPCP IPC Manager App KIPCM App Sockets TCP/UDP IP / Ethernet Traffic control Config. toolsRouting Daemon
  14. 14. How to setup an experiment Master the config file! IRATI objectives, outcomes and lessons learned 14 Instantiation of IPCPs Shim DIF config Normal DIF config, routing Normal DIF config, EFCP 1 Login to the node 2 Edit config file 3 Start IPC Manager
  15. 15. Improving node configuration.. IRATI objectives, outcomes and lessons learned 15 • Today • Manual editing of the config files at each node -> time consuming and error-prone • Tomorrow (short-term) • Standalone tool to generate configuration files (PRISTINE) • RINA Plugin Infrastructure (RPI) Tooling (PRISTINE) • Tomorrow (mid-term) • RINA Configuration via Network Management System (PRISTINE)
  16. 16. Some early results • Performance evaluation of the RINA implementation – IEEE Globecom 2014. Achieves line-rate over GigE link. • Deliverable D4.3 (to be published next few weeks) – Influence of credit (constant policy) in throughput – Effect of adding parallel flows on throughput – Prototype CPU and memory resource utilization – Study of retransmission control behavior at various loss rates (immediate ACK policy vs. A-timer policy) with parallel flows – Validation and performance evaluation of shim DIF over TCP/UDP and shim DIF over Hypervisors – Evaluation of SDU Protection policies (CRC and TTL) – Study on interop requirements with TRIA Network Systems prototype IRATI objectives, outcomes and lessons learned 17 1 2 3 4 5 1 6 7
  17. 17. ADVANCE STATE OF THE ART OF RINA SPECIFICATIONS IRATI objectives, outcomes and lessons learned 18 3
  18. 18. • Source MAC @ (6 bytes) – Source shim IPC Process address • Destination MAC @ (6 bytes) – Destination shim IPC Process address • IEEE 802.1Q tag (2 bytes) – DIF name • Ethertype (2 bytes) – 0x0D1F 19 Shim DIF over Ethernet Ethernet II PCI Application data • Minimum length: 42 bytes (46 if 802.1Q not present) • Maximum length: 1500 bytes Shim DIF over 802.1Q Use of the Ethernet frame T-5 Alternatives to TCP/IP
  19. 19. Shim DIF over 802.1Q Environment Investigating RINA as an Alternative to TCP/IP 20
  20. 20. Shim DIF over TCP/UDP • Wraps an IP network with the DIF IPC API • Two QoS cubes possible: reliable and in-order-delivery of flows (TCP), unreliable (UDP) – More could be possible depending on the capabilities of the underlying IP network • IPCP name is mapped to an IP address and a port number – Using proprietary procedures or leveraging DNS (via SRV records) T-5 Alternatives to TCP/IP 21 IPCP a.1 IPCP b.1 Shim DIF over IP networks IP layer UDP Port:2524UDP Port:2524 Shim IPCP X.1 Shim IPCP Y.1 IP: 4.3.2.1 IP: 5.3.5.8 2 5 Flow
  21. 21. Shim DIF for HyperVisors IRATI objectives, outcomes and lessons learned 22 • Allow a VM to communicate with its Main Environment (Host OS for type 2 HV or privileged VM for type 1 HVs), using shared memory mechanisms Type 2 HyperVisor Type 1 HyperVisor
  22. 22. Link-state routing policy IRATI objectives, outcomes and lessons learned 23 RIB Daemon Resource Allocator PDU Forwarding Table Generator Events N-1 flow allocated N-1 flow deallocated N-1 flow down N-1 flow up Neighbor B invoked write operation on object X CDAP Incoming CDAP messages from neighbor IPC Processes CDAP Outgoing CDAP messages to neighbor IPC Processes Invoke write operation on object X to neighbor A Update knowledge on N- 1 flow state Propagate knowledge on N- 1 flow state Recompute forwarding table PDU Forwarding Table Relaying and Multiplexing Task Lookup PDU Forwarding table to select output N-1 flow for each PDU 4321 N-1 Flows to nearest neighbors IPC Process Enrollment Task Events Enrollment completed successfully
  23. 23. INCREASE RINA AWARENESS AND STANDARDS STRATEGY IRATI objectives, outcomes and lessons learned 24 4
  24. 24. Some reactions to the RINA message • Disseminating RINA can be challenging sometimes … IRATI objectives, outcomes and lessons learned 25 Skepticism If it’s so nice, why it is not implemented yet? Not mainstream? Don’t care
  25. 25. Some tips for disseminating RINA • RINA is a new architecture, not a single point solution. Position RINA as a better toolbox to allow architects/designers to design better networks. – Benefits of RINA are easier to understand when you take a systems view. • Explain relationship of RINA with hot topics such as SDN, NFV, 5G, ICN – In order to create initial interest and provide some context • We need to work out specific use cases of how RINA could be used in certain environments – See IRINA NRENs and GEANT use case – to be published soon IRATI objectives, outcomes and lessons learned 26
  26. 26. Standards: PSOC and ISO • Need for a forum that is the authoritative source for the RINA specifications and keeps them up to date – Must be formed by people that is interested in moving RINA forward and are experts in the topic -> cannot be established SDOs (have their own agendas) – PSOC talk later this afternoon by John Day • ISO SC6 WG 7 (Future Networks) – RINA presented last October, received with interest – Opportunity to bring RINA as one of this group’s projects; very long process but may be worth – It may work to do the RINA standards within PSOC, take them to ISO for approval and international recognition IRATI objectives, outcomes and lessons learned 27
  27. 27. IRATI objectives, outcomes and lessons learned Questions? Thanks to all the IRATI crew! http://irati.eu

Editor's Notes

  • 1)
  • Ideal platform for networking research (you can isolate one change while keep all the other environment the same) -> more repeatability of tests
  • If you need to to more you’ll need to develop your own policies -> wait for PRISTINE’s SDK!
  • (Disclaimer: Other shim DIFs over Ethernet are possible: with no VLANs; using LLC; over carrier Ethernet; …)

    A shim DIF over Ethernet maps to a VLAN
    The DIF name is the VLAN name

    The shim DIF only supports on class of service: unreliable

    ARP can be used to map upper layer IPC Process names to shim DIF addresses (MAC addresses)

    Only one application (a normal IPC Process) can be registered at each shim IPC Process
    No way to differentiate between multiple flows from the same pair of shim IPC Processes
  • A shim DIF over Ethernet maps to a VLAN
    The DIF name is the VLAN name
    The shim DIF only supports on class of service: unreliable
    ARP can be used to map upper layer IPC Process names to shim DIF addresses (MAC addresses)
    Spans a single Ethernet segment

×