Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2. RINA overview - TF workshop


Published on

This talk introduces the main concepts to be able to understand RINA, explains its key principles and introduces the architectural problems it addresses.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

2. RINA overview - TF workshop

  1. 1. Large scale RINA Experimentation on FIRE + RINA high-level Overview RINA Workshop @ Telefonica TBD
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  21. 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