Advertisement

Rina converged network operator - etsi workshop

May. 11, 2016
Advertisement

More Related Content

Advertisement
Advertisement

Rina converged network operator - etsi workshop

  1. Large scale RINA Experimentation on FIRE + Designing a converged network operator with RINA: any access, any application From Research to Standardization workshop May 10, 11 Sophia Antipolis
  2. A converged network vision.. • Any access media, any application requirement supported by a common network infrastructure • Single architecture, single management system, single users database (regardless of access) Large-scale RINA Experimentation on FIRE+ 2 Manage users and sessions, Local managed services Capillarity, Capacity, Mobility support Multiplexing Switching, Transport Control functions, Regional managed services Devices Places Users Access Aggregation Local Points of Presence Core Regional Data Centres Radio Fiber
  3. Are “All IP networks” fit for this purpose? • 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 Large-scale RINA Experimentation on FIRE+ 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
  5. RINA macro-structure (layers) Single type of layer, consistent API, programmable policies 5 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.) Large-scale RINA Experimentation on FIRE+ 6 (Theory) (Practice)
  7. Naming and addressing, mobility, routing No need for special protocols Large-scale RINA Experimentation on FIRE+ 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 Large-scale RINA Experimentation on FIRE+ 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 Large-scale RINA Experimentation on FIRE+ 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
  10. Deployment Clean-slate concepts but incremental deployment Large-scale RINA Experimentation on FIRE+ 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. Service provider, RINA, Internet (e-mall) Access Access router PtP DIF CPE Edge Service Router MAN P.E MAN P. E. MAN Access DIF MAN Core DIF PtP DIF PtP DIF PtP DIF PtP DIF MAN P PtP DIF Host Core Backbone DIF PtP DIF Core router Core router e-mall Access Router E-mall Border Router Customer network Service Prov. 1 network Access Aggregation Service Edge Core Internet Edge Internet ( e-mall) eXchange Point Core PoP, city B Core PoP, city ACity A MAN City A Cabinets PtP DIF PtP DIF PtP DIF Service Provider Top Level DIF E-mall 1 DIF PtP DIF E-mall 2 DIF
  12. Service provider, RINA, Internet (e-mall) Access Access router PtP DIF Cell Tower (eNodeB) Mobile Edge Service Router MAN P.E MAN P. E. MAN Access DIF MAN Core DIF PtP DIF PtP DIF PtP DIF PtP DIF MAN P Cell DIF Mobile Host (or border router) Core Backbone DIF PtP DIF Core router Core router e-mall Access Router E-mall Border Router Service Prov. 1 network Access Aggregation Service Edge Core Internet Edge PtP DIF PtP DIF PtP DIF Service Provider Top Level DIF E-mall 1 DIF PtP DIF E-mall 2 DIF Mobile Access DIF Internet ( e-mall) eXchange Point Core PoP, city B Core PoP, city A City A MANCity A Cabinets Cell sites
  13. From research to standardisation Large-scale RINA Experimentation on FIRE+ 13 • 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

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
  5. 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
  6. 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
  7. Start by emalls, CPEs connecting to e-mall DIFs. * The man’s scope may be a city (then it is really a metropolitan area network) or a region aggregating several towns/rural areas (then it is a regional area network) e.Mall access router may be reachable from the same core PoP where a customer is connected or from a different one (as in picture) Divided e-mall access and border router, may be a single router
  8. * Mobile Access DIF Hides Cell Towers from Service Provider TL. DIF, and makes the Mobile Hosts appear stationary to the Mobile Edge Service Router (mobility anchor), where the Mobile Host User can access the Service Provider Top Level DIF and from there communicate with other service provider customers or to one or more of the available e-malls. * More Mobile Access DIF layers with more “local” mobility anchors could be added as well if the deployment required it.
  9. 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
Advertisement