1. Simplifying Multi-layer Network Management with RINA Simplifying multi-layer network management with RINA Eduard Grasa, Fundació i2CAT, FP7 PRISTINE TNC 2016, Prague, June 13 th 2016

2. Computer network being managed Events Reason about events Layers state models Compare with desired state Updated network state Desired network state Reason about config changes Network state drift Layers config models Apply updated config Network Management System 2 Automating network management … Complexity of management models key metric to evaluate the limitations/possibilities on network automation (and its cost)

3. Are “All IP networks” easy to automate? Computer networking & telecom industry has been steadily moving towards an “all IP” world. – Is “ all-IP convergence ” a simple, scalable, robust, manageable, performing and future-proof solution for all types of computer networks ? Could be if – The “IP protocol suite” had been designed with generality in mind, allowing its protocols to adapt to specific network environments – The “IP protocol suite” is well know for having no scalability, performance or security issues Simplifying multi-layer network management with RINA3 1 2 1 4 2

4. There is a better approach: RINA Network architecture resulting from a fundamental theory of computer networking Networking is InterProcess Communication (IPC) and only IPC. Unifies networking and distributed computing: the network is a distributed application that provides IPC There is a single type of layer with programmable functions, that repeats as many times as needed by the network designers All layers provide the same service: instances or communication (flows) to two or more application instances, with certain characteristics (delay, loss, in-order-delivery, etc) There are only 3 types of systems: hosts, interior and border routers. No middleboxes (firewalls, NATs, etc) are needed Deploy it over, under and next to current networking technologies 4 1 2 3 4 5 6 Simplifying multi-layer network management with RINA

5. RINA macro-structure (layers) Single type of layer, consistent API, programmable policies Host Border routerInterior Router DIF Border router DIF DIF (Distributed IPC Facility) Host App A App B Consistent API through layers 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

6. “IP protocol suite” macro-structure Functional layers organized for modularity, each layer provides a different service to each other – As the RM is applied to the real world, it proofs to be incomplete. As a consequence, new layers are patched into the reference model as needed (layers 2.5, VLANs, VPNs, virtual network overlays, tunnels, MAC-in-MAC, etc.) 6 (Theory) (Practice) Simplifying multi-layer network management with RINA

7. Network management Commonality is the key to effective network management 7 Commonality and consistency in RINA greatly simplifies management models, opening the door to increased automation in multi-layer networks – Reduce opex, network downtime, speed-up network service delivery, reduce components that need to be standardised From managing a set of layers, each with its own protocols, concepts and definitions … … to managing a common, repeating structure of two protocols and different policies Simplifying multi-layer network management with RINA

8. Separation of mechanism from policy 8 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 Namespace Management Security Management All layers have the same mechanisms and 2 protocols ( EFCP for data transfer, CDAP for layer management), programmable via policies. – All data transfer and layer management functions are programmable! Don’t specify/implement protocols, only policies – Re-use common layer structure, re-use policies across layers This approach greatly simplifies the network structure, minimizing the management overhead and the cost of supporting new requirements, new physical media or new applications

9. Case study: Large-scale DC Network Large-scale DCN connects around 100k servers, how to realize and manage the DCN with RINA and IP? Simplifying multi-layer network management with RINA 9

10. IP-based DCN design (With minimal number of protocols) Data plane (up), control plane (down). L3-only fabric 10 ToR FabricSpine Fabric Server IPv4 or IPv6 (Fabric layer) UDP VM Ethernet VXLAN 802.1Q 802.3 802.1Q IPv4 or IPv6 (tenant overlay) TCP or UDP or SCTP, … (transport layer) 802.3 Protocol conversion, Local bridging ToR FabricSpine Fabric Server IPv4 or IPv6 (Fabric layer) TCP Ethernet LACP Ethernet LACP Ethernet TCP eBGP TCP eBGP TCP eBGP TCP eBGP

11. RINA-based DCN design Overall design (up), Fabric addressing plan (down) Simplifying multi-layer network management with RINA11 PtP DIF DC Fabric DIF Tenant DIF ToR VM Server VM Fabric Spine

12. Models for the DCN fabric: IP vs RINA Assumption (for IP): all nodes NETCONF/YANG capable Simplifying multi-layer network management with RINA12 ConceptIPRINA Interfaces IPv4 interfaces, need IP address (one per interface), unique in the layer. Port-ids to N-1 flows, just need port-id (locally –device- unique identifier) Data Transfer protocol syntax IPv4 syntax, TCP syntax (TCP is used by the control plane) EFCP (length of fields). Need address (one per device in the layer), unique in the layer Forwarding entityRouter, one per device in the layer, has FIB entries (forwarding table) Relaying and Multiplexing Task (RMT), one per device in the layer, has forwarding table entries. Forwarding strategyLongest prefix matching, ECMP Scheduling strategy FIFO (needs max-queue size) Routing protocolBGP with different routing policies. Needs AS numbers, router-id (IP address), neighbours’ IP addresses and AS numbers. CDAP with link-state routing policy and topological addressing Directory protocol-CDAP with centralized directory policy. Mgmt protocolNETCONFCDAP Mgmt modelsyang-common-types, yang-interfaces, yang- ip, yang-routing, yang-bgp daf-common-mom, dif-common-mom, dif-default-policies

13. Configuration overhead: # of addresses in the DCN fabric IP. 2*number of interfaces in the DCN fabric (MAC @, IP @) RINA. 1*number of devices in the DCN fabric (IPCP @) Simplifying multi-layer network management with RINA13

14. Models for the tenant layers: IP vs RINA (I) Assumption (for IP): all nodes NETCONF/YANG capable Simplifying multi-layer network management with RINA14 ConceptIPRINA Interfaces Ethernet interfaces: need MAC address (one per interface) 802.1q interfaces: need VLAN-id VTEP interfaces: need VXLAN-id, local IP address and UDP port, remote IP address and UDP port IPv4 interfaces: need IP address (one per interface), unique in tenant overlay Port-ids to N-1 flows, just need port-id (locally –device- unique identifier) Data Transfer protocol syntax IEEE 802.3 (Ethernet), IEEE 802.1q, IPv4, UDP, VXLAN, TCP EFCP (length of fields). Need address (one per device in the layer), unique in the layer Forwarding entityrouter: one per VM Ethernet bridge: one per server per tenant overlay E-VRF: one per ToR per tenant overlay Relaying and Multiplexing Task (RMT), one per device in the layer, has forwarding table entries. Forwarding strategyExact (MAC) address matchingLongest prefix matching, ECMP (load- balancing/redundancy at server level) Scheduling strategy FIFO (needs max-queue size)

15. Models for the tenant layers: IP vs RINA (II) Assumption (for IP): all nodes NETCONF/YANG capable Simplifying multi-layer network management with RINA15 ConceptIPRINA Routing protocolBGP with multi-protocol extensions. Needs route distinguisher and VPN targets CDAP with link-state routing policy and topological addressing Directory protocolDNS (resolve domain names of apps executing in the tenant DIF to IP @s) CDAP with distributed directory policy. Maintains Directory Forwarding Table Redundancy protocolLink Aggregation Control Protocol – needs local Ethernet interface addresses - Mgmt protocolNETCONFCDAP Mgmt modelsyang-common-types, yang-interfaces, yang- ip, yang-bridging, yang-routing, yang-bgp, yang-vxlan, yang-evpn, yang-lacp daf-common-mom, dif-common-mom, dif-default-policies Concept# (IP)# (RINA) Interface types41 DT protocol syntaxes51 (2 different field lengths) Types of forwarding entities31 Layer mgmt/control plane protocols31 (with 4 policies)

16. NMS-DAF: Manager design Simplifying multi-layer network management with RINA16 Manager Mgmt Agent (MA) Mgmt Agent (MA) CDAP Connect CDAP Connect Managed Resource (RINA System) Managed Resource (RINA System) API Calls, etc. CDAP Manager App Manager App Manager App Manager App Manager App Manager App Messaging System Messaging System Mgmt Shell / GUI Mgmt Shell / GUI Mgmt Shell / GUI Mgmt Shell / GUI Mgmt Shell / GUI Mgmt Shell / GUI Other Apps Other Apps Other Apps Other Apps Other Apps Other Apps Mgmt Agent (MA) Mgmt Agent (MA) Managed Resource (RINA System) Managed Resource (RINA System) API Calls, etc. Mgmt Agent (MA) Mgmt Agent (MA) Managed Resource (RINA System) Managed Resource (RINA System) API Calls, etc. CDAP NMS-DAF Event-source, distributed and modular design, layered design, distributed configuration management, Java 8 Messaging: W3C Websockets Agent Connection: CDAP connector

17. Demo: multi-tenant capable DCN (I)

18. Demo: multi-tenant capable DCN (II) Simplifying multi-layer network management with RINA18 M6 (Server 5) Fabric.DIF M11 (Spine 2) M12 (Border 1) M8 (Leaf 1) Shim Eth DCAccess.DIF Client 1 VPN 1 Shim TCP UDP VPN1.DIF TCP or UDP IPv4 (public Internet) IEEE 802.3 IEEE 802.1q Shim Eth IEEE 802.1q Shim Eth IEEE 802.1q M7 (Server 6) Fabric.DIF M11 (Spine 2) M9 (Leaf 2) M8 (Leaf 1) Shim Eth VPN3.DIF IEEE 802.1q Shim Eth IEEE 802.1q Shim Eth IEEE 802.1q Shim Eth IEEE 802.1q M2 (Server 1)

19. Research, open source, standards 19 Current research projects – FP7 PRISTINE (2014-2016) http://ict-pristine-euhttp://ict-pristine-eu – H2020 ARCFIRE (2016-2017) http://ict-arcfire.euhttp://ict-arcfire.eu – Norwegian project OCARINA(2016-2021) – BU RINA team http://csr.bu.edu/rinahttp://csr.bu.edu/rina Open source implementations – IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over X) http://github.com/irati/stackhttp://github.com/irati/stack – RINASim (RINA simulator, OMNeT++) – ProtoRINA (Java, RINA over UDP, quick prototyping) Key RINA standardization activities – Pouzin Society (experimental specs) http://pouzinsociety.orghttp://pouzinsociety.org – ISO SC6 WG7 (2 new projects: Future Network – Architectures, Future Network- Protocols) – ETSI Next Generation Protocols ISG 1 2 3 4 1 2 3 1 2 3 Simplifying multi-layer network management with RINA