1. #ict-pristine IRATI: An open source RINA implementation for Linux/OS Eduard Grasa on behalf of The PRISTINE consortium

2. OVERVIEW: GOALS AND HIGH LEVEL DESIGN 2 1 #ict-pristine

3. … 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 3 1 2 3 4 5 1 2 3 4 5 #ict-pristine

4. Some decisions and tradeoffs 4 DecisionProsCons 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

5. High-level software arch. 5

6. PRISTINE contributions: SDK, policies, NMS 6 Normal IPC Process (Layer Management) User space IRATI stack Kernel Kernel IPC Manager Normal IPC Process (Data Transfer/Control) Shim IPCP over 802.1Q Shim IPCP for HV Shim IPCP TCP/UDP IPC Process Daemon (Layer Management) IPC Manager Daemon Normal IPC Process (Data Transfer/Control) Shim IPCP TCP/UDP Shim IPCP for HV Shim IPCP over 802.1Q Application zoom in Normal IPC Process (Data Transfer/Control) Error and Flow Control Protocol Relaying and Multiplexing Task SDU Protection SDK support RTT policy Tx ctrl policy ECN policy... SDK support Forwar policy Schedu policy Max Q policy Monit policy SDK support TTL policy CRC policy Encryp policy Normal IPC Process (Layer Management) RIB & RIB Daemon librina Resource allocation Flow allocation Enrollment Namespace Management Security Management Routing SDK support Auth. policy Acc. ctrl policy Coord policy SDK support Address assign Directory replica Address validat SDK support New flow policy SDK support PFT gen policy Pushbak notify SDK support Enroll. sequenc e SDK support Routing policy IPC Manager RIB & RIB Daemon librina Manageme nt agent (NMS DAF) IPCM logic Network Manager (NMS DAF)

7. Implementation status (I) General IRATI objectives, outcomes and lessons learned 7 ComponentSummary of status Management Agent Initial implementation ready: IPCP creation, destruction; assignment to a DIF; triggering of enrollment operation; query RIB ManagerInitial PoC ready, working on integration with Management Agent. Shim IPCP over 802.1q Wrap a VLAN interface or a full Ethernet interface with the DIF API. Uses own implementation of ARP internally. Single QoS cube. Shim IPCP over TCP/UDP Wrap a TCP/UDP-IP layer with the DIF API. Two QoS cubes: reliable (“implemented” with a TCP connection) and unreliable (UDP) Shim IPCP for HV Allow VM-to-host communications over shared memory wrapping it with the DIF API. Normal IPC ProcessSee next slides SDK (kernel RPI) Support for RMT and EFCP. Need to improve granularity of policy- sets and add support for SDU Protection. SDK (user-space RPI) Support for enrollment, auth, flow allocation, namespace mgr, resource allocator, routing. Need CDAP, RIB Daemon support.

8. Implementation status (I) IPCP components IRATI objectives, outcomes and lessons learned 8 IPCP componentSDKAvailable policies / comments CACEPYNo authentication, password-based, cryptographic (RSA keys) SDU Protection N On/off hardcoded default policies, no SDK support yet: CRC32 (Error Check), hopcount (TTL enforcement), AES encryption CDAP NGoogle Protocol Buffers (GPB) encoding, no support for filter op EnrollmentYDefault enrollment policy based on enrollment spec Flow AllocationYSimple QoS-cube selection policy (just reliable or unreliable) Namespace Mgr.YStatic addressing, fully replicated Directory Forwarding Table RoutingYLink-state routing policy based on IS-IS Res. AllocatorYPDU Fwding table generator policy with input from routing EFCPYRetx. Control policies, window-based flow control, ECN receiver RMTY Multiplexing: simple FIFO, cherish/urgency. Forwarding: longest match on dest. address, multi-path forwarding, LFA. ECN marking

9. QUICK DEMO 9 2

10. Overlay2 2 Quick demo scenario 10 VLAN 110VLAN 100 Shim DIF over 802.1Q, “100” Shim DIF over 802.1Q “110” test1.IRATI 16 test2.IRATI 17 test3.IRATI 18 “Normal.DIF” Server app Client app System 1System 2System 3 eth1 eth2 eth1 Nothing too fancy, just show how IPCPs are created and configured currently, 2 levels of DIFs and the “rina-echo-time” application on top Overlay1 1 “vpn.DIF”

11. EXPERIMENTAL ACTIVITIES 11 3

12. Decide the number and scope of the layers (DIFs) in the network,. Example: – Three ISPs that use multiple DIFs internally for traffic aggregation purposes – ISP alliance DIF: the three ISPs get together to support a number of specialized DIFs Public Internet DIF (General purpose), Corporate VPN DIF, Interactive Video DIF Designing RINA networks (I) Number, scope of layers and goal of each one 12 ISP 2 Metro DIF ISP 2 Regional DIF ISP 2 Backbone DIF ISP 3 Metro DIF ISP 3 Backbone DIF ISP 1 Metro DIF ISP 1 Backbone DIF ISP Alliance DIF Public Internet DIF Corporate VPN DIF Interactive Video DIF

13. Designing RINA networks (II) QoS cubes to be supported by each layer Identify the types of traffic that should be served by each layer and dimension it. Ideally, for each type of traffic, we would like to know: – Characterization in terms of burstiness, offered load, etc – Required statistical bounds on loss and delay (e.g. 99% of time loss should be less than 5%) -> can be derived from required QoE – Reliable and/or in order delivery of data required? From that information the number and characteristics of QoS cubes required can be derived. 13

14. Designing RINA networks (III) Policy sets of each layer Design new (or use existing) policy sets that allow each layer to reach its design goals taking into account its operational environment (offered traffic, QoS cubes supported, N-1 DIFs). – Connectivity graph, addressing, routing, data transfer, delimiting, resource allocation, relaying and multiplexing, authentication, authorization, SDU protection, etc 14 IPC API Data TransferData Transfer Control Layer Management SDU Delimiting Data Transfer Relaying and Multiplexing SDU Protection Retransmission Control Flow Control RIB Daemon RIB CDAP Parser/Generator CACEP Enrollment Flow Allocation Resource Allocation Routing Authentication State Vector Data Transfer Retransmission Control Flow Control Increasing timescale (functions performed less often) and complexity Namespace Management Security Management

15. Designing RINA networks (IV) Network Management System Analyze the role of the Network Management System (“ monitor and repair ”), a number of configurations are possible – from fairly centralized to autonomic. Understand the different operating ranges of the network, decide monitors/triggers to sense them and design strategies to automatically transition between different policy sets associated to the operating ranges. 15 MgrMA

16. Designing RINA networks (V) Interoperating with legacy technology If it has to interoperate with existing technology or support legacy apps, understand the required tooling for interoperation: shim DIFs, gateways, legacy application support. 16 Gateway VIFIB Node TCP or UDP Public Internet (IPv6) Ethernet Gateway VIFIB Node Ethernet (VLAN) Shim IPC Process Public Internet (IPv4) Ethernet... Ethernet... Shim IPC Process IPC Process SlapOS base DIF Shim DIF over UDP Shim DIF over 802.1Q Shim DIFs Gateway Legacy app faux Faux Sockets

17. Performance experiments (I) goodput 17 Note: The prototype is not performance-optimized yet An extra layer doesn’t add too much overhead

18. Performance experiments (II) delay 18 RTT directly over the shim DIF RTT directly over normal IPCP over shim Adding an extra DIF doesn’t incur a significant penalty on processing delay

19. Experiments we are currently setting up Distributed cloud scenario 19 Authentication, encryption Multi-layer congestion control/avoidance Delay/loss multiplexing (multiple QoS classes)

20. Experiments we are currently setting up Datacentre networking scenario 20 Multi-layer congestion control/avoidance QoS-aware multipath routing Routing in multiple layers

21. OPEN SOURCE INITIATIVE 21 4

22. Open source IRATI 22 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

23. Planned contributions to (open) IRATI 23 Open IRATI 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!

24. Further information can be found here. Twitter@ictpristine wwwwww.ict-pristine.eu