2. RINA overview - TF workshop
- 1. Large scale RINA Experimentation on FIRE + RINA high-level Overview RINA Workshop @ Telefonica TBD
- 2. HOW TO CONSTRUCT A BETTER NETWORK ARCHITECTURE 4 2
- 3. So.. What do we want? β’ As much invariants as possible in the architecture, so that we can minimize the number of protocols and maximize their commonality 3 Architecture: patterns, invariants, building blocks, methods Protocols Today: β’ Architecture has too little patterns/commonality, and they are a bit broken β’ Too many protocols, too little commonality Architecture: patterns, invariants, building blocks, methods What we want: β’ Architecture provides as much invariants as possible β’ Few protocols, sharing lots of commonalityProtocols
- 4. Application API: IPC services β’ Application names are location independent (the network locates the apps); addresses internal to the network β’ Application provides service requirements for their flows (loss, delay, etc.), the network chooses the right protocols to provide them 4 Host Host App A App B App A IPC API OS IPC 1. Register/Unregister App 2. Allocate/Deallocate flows 3. Write data (SDUs) to flows 4. Read data (SDUs) from flows The network locates the destination application (directory), and configures protocols for each flow βThe networkβ provides communication flows
- 5. What is the nework? β’ Provides IPC services, but what is it? Some hints: β Executes in computers running operating systems (PCs, laptops, routers, sensors, smartphones, tables, switches, etc.) β Has instances distributed through many machines, exchanging information and collaborating β Just likeβ¦ the web, Skype, email, etc. β’ Therefore the network is just a distributed application specialised to provide IPC β Weβll call this application a DIF (Distributed IPC Facility) 5 Host DIF Host App A App B RouterRouter
- 6. Structure: layering (I) β’ But a single DIF for all applications and all machines in the world/universe is not very scalable ... β We need to isolate scopes (link, network, Internet, VPN, etc.) β’ Multiple DIFs, providing IPC services to each other! β After all a DIF is just a distributed application, right? 6 Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF Host App A App B Consistent API through layers
- 7. Layering, a better pattern (II) β’ Single type of layer, providing an IPC Service that repeats as many times as needed by the network designer β’ A layer is a resource allocator that provides an manages the IPC service over a given scope (link, network, Internet, VPN, etc.). A layer allocates resources (memory in buffers, scheduling capacity, bandwidth) to competing flows. Host Router Router Border Router Router Router HostBorder Router Network 2 SNAC SNDC SNIC Application DIF DIF DIF DIF DIF DIFDIF DIF DIF DIF 7 Network 1
- 8. Letβs go to our to-do list β’ We have improved β Structure β Protocol design β Naming and addressing scheme β Service model / Application API β Security β Network management β’ Still work to do, letβs move on! 8
- 9. What protocols inside a DIF? β’ A DIF is a distributed application, how can we organise its functions? β Remember: data transfer, data transfer control, layer management β’ But we want to limit the variability in protocols to the minimum: apply separation of mechanism and policy β Mechanism are the parts in a protocol that are fixed (e.g. an acknowledgement ACK) β Policy is the part of the protocol that can change (e.g. when to send an ACK is policy) β’ Each DIF has different requirements, so we cannot have the same protocols in all of them, but can we abstract invariances so that we end up with: β 1 protocol (framework) for data transfer? β 1 protocol (framework) for layer management? 9
- 10. EFCP: Error and Flow Control Protocol β’ By separating data transfer protocol elements between mechanism (invariant) and policy (variant), it is possible to specify a data transfer protocol framework from which multiple data transfer protocols can be generated by β Choosing a concrete syntax (length of header fields) β Plugging in the right policies (for flow control, retx. control, congestion contol) 10 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 ControlRetransmission Control Flow Control Flow Control Namespace Management Security ManagementEFCP App A IPC API IPC Process
- 11. Unified layer management 11 Resource Information Base (RIB): Schema that defines the external representation of the set of objects that model the state of the IPCP (object names, attributes, relationships, allowed CDAP operations and their effects) Common Distributed Application Protocol (CDAP): Application protocol that allows two applications to operate on the objects of each otherβs RIB. Provides 6 operations (create/delete/read/write/start/stop). RIB Daemon: Entity that processes incoming CDAP messages (delegating RIB operations to layer mgmt tasks) and generates outgoing CDAP messages from layer management tasksβ requests
- 12. Benefits of unified layer management framework β’ Only need one common layer management protocol for all layers, which allows layer management functions to remotely operate on objects (which model the functionβs externally visible state) β’ Only need one common distributed memory/database manager for layer management functions β With pluggable replication policies (on demand, event-based, periodic, etc..) β’ Layer management functions just need to specify an object schema, and the behaviour when the common protocol operations are invoked on the objects β’ This is a huge reduction in network complexity, coming from a world were every single layer management/control plane function has one or more standalone protocols, independently designed (ICMP, RSVP, OSPF, RIP, BGP, IS-IS, ARP, DNS, etc..) 12
- 13. Letβs go to our to-do list β’ We have improved β Structure β Protocol design β Naming and addressing scheme β Service model / Application API β Security β Network management β’ Still work to do, letβs move on! 13
- 14. Naming and addressing, mobility, routing No need for special protocols 14 Name Indicates Property RINA IP Application name What Location independent Yes No Node address Where Location dependent, route independent Yes No Point of Attachment How to get there Route dependent Yes Yes (twice: IP, MAC)
- 15. Implications for multi-homing 15 G A B C E D F H 1 2 6 5 8 3 14 18 17 16 15 19 21 13 20 9 11 10 12 4 7 2 2 G A B C E D F H 1 2 3 1 2 1 3 4 1 2 3 1 2 3 1 2 3 1 1 2 2 2 β’ Addressing the node instead of the interface: 3-4x time routing/forwarding table reduction! β’ No need for special protocols to support multi- homing Addresses assigned to interfaces (like in IP) Addresses assigned to nodes (like in RINA)
- 16. Security: DIFs are securable containers Secure layers instead of protocols, expose less to apps, scope 16 Allocating a flow to destination application Access control Sending/receiving SDUs through N-1 DIF Confidentiality, integrity N DIF N-1 DIF IPC Process IPC Process IPC Process IPC Process Joining a DIF authentication, access control Sending/receiving SDUs through N-1 DIF Confidentiality, integrity Allocating a flow to destination application Access control IPC Process Appl. Process DIF Operation Logging/Auditing DIF Operation Logging/Auditing RINA IP protocol suite Consistent security model, enforced by each layer via pluggable policies Each protocol has its own security model/functions (IPsec, TLS, BGPsec, DNSsec, etc.) Scope as a native construct: controlled connectivity by default Single scope (global), connectivity to everyone by default. Scope via ad-hoc means: firewalls, ACLs, VLANs, VPNs, etc. Complete naming and addressing, separation of synchronization from port allocation No application names, addresses exposed to applications, well- known ports
- 17. Network management Commonality is the key to effective network management 17 β’ 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 RINA Introduction
- 18. Letβs go to our to-do list β’ We have improved β Structure β Protocol design β Naming and addressing scheme β Service model / Application API β Security β Network management β’ And made Homer happy! 18
- 19. Summing up.. RINA is not a protocol! 19 β’ 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 (DIF!) β’ 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 1 2 3 4 5 6
- 20. AND HOW DO YOU PRETEND TO DEPLOY THIS STUFF? 5 20
- 21. Incremental deployment β’ IPv6 brings very small improvements to IPv4, but requires a clean slate deployment (not compatible to IPv4) β’ RINA can be deployed incrementally where it has the right incentives, and interoperate with current technologies (IP, Ethernet, MPLS, etc.) β Over IP (just like any overlay such as VXLAN, NVGRE, GTP-U, etc.) β Below IP (just like any underlay such as MPLS or MAC-in-MAC) β Next to IP (gateways/protocol translation such as IPv6) IP Network RINA Provider RINA Network Sockets ApplicationsRINA supported Applications IP or Ethernet or MPLS, etc 21
Editor's Notes
- #9: Number and scope of layers is not decided by architecture but by the network designer: use the best number for each building Invariant structure with respect to the type of network being designed: the repeating building block with a consistent service interface (IPC) helps network designers to bound structural complexity We still face the problem of what is the internal structure of such a generic IPC layer? How many protocols? How do they look like? Are there invariants we can extract to further simplify and streamline the process of network design?
- #11: Reduce the number of data transfer protocols to a few (maybe 10 or so?), all sharing the same abstract syntax and the same mechanisms Much easier to specify, implement and debug Networks become much easier to understand, manage and troubleshoot -> cheaper to operate and more reliable Innovation becomes much easier -> donβt need to design and implement full-fledged protocols, just new policies E.g. almost all TCP variants are just a little change in the congestion control policy We can share some work done on PRISTINE to understand what it means to specify/develop this data transfer policies
- #14: Number and scope of layers is not decided by architecture but by the network designer: use the best number for each building Invariant structure with respect to the type of network being designed: the repeating building block with a consistent service interface (IPC) helps network designers to bound structural complexity We still face the problem of what is the internal structure of such a generic IPC layer? How many protocols? How do they look like? Are there invariants we can extract to further simplify and streamline the process of network design?
- #18: 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
- #19: Number and scope of layers is not decided by architecture but by the network designer: use the best number for each building Invariant structure with respect to the type of network being designed: the repeating building block with a consistent service interface (IPC) helps network designers to bound structural complexity We still face the problem of what is the internal structure of such a generic IPC layer? How many protocols? How do they look like? Are there invariants we can extract to further simplify and streamline the process of network design?
- #22: 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