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.

Intro RINA

293 views

Published on

Intro to RINA and computer network architecture

Published in: Internet
  • Be the first to comment

Intro RINA

  1. 1. February 7th 2017 RINA Introduction Eduard Grasa
  2. 2. Together we’ll try to make sense of ... • What (computer) network architecture is What is the current one • What are its main flaws • How to construct a better architecture 1 2 3 4 2
  3. 3. WHAT IS A NETWORK ARCHITECTURE? 1 3
  4. 4. What is architecture? • “The style of design and method of construction of buildings and other physical structures” • Architecture provides a set of patterns and methodology that guides building designers in carrying out their task • The same architecture is used to design many different buildings with different requirements – Architecture captures the rules and patterns that are invariant with respect to the specific requirements of each building 4
  5. 5. Elements of the gothic architecture Grand, Tall Designs, Which Swept Upwards With Height and Grace These flying buttresses are a feature of gothic architecture. The Pointed Arch The Vaulted Ceiling Light, Airy Interiors The Emphasis Upon the Decorative Style and the Ornate 5
  6. 6. Buildings of gothic architecture City Hall Palace Cathedral Fish market City gates 6
  7. 7. Elements of the modernist architecture The catalan vault Use of iron Use of bricks Assymetric forms Curvy lines Nature as source of inspiration7
  8. 8. Buildings of modernist architecture Houses Hotels Cathedrals Parks Music Halls 8
  9. 9. What is architecture? • Architecture provides a set of patterns and methodology that guides building designers in carrying out their task • Architecture captures the rules and patterns that are invariant with respect to the specific requirements of each building 9
  10. 10. What is computer networking? • Who are the “users” of networking services? – (or what are the “endpoints” of communication”) • What service is networking providing? – Imperfect remote data replication a.k.a communication services Applications! Ok, if you really want to be precise about it : instances of OS processes or equivalents Perfect would mean 0 packet loss, 0 delay, ∞ capacity Network are just large data copying machines 10
  11. 11. So, computer networks are … • Computer networking is Inter Process Communication (IPC) – Robert Metcalfe, inventor of Ethernet, 1972 Machine 1 Machine 2 “The network” A distributed, imperfect machine that copies data between instances of applications, introducing loss and delay in the process App A App B “I believe it is natural to think of resources as being associated with processes and available only through communication with these processes. Therefore, I view the fundamental problem of resource sharing to be the problem of interprocess communication. I also share with Carr, Crocker, and Cerf the view that interprocess communication over a network is a subcase of general interprocess communication in a multi-programmed environment” D.C. Walden, ARPANET design team, 1970 (RFC 62) End-to-end protocols (often called "Host- Host" protocols) are installed on top of the packet switching service to provide users with an interprocess communication facility Cerf, Zimmerman, McKenzie (INWG), 1976 Thus, all communication is viewed as interprocess communication DARPA, RFC 793 (TCP spec), 1981 11
  12. 12. Conclusions on network architecture • Network architecture provides a set of patterns and methodology that guides network (protocol) designers in carrying out their task • Network architecture captures the rules and patterns that are invariant with respect to the specific requirements of each individual network – General rules and patterns to provide distributed IPC services to any application over any physical media Cellular networks Wireless networks Datacentre networks ISP networks 12
  13. 13. WHAT IS THE CURRENT NETWORK ARCHITECTURE? 2 13
  14. 14. WHAT ARE THE MAIN FLAWS3 14
  15. 15. Structure (layering) • Current networks loosely based on the OSI reference model Application Presentation Session Transport Network Physical OSI (Initial) Data Link Application Transport Network LLC Physical OSI (Final) SubNet Indep. C. SubNet Dep. C. SubNet Access Data Link MAC Application Transport LLC Physical Internet (theory) MAC Internet Data Link and others and others For cellular networks In textbooks (and was wrong) Ignored (Supports Internets) Current one (In reality a network model) 15
  16. 16. The “Internet” is not an Internet.. • Internet (theoretical model) • OSI model Host Router Router Border Router Router Router HostBorder Router Physical Physical Physical Physical Physical Physical Physical LLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MAC Internet Transport Network 1 Network 2 Host Router Router Border Router Router Router HostBorder Router Physical Physical Physical Physical Physical Physical Physical LLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MAC Transport Network 1 Network 2 SNAC SNDC SNAC SNDC SNIC Application Application 16
  17. 17. Layering: problems (I) • Internet architecture does not have room for different network protocols (there is a common Internet layer directly over data link layers) • If a network wants to do its own non-IP forwarding, or do IP forwarding but hide internal routers from the Internet, ad-hoc extensions are required: – “Layers 2.5” -> MPLS – Tunnelling protocols -> e.g. GTP for mobile networks, IP-in-IP tunnelling protocols, MAC-in-MAC, etc.. (every SDO designing its ad-hoc solution(s) for its problem domain, independently) • Note that this was already covered in the OSI architecture by SNDC and SNAC 17
  18. 18. Layering: problems (II) • Fixed number of layers, sometimes more needed between transport and application – Need concepts like “overlay”, “VPN”, “virtual networks”, .. • Although the need for scope is clear (link, network, Internet, VPN …) layers are organised as units of modularity, with each layer providing a different function to each other (Theory) (Practice) 18
  19. 19. Layers and protocols • Each layer provides a different function to each other – Multiple protocols within the same layer • Protocols are usually – Independently designed from each other (little commonality) in different SDOs, even within the same SDO – Almost each new use case requires a new protocol 19 • Flaws in the architecture (e.g. multi-homing, mobility) require special protocols
  20. 20. Result: protocol proliferation! 20
  21. 21. Is there any structure? 21 • Each layer performs a number of distributed functions coordinated via network protocols, which can be categorised: – Data transfer (or data plane) functions. The functions that are associated to every single packet (PDU), such as multiplexing, scheduling, forwarding, addressing, concatenation, fragmentation, sequencing, encryption, etc.. – Data transfer control (or also data plane) functions. Feedback functions that are loosely associated to the data transfer ones, such as flow control, congestion control or retransmission control. – Layer management (or control plane) functions. Functions to manage the functioning of a layer, not directly associated to the data of the layer users, such as: authentication, access control, routing, resource allocation, security management.
  22. 22. Complexity is your enemy • Complexity makes all other network problems worst (security, management, etc), makes networks hard (and expensive!) to manage and less reliable. 22
  23. 23. Naming and addressing • Domain names are mapped to IP addresses by DNS • IP addresses are assigned to interfaces • MAC addresses are assigned to interfaces • Transport layers and below know nothing about domain names 23  http://www.i2cat.net Synonym of an interface of a host Port number (Endpoint of TCP connection) :80 App App App name = domain name + port number IP address MAC address IP address MAC address Internet layer routes on IP addresses
  24. 24. Issues: multi-homing 24 AppApp 1.1.1.1 1.2.1.1 2.1.1.1 The network doesn’t know that 1.1.1.1 and 1.2.1.1 actually go to the same place. If one of the two interfaces crashes, packets can’t be re- routed to the other one • A number of special protocols designed to partially deal with it: SHIM6, Multipath TCP, BGP (multi-homing at the AS level), SCTP AppApp 1.1.1.1 2.1.1.1 Solution is trivial: assign addresses to the “node”, not interfaces. Route on node addresses
  25. 25. Issues: mobility (II) • Seamless (application does not notice it) mobility is complicated due to incomplete naming&addressing: – Applications need an identifier that is stable when their host moves across networks – To make routing scale the network addresses need to change as the host attaches to different networks • But in the Internet (layer) there is only one identifier: the IP address – Special protocols to try to make it work: Mobile IP(v4/v6), Proxy Mobile IP (v4/v6), GTP for cellular (create a huge layer 2 subnet), LISP – Most of them require tunnels (expensive to setup), all have limitations at the scale they can provide seamless mobility 25
  26. 26. Application API • Applications must know about transport protocol and choose it • Addresses exposed to applications (security problem) • No way to request QoS parameters (loss, delay, etc..) • Barrier to adoption of new protocols (IETF TAPS tries to address this) 26 Host Transport Host App A App B Application A Sockets API OS Sockets Layer 1. Bind/Listen to interface and port 2. Accept incoming connections 3. Connect to a remote address/port 4. Send datagram 5. Write data (bytes) to socket 6. Read data (bytes) from socket 7. Destroy socket Internet
  27. 27. Summing up • Current network architecture has a flawed … – Structure – Protocol design – Naming and addressing scheme – Service model / Application API – And we didn’t touch security – or network management • But enough complaining! 27
  28. 28. HOW TO CONSTRUCT A BETTER NETWORK ARCHITECTURE 4 28
  29. 29. 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 29 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
  30. 30. 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 30 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
  31. 31. 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) 31 Host DIF Host App A App B RouterRouter
  32. 32. 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? 32 Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF Host App A App B Consistent API through layers
  33. 33. 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 33
  34. 34. Let’s go to our to-do list • We have fixed – Structure – Protocol design – Naming and addressing scheme – Service model / Application API – Security – Network management • Still work to do, let’s move on! 34
  35. 35. 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? 35
  36. 36. 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) 36 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 EFCP App A IPC API IPC Process
  37. 37. Unified layer management 37 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
  38. 38. Let’s go to our to-do list • We have fixed – Structure – Protocol design – Naming and addressing scheme – Service model / Application API – Security – Network management • Still work to do, let’s move on! 39
  39. 39. Naming and addressing, mobility, routing No need for special protocols 40 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)
  40. 40. Implications for multi-homing 41 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)
  41. 41. Security: DIFs are securable containers Secure layers instead of protocols, expose less to apps, scope 42 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
  42. 42. Network management Commonality is the key to effective network management 43 • 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
  43. 43. Let’s go to our to-do list • We have fixed – Structure – Protocol design – Naming and addressing scheme – Service model / Application API – Security – Network management 44
  44. 44. Summing up.. RINA is not a protocol! 45 • 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
  45. 45. Examples: RINA in a PBB-VPLS style config • RINA recursive layering structure cleans up and generalizes the current protocol stack. • Example 1: PBB-VPLS (Virtual Private LAN Service) – Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs 46
  46. 46. Examples: RINA in a PBB-VPLS style config • RINA recursive layering structure cleans up and generalizes the current protocol stack. • Example 1: PBB-VPLS (Virtual Private LAN Service) – Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs 47 PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
  47. 47. Examples: RINA in a PBB-VPLS style config • RINA recursive layering structure cleans up and generalizes the current protocol stack. • Example 1: PBB-VPLS (Virtual Private LAN Service) – Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs 48 Metro DIF Metro DIFCore DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
  48. 48. Examples: RINA in a PBB-VPLS style config • RINA recursive layering structure cleans up and generalizes the current protocol stack. • Example 1: PBB-VPLS (Virtual Private LAN Service) – Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs 49 Provider VPN Service DIF Metro DIF Metro DIFCore DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
  49. 49. Examples: RINA in a PBB-VPLS style config • RINA recursive layering structure cleans up and generalizes the current protocol stack. • Example 1: PBB-VPLS (Virtual Private LAN Service) – Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs 50 Green Customer VPN DIF Provider VPN Service DIF Metro DIF Metro DIFCore DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
  50. 50. Examples: RINA in a LTE style config • Example 2: LTE (Long Term Evolution) – Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. 51 IP (e.g. Internet) TCP or UDP PDCP GTP-U Protocol conversion GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi
  51. 51. Examples: RINA in a LTE style config • Example 2: LTE (Long Term Evolution) – Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. 52 IP (e.g. Internet) TCP or UDP PDCP GTP-U Protocol conversion GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Multi-access radio DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF
  52. 52. Examples: RINA in a LTE style config • Example 2: LTE (Long Term Evolution) – Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. 53 IP (e.g. Internet) TCP or UDP PDCP GTP-U Protocol conversion GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Multi-access radio DIF Mobile Operator Transport DIF Mobile Operator Transport DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF
  53. 53. Examples: RINA in a LTE style config • Example 2: LTE (Long Term Evolution) – Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. 54 IP (e.g. Internet) TCP or UDP PDCP GTP-U Protocol conversion GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Mobile Access Network Top Level DIF Multi-access radio DIF Mobile Operator Transport DIF Mobile Operator Transport DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF
  54. 54. Examples: RINA in a LTE style config • Example 2: LTE (Long Term Evolution) – Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. 55 IP (e.g. Internet) TCP or UDP PDCP GTP-U Protocol conversion GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Public Internet DIF Mobile Access Network Top Level DIF Multi-access radio DIF Mobile Operator Transport DIF Mobile Operator Transport DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF
  55. 55. Examples: RINA in a Virt. DC style config • Example 3: Data Center Network with NVO3 – Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to support multi-tenancy • Recursion provides a cleaner, simpler solution than virtualization – Repeat the same building block, with the same interface. 56 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
  56. 56. Examples: RINA in a Virt. DC style config • Example 3: Data Center Network with NVO3 – Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to support multi-tenancy • Recursion provides a cleaner, simpler solution than virtualization – Repeat the same building block, with the same interface. 57 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 PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIF
  57. 57. Examples: RINA in a Virt. DC style config • Example 3: Data Center Network with NVO3 – Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to support multi-tenancy • Recursion provides a cleaner, simpler solution than virtualization – Repeat the same building block, with the same interface. 58 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 PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIF DC Fabric DIF
  58. 58. Examples: RINA in a Virt. DC style config • Example 3: Data Center Network with NVO3 – Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to support multi-tenancy • Recursion provides a cleaner, simpler solution than virtualization – Repeat the same building block, with the same interface. 59 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 PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIF DC Fabric DIF Tenant DIF
  59. 59. AND HOW DO YOU PRETEND TO DEPLOY THIS STUFF? 5 60
  60. 60. 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 61
  61. 61. IF IT IS SO NICE.. WHY IS NOT ALREADY OUT THERE?6 62
  62. 62. • … 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 1 2 3 4 5 1 2 3 4 5 63
  63. 63. Some decisions and tradeoffs 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 64
  64. 64. High-level software arch. 65
  65. 65. Thanks for your patience! • Current research projects – FP7 PRISTINE (2014-2016) http://ict-pristine-eu – H2020 ARCFIRE (2016-2018) 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 66
  66. 66. IRATI Demo • Datacentre configuration, using demonstrator • 107 VMs, leaf-spine “topology”, each ToR has 12 Machines, each ToR conncted to 3 spines • 8 VPN DIFs “floating” on top of the DC Fabric DIF DC Fabric DIF One of the 8 VPN DIFs 67

×