Anúncio

The hague rina-workshop-intro-eduard

Research RINA em FP7 project
25 de Oct de 2016
Anúncio

Mais conteúdo relacionado

Similar a The hague rina-workshop-intro-eduard(20)

Anúncio
Anúncio

The hague rina-workshop-intro-eduard

  1. RINA Introduction RINA Introduction Eduard Grasa, FP7 PRISTINE SDN World Congress 2016, The Hague, October 2016
  2. We have a structural problem in networking… • Functional layers organized for modularity, each layer provides a different service to each other – As the Reference Model is applied to the real world, it proofs to be incomplete. New layers and protocols are patched into the reference model as needed (layers 2.5, VLANs, VPNs, virtual network overlays, tunnels, MAC-in-MAC, etc.) 2 (Theory) (Practice) RINA Introduction
  3. … but instead of facing it we keep patching • Every new requirement / use case usually triggers the development of new protocols – Never refactor, we keep accumulating “technical debt” RINA Introduction 3 RINA Introduction
  4. Let’s fix the structural flaws! Meet 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 RINA Introduction
  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 RINA Introduction 5
  6. Separation of mechanism from policy 6 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 RINA Introduction
  7. Naming and addressing, mobility, routing No need for special protocols RINA Introduction 7 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)
  8. Security: DIFs are securable containers Secure layers instead of protocols, expose less to apps, scope RINA Introduction 8 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
  9. Network management Commonality is the key to effective network management 9 • 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
  10. Deployment New technology but incremental deployment RINA Introduction 10 • 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
  11. Research, open source, standards 11 • 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 RINA Introduction
  12. RINA Introduction Thanks for your attention! http://ict-pristine.eu http://pouzinsociety.org 12

Notas do Editor

  1. - Complexity, complexity, complexity (unbounded, nobody knows what new combinations of layers may be needed in the future
  2. Layers are resource allocators, provide IPC services over a certain scope, they all have the same functions
  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
Anúncio