Mais conteúdo relacionado

Apresentações para você(20)

Similar a IRATI: an open source RINA implementation for Linux/OS(20)


IRATI: an open source RINA implementation for Linux/OS

  1. #ict-pristine IRATI: An open source RINA implementation for Linux/OS Eduard Grasa on behalf of The PRISTINE consortium
  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 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
  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 zoom in zoom in Normal IPC Process (Data Transfer/Control) Error and Flow Control Protocol Relaying and Multiplexing Task SDU Protection SDK support RTT policy Txctrl policy ECN policy . . . SDK support Forwar policy Schedu policy MaxQ 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 PFTgen policy Pushbak notify SDK support Enroll. sequenc e SDK support Routing policyIPC 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 Component Summary of status Management Agent Initial implementation ready: IPCP creation, destruction; assignment to a DIF; triggering of enrollment operation; query RIB Manager Initial 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 Process See 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 component SDK Available policies / comments CACEP Y No 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 N Google Protocol Buffers (GPB) encoding, no support for filter op Enrollment Y Default enrollment policy based on enrollment spec Flow Allocation Y Simple QoS-cube selection policy (just reliable or unreliable) Namespace Mgr. Y Static addressing, fully replicated Directory Forwarding Table Routing Y Link-state routing policy based on IS-IS Res. Allocator Y PDU Fwding table generator policy with input from routing EFCP Y Retx. Control policies, window-based flow control, ECN receiver RMT Y 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 110 VLAN 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 1 System 2 System 3 eth1eth2eth1eth1 • 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”
  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 DIFInteractive 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 Transfer Data 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 StateVector StateVectorStateVector Data TransferData Transfer Retransmission Control Retransmission Control Flow 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 Mgr MA MA MA MA MA MA MA MA
  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 GatewayVIFIB Node TCP or UDP Public Internet (IPv6) Ethernet Gateway VIFIB Node VIFIB Node Ethernet (VLAN) Shim IPC Process Shim IPC Process Public Internet (IPv4) Ethernet Ethernet. . . Ethernet Ethernet. . . Shim IPC Process Shim IPC Process Shim IPC Process IPC Process IPC Process 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
  22. Open source IRATI 22 • IRATI github side • • Hosts code, docs, issues • Installation guide • Experimenters (tutorials) • Developers (software arch) • Mailing list for users and developers • • 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 www <Thank you!>