SlideShare a Scribd company logo

Pristine rina-tnc-2016

•Download as PPTX, PDF•
•
A
ARCFIRE ICT

This document summarizes how the Recursive InterNetwork Architecture (RINA) approach simplifies multi-layer network management compared to the traditional IP approach. RINA uses a single, consistent layer type and management protocol (CDAP) across all layers, reducing complexity compared to IP which has unique layer types and protocols. This common structure in RINA simplifies management models and enables greater automation of multi-layer networks. The document provides examples comparing IP and RINA models for data center fabric management and tenant network management.

Related slideshows

3. RINA use cases, results, benefits
3. RINA use cases, results, benefits3. RINA use cases, results, benefits
3. RINA use cases, results, benefits
 
Vsat day-2008-comtech
Vsat day-2008-comtechVsat day-2008-comtech
Vsat day-2008-comtech
 
Arcfire fire forum 2015
Arcfire fire forum 2015Arcfire fire forum 2015
Arcfire fire forum 2015
 
1 of 19
Simplifying Multi-layer Network Management with RINA Simplifying multi-layer network management with RINA Eduard Grasa, Fundació i2CAT, FP7 PRISTINE TNC 2016, Prague, June 13th 2016
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)
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 RINA 3 1 2 1 42
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
RINA macro-structure (layers) Single type of layer, consistent API, programmable policies Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF (Distributed IPC Facility) Host App A App B Consistent API through layers 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 StateVector StateVector Data TransferData Transfer Retransmission Control Retransmission Control Flow Control Flow Control Increasing timescale (functions performed less often) and complexity Namespace Management Security Management
“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
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
Separation of mechanism from policy 8 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 StateVector StateVector Data TransferData Transfer Retransmission Control Retransmission Control Flow 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
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
IP-based DCN design (With minimal number of protocols) • Data plane (up), control plane (down). L3-only fabric 10 ToR ToRFabric Spine Fabric Server ServerIPv4 or IPv6 (Fabric layer) UDPVM VM Ethernet Ethernet Ethernet Ethernet VXLAN802.1Q802.3 802.1Q IPv4 or IPv6 (tenant overlay) TCP or UDP or SCTP, … (transport layer) 802.3 Protocol conversion, Local bridging ToR ToRFabric Spine FabricServer Server IPv4 or IPv6 (Fabric layer) TCP Ethernet Ethernet Ethernet Ethernet LACP Ethernet LACP Ethernet TCP eBGP eBGP TCP TCP eBGP eBGP TCP eBGP TCP eBGP
RINA-based DCN design • Overall design (up), Fabric addressing plan (down) Simplifying multi-layer network management with RINA 11 PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIF DC Fabric DIF Tenant DIF ToR ToR VM Server Server VM FabricFabric Spine
Models for the DCN fabric: IP vs RINA Assumption (for IP): all nodes NETCONF/YANG capable Simplifying multi-layer network management with RINA 12 Concept IP RINA 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 entity Router, 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 strategy Longest prefix matching, ECMP Longest prefix matching, ECMP Scheduling strategy FIFO (needs max-queue size) FIFO (needs max-queue size) Routing protocol BGP 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 protocol NETCONF CDAP Mgmt models yang-common-types, yang-interfaces, yang- ip, yang-routing , yang-bgp daf-common-mom, dif-common-mom, dif-default-policies
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 RINA 13
Models for the tenant layers: IP vs RINA (I) Assumption (for IP): all nodes NETCONF/YANG capable Simplifying multi-layer network management with RINA 14 Concept IP RINA 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 entity router: 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 strategy Exact (MAC) address matching Longest prefix matching, ECMP (load- balancing/redundancy at server level) Scheduling strategy FIFO (needs max-queue size) FIFO (needs max-queue size)
Models for the tenant layers: IP vs RINA (II) Assumption (for IP): all nodes NETCONF/YANG capable Simplifying multi-layer network management with RINA 15 Concept IP RINA Routing protocol BGP with multi-protocol extensions. Needs route distinguisher and VPN targets CDAP with link-state routing policy and topological addressing Directory protocol DNS (resolve domain names of apps executing in the tenant DIF to IP @s) CDAP with distributed directory policy. Maintains Directory Forwarding Table Redundancy protocol Link Aggregation Control Protocol – needs local Ethernet interface addresses - Mgmt protocol NETCONF CDAP Mgmt models yang-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 types 4 1 DT protocol syntaxes 5 1 (2 different field lengths) Types of forwarding entities 3 1 Layer mgmt/control plane protocols 3 1 (with 4 policies)
NMS-DAF: Manager design Simplifying multi-layer network management with RINA 16 Manager Mgmt Agent (MA) CDAP Connect Managed Resource (RINA System) API Calls, etc. CDAP Manager App Manager App Manager App Messaging System Mgmt Shell / GUI Mgmt Shell / GUI Mgmt Shell / GUI Other Apps Other Apps Other Apps Mgmt Agent (MA) Managed Resource (RINA System) API Calls, etc. Mgmt Agent (MA) Managed Resource (RINA System) API Calls, etc. CDAP CDAP NMS-DAF • Event-source, distributed and modular design, layered design, distributed configuration management, Java 8 Messaging: W3C Websockets Agent Connection: CDAP connector
Demo: multi-tenant capable DCN (I)
Demo: multi-tenant capable DCN (II) Simplifying multi-layer network management with RINA 18 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.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)
Research, open source, standards 19 • Current research projects – FP7 PRISTINE (2014-2016) http://ict-pristine-eu – H2020 ARCFIRE (2016-2017) http://ict-arcfire.eu – Norwegian project OCARINA(2016-2021) – BU RINA team http://csr.bu.edu/rina • Open source implementations – IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over X) http://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.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

More Related Content

Pristine rina-tnc-2016

  • 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 13th 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 RINA 3 1 2 1 42
  • 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 router Interior Router DIF DIF DIF Border router DIF DIF DIF (Distributed IPC Facility) Host App A App B Consistent API through layers 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 StateVector StateVector Data TransferData Transfer Retransmission Control Retransmission Control Flow 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 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 StateVector StateVector Data TransferData Transfer Retransmission Control Retransmission Control Flow 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 ToRFabric Spine Fabric Server ServerIPv4 or IPv6 (Fabric layer) UDPVM VM Ethernet Ethernet Ethernet Ethernet VXLAN802.1Q802.3 802.1Q IPv4 or IPv6 (tenant overlay) TCP or UDP or SCTP, … (transport layer) 802.3 Protocol conversion, Local bridging ToR ToRFabric Spine FabricServer Server IPv4 or IPv6 (Fabric layer) TCP Ethernet Ethernet Ethernet Ethernet LACP Ethernet LACP Ethernet TCP eBGP eBGP TCP TCP eBGP eBGP TCP eBGP TCP eBGP
  • 11. RINA-based DCN design • Overall design (up), Fabric addressing plan (down) Simplifying multi-layer network management with RINA 11 PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIF DC Fabric DIF Tenant DIF ToR ToR VM Server Server VM FabricFabric Spine
  • 12. Models for the DCN fabric: IP vs RINA Assumption (for IP): all nodes NETCONF/YANG capable Simplifying multi-layer network management with RINA 12 Concept IP RINA 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 entity Router, 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 strategy Longest prefix matching, ECMP Longest prefix matching, ECMP Scheduling strategy FIFO (needs max-queue size) FIFO (needs max-queue size) Routing protocol BGP 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 protocol NETCONF CDAP Mgmt models yang-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 RINA 13
  • 14. Models for the tenant layers: IP vs RINA (I) Assumption (for IP): all nodes NETCONF/YANG capable Simplifying multi-layer network management with RINA 14 Concept IP RINA 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 entity router: 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 strategy Exact (MAC) address matching Longest prefix matching, ECMP (load- balancing/redundancy at server level) Scheduling strategy FIFO (needs max-queue size) 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 RINA 15 Concept IP RINA Routing protocol BGP with multi-protocol extensions. Needs route distinguisher and VPN targets CDAP with link-state routing policy and topological addressing Directory protocol DNS (resolve domain names of apps executing in the tenant DIF to IP @s) CDAP with distributed directory policy. Maintains Directory Forwarding Table Redundancy protocol Link Aggregation Control Protocol – needs local Ethernet interface addresses - Mgmt protocol NETCONF CDAP Mgmt models yang-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 types 4 1 DT protocol syntaxes 5 1 (2 different field lengths) Types of forwarding entities 3 1 Layer mgmt/control plane protocols 3 1 (with 4 policies)
  • 16. NMS-DAF: Manager design Simplifying multi-layer network management with RINA 16 Manager Mgmt Agent (MA) CDAP Connect Managed Resource (RINA System) API Calls, etc. CDAP Manager App Manager App Manager App Messaging System Mgmt Shell / GUI Mgmt Shell / GUI Mgmt Shell / GUI Other Apps Other Apps Other Apps Mgmt Agent (MA) Managed Resource (RINA System) API Calls, etc. Mgmt Agent (MA) Managed Resource (RINA System) API Calls, etc. CDAP CDAP NMS-DAF • Event-source, distributed and modular design, layered design, distributed configuration management, Java 8 Messaging: W3C Websockets Agent Connection: CDAP connector
  • 18. Demo: multi-tenant capable DCN (II) Simplifying multi-layer network management with RINA 18 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.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-eu – H2020 ARCFIRE (2016-2017) http://ict-arcfire.eu – Norwegian project OCARINA(2016-2021) – BU RINA team http://csr.bu.edu/rina • Open source implementations – IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over X) http://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.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

Editor's Notes

  1. Layers are resource allocators, provide IPC services over a certain scope, they all have the same functions
  2. - Complexity, complexity, complexity (unbounded, nobody knows what new combinations of layers may be needed in the future
  3. Core/backbone: IP/MPLS Metro aggregation: Carrier Ethernet Access: xDSL, FTTH (PON tech), WiFI, LTE Services: L2/L3 VPNs, Internet access, IMS Micro DC: C-RAN, Mobile Edge computing Metro/regional/national DCs: provider service platforms (DNS, SMTP, etc…) LTE EPC (S-GW and/or P-GW, MME), IMS, cloud hosting, NOC, etc
  4. Core/backbone: IP/MPLS Metro aggregation: Carrier Ethernet Access: xDSL, FTTH (PON tech), WiFI, LTE Services: L2/L3 VPNs, Internet access, IMS Micro DC: C-RAN, Mobile Edge computing Metro/regional/national DCs: provider service platforms (DNS, SMTP, etc…) LTE EPC (S-GW and/or P-GW, MME), IMS, cloud hosting, NOC, etc