O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Superfluid networking for 5G: vision and state of the art

534 visualizações

Publicada em

In physics, superfluidity is a state in which matter behaves like a fluid with zero viscosity. The vision of superfluid networking corresponds to the ability to decompose services into network functions to be deployed on-the-fly, run them anywhere in the network (core, aggregation, edge) and shift them transparently to different locations and heterogeneous execution environments. Superfluid networking tackles crucial shortcomings in today’s networks like long provisioning times, with wasteful over-provisioning used to meet variable demand and reliance on rigid and cost-ineffective hardware devices. The 5G System architecture can be deployed using techniques like Network Function Virtualization (NFV) that potentially enable the realization of superfluid networking. In this talk, we discuss the state of the art of NFV models and infrastructures for 5G and illustrate the path toward superfluid networking, considering the results of the Superfluidity research project (funded by EU in the H2020 framework).

Publicada em: Internet

Superfluid networking for 5G: vision and state of the art

  1. 1. Superfluid networking for 5G: vision and state of the art Stefano Salsano CNIT / Univ. of Rome Tor Vergata, Italy Project coordinator of EU H2020 Superfluidity project http://superfluidity.eu/ Invited talk – Session on Millimeter-wave and edge computing SmartCom 2017 -The 4th International Workshop on Smart Wireless Communications Rome, Italy - 24th October, 2017 A super-fluid, cloud-native, converged edge system
  2. 2. 5G Usage scenarios 2 ITU-R M.2083
  3. 3. Technical challenges / KPIs for 5G 3 10x User data rate 20x Peak data rate 100x Area traffic capacity 100x Network energy efficiency 10x Lower latency
  4. 4. Facing the 5G challenges 4 Radio Access Network 5G Core Network Air interface Networking: edge/aggregation/core Internet / Cloud Datacenters Datacenter BackhaulFronthaul
  5. 5. Facing the 5G challenges 5 Radio Access Network 5G Core Network Air interface Networking: edge/aggregation/core Internet / Cloud Datacenters Datacenter BackhaulFronthaul
  6. 6. 5G networks: the approach to face the challenges 6 • “The 5G System architecture is defined to support data connectivity and services enabling deployments to use techniques such as e.g. Network Function Virtualization (NFV) and Software Defined Networking (SDN).” (*) NVF + SDN (+MEC) = Network softwarization (*) 3GPP TS 23.501 V1.4.0 (2017-09)
  7. 7. Network softwarization 7 Radio Access Network 5G Core Network A large distributed Datacenter to support all networking/processing functions Internet / Cloud Datacenters Datacenter BackhaulFronthaul Air interface NFV – Network Function Virtualization / SDN – Software Defined Networking / MEC – Multi-access Edge Computing
  8. 8. Network softwarization 8 The Network Softwarization is the way to meet the target KPIs and reduce costs, thanks to: - efficient utilization of resources - reuse of functions - flexibility in the design of services Edge / Cloud RAN 5G Core Network Cloud Datacenters
  9. 9. Network softwarization 9 The Network Softwarization is the way to meet the target KPIs and reduce costs, thanks to: - efficient utilization of resources - reuse of functions - flexibility in the design of services Edge / Cloud RAN 5G Core Network Cloud Datacenters We want to reduce “space” and “time” granularity in allocation of the resources
  10. 10. From Network Softwarization to Superfluid networking Goals • Instantiate network functions and services on-the-fly • Run them anywhere in the network (core, aggregation, edge), across heterogeneous infrastructure environments (computing and networking), taking advantage of specific hardware features, such as high performance accelerators, when available Approach • Decomposition of network components and services into elementary and reusable primitives (“Reusable Functional Blocks – RFBs”) • Platform-independent abstractions, permitting reuse of network functions across heterogeneous hardware platforms 10
  11. 11. The Superfluidity vision 11 Current NFV technology Granularity Time scale Superfluid NFV technology Days, Hours Minutes Seconds Milliseconds Big VMs Small components Micro operations • From VNFs (Virtual Network Functions) to RFBs Reusable Functional Blocks
  12. 12. Heterogeneous composition/execution environments 12 • Classical NFV environments (i.e. by ETSI NFV standards) – VNFs are composed/orchestrated to realize Network Services – VNFs can be decomposed in VNFC (VNF Components) «Big» VNF «Big» VNF «Big» VNF «Big» VNF VNFC VNFC VNFC VM VM
  13. 13. Heterogeneous composition/execution environments 13 • Classical NFV environments (i.e. by ETSI NFV standards) – VNFs are composed/orchestrated to realize Network Services – VNFs can be decomposed in VNFC (VNF Components) «Big» VNF «Big» VNF «Big» VNF «Big» VNF VNFC VNFC VNFC VM VM - VNFC -> Full VMs (initially) - Containers are now being considered in the models - We further consider the Unikernels technology
  14. 14. Heterogeneous composition/execution environments 14 • Towards more «fine-grained» decomposition… • Modular software routers (e.g. Click) – Click elements are combined in configurations (Direct Acyclic Graphs)
  15. 15. Heterogeneous composition/execution environments 15 • Towards more «fine-grained» decomposition… • XSFM-based (eXtended Finite State Machine) decomposition of traffic forwarding / flow processing tasks, and HW support for wire speed execution
  16. 16. The Superfluidity Architecture 16 RFB #a RFB #b RFB #c RFB #n (node-level) RDCL script REE RFB#2 (network-level) RDCL script (network-wide) REE RFB Execution Environment RFB#1 (node-level) REE RFB Execution Environment RFB : Reusable Functional Blocks RDCLs : RFB Description and Composition Languages REE : RFB Execution Environments REEs are heterogeneous and can be nested
  17. 17. The Superfluidity Architecture (APIs) 17 RFB #a RFB #b RFB #c RFB #n (node-level) RDCL script REE RFB#2 (network-level) RDCL script REE Manager REE User REE Resource Entity UM API MR API REE User UM API REE Resource Entity REE Manager (network-wide) REE RFB Execution Environment RFB#1 MR API(node-level) REE RFB Execution Environment
  18. 18. (Towards) Common Abstractions for Heterogeneous Environments 18 REE - RFB Execution Environment(s) RFBs Description & Composition Languages (RDCLs) and tools • “Traditional” NFVI infrastructure hypervisors with Full VMs • NFVI with containers • Unikernel based virtualization • Software modular routers environments (e.g. Click) • Radio processing SW modules • Hardware packet processors • ETSI VNF descriptors / NEMO • MISTRAL – HEAT • Docker Compose … • Click configurations / SEFL / Symnet • PN (Process Networks), SDF (Synchronous Data Flow)… • XFSMs (eXtended Finite State Machines)
  19. 19. The Superfluidity vision 19 Current NFV/SDN technology Virtualization technologies heterogeneity Superfluid NFV/SDN technology VMs VMs & Containers VM, Containers, Unikernels • From VNF Virtual Network Functions to RFB Reusable Functional Blocks • Improving Virtual Infrastructure Managers (VIMs) • Heterogeneous RFB execution environments - Hypervisors - Modular routers - Packet processors … Single-level orchestration Nested decomposition & orchestration
  20. 20. Unikernels: a tool for superfluid virtualization Containers e.g. Docker • Lightweight (not enough?) • Poor isolation 20 Hypervisors (traditional VMs) e.g. XEN, KVM, wmware… • Strong isolation • Heavyweight Unikernels Specialized VMs (e.g. MiniOS, ClickOS…) • Strong isolation • Very Lightweight • Very good security properties They break the “myth” of VMs being heavy weight…
  21. 21. What is a Unikernel? • Specialized VM: single application + minimalistic OS • Single address space, co-operative scheduler so low overheads • Unikernel virtualization platforms extend existing hypervisors (e.g. XEN) driver1 driver2 app1 (e.g., Linux, FreeBSD) KERNELSPACEUSERSPACE app2 appNdriverN Vdriver1 vdriver2 app SINGLEADDRESS SPACE 21 General purpose OS Unikernel a minimalistic OS (e.g., MiniOS, Osv)
  22. 22. Unikernels (ClickOS) memory footprint and boot time VM configuration: MiniOS, 1 VCPU, 8MB RAM, 1 VIF • ~ 2 ms • 87.77 ms 22 Boot time, state of the art results Recent results from Superfluidity, by redesigning the XEN toolstack Memory footprint • Hello world guest VM : 296 KB • Ponger (ping responder) guest VM : ~700KB
  23. 23. Unikernels (ClickOS) memory footprint and boot time VM configuration: MiniOS, 1 VCPU, 8MB RAM, 1 VIF 23 Boot time, state of the art results Memory footprint • Hello world guest VM : 296 KB • Ponger (ping responder) guest VM : ~700KB Recent results from Superfluidity, by redesigning the XEN toolstack • ~ 2 ms • 87.77 ms
  24. 24. ETSI NFV Orchestration architecture 24
  25. 25. VM instantiation and boot time typical performance (no Unikernels) 25 Orchestrator request VIM operations Virtualization Platform Guest OS (VM) Boot time 1-2 s 5-10 s ~1 s
  26. 26. VM instantiation and boot time typical performance (no Unikernels) 26 Orchestrator request VIM operations Virtualization Platform Guest OS (VM) Boot time 1-2 s ~1 ms ~1 ms XEN Hypervisor Enhancements Unikernels Unikernels and Hypervisor can provide low instantiation times for “Micro-VNF”
  27. 27. VM instantiation and boot time typical performance (no Unikernels) 27 Orchestrator request VIM operations Virtualization Platform Guest OS (VM) Boot time 1-2 s ~1 ms ~1 ms XEN Hypervisor Enhancements Unikernels Can we improve VIM performances? Unikernels and Hypervisor can provide low instantiation times for “Micro-VNF”
  28. 28. Results – Unikernels (ClickOS) instantiation times in VIMs (OpenStack, Nomad, OpenVIM) 28 OpenStack Nova Nomad seconds seconds OpenVIM seconds
  29. 29. There is no comparison implied… • NB: the purpose of the work was NOT to compare OpenStack vs. Nomad vs. OpenVIM. The goal was to understand how the different VIMs behave and find ways to reduce instantiation times. • A direct comparison makes few sense. OpenStack is a much more complete framework in terms of offered functionality and different types of supported hypervisors. Note also that we have put most of our efforts into the optimization of OpenVIM because it was simpler to modify for our purposes. 29
  30. 30. The Superfluidity vision 30 Current NFV/SDN technology Virtualization technologies heterogeneity Superfluid NFV/SDN technology VMs VMs & Containers VM, Containers, Unikernels • From VNF Virtual Network Functions to RFB Reusable Functional Blocks • Improving Virtual Infrastructure Managers (VIMs) • Heterogeneous RFB execution environments - Hypervisors - Modular routers - Packet processors … Single-level orchestration Nested decomposition & orchestration
  31. 31. Orchestration of heterogeneous and nested RFBs • Extended the ETSI NFV models to support: – coexistence of VMs, containers, unikernels – nested decomposition of one “VDU” into a modular software router platform (click router) • Developed the RDCL 3D tool to demonstrate the extended models • Extended the OpenStack networking with “kuryr” project to support the networking of VMs and containers 31
  32. 32. Working prototype RDCL 3D: RFB Description and Composition Language Design Deploy and Direct 32 This is a regular VM (XEN HVM) These are 3 Unikernel VMs (ClickOS)
  33. 33. Working prototype RDCL 3D: RFB Description and Composition Language Design Deploy and Direct 33 This is a regular VM (XEN HVM) These are 3 Unikernel VMs (ClickOS)
  34. 34. Working prototype RDCL 3D: RFB Description and Composition Language Design Deploy and Direct 34 This is a regular VM (XEN HVM) These are 3 Unikernel VMs (ClickOS)
  35. 35. Working prototype RDCL 3D: RFB Description and Composition Language Design Deploy and Direct 35 This is a regular VM (XEN HVM) These are 3 Unikernel VMs (ClickOS) Live demo of RDCL 3D prototype: http://rdcl-demo.netgroup.uniroma2.it/
  36. 36. The Superfluidity vision 36 Hardware platforms heterogeneity Homogeneous HW (COTS Servers) HW acceleration • Heterogeneous RFB execution environments - Hypervisors - Modular routers - Packet processors … Programmable Data Plane Chips OpenFlow Switches XFSM eXtended Finite State Machine abstractions Current NFV/SDN technology Superfluid NFV/SDN technology
  37. 37. Network Functions reuse/migration 37 NFV-like VNF management General purpose Computing Platform (CPUs) specific VNF VM General purpose Computing Platform (CPUs) specific VNF VM SDN-like Configuration deployment The ‘traditional’ VNF’s view General purpose computing platform Deploy VNFs over the VMs Full flexibility (VNF = ‘anything’ coded in ‘any’ language) Performance limitations (slow path execution) Pre-implemented match/action table OpenFlow (HW) switch Flow table Entry Flow table Entry Flow table Entry flow-mod Flow table Entry Flow table Entry Flow table Entry flow-mod Pre-implemented match/action table OpenFlow (HW) switch Traditional SDN southbound (OpenFlow) Domain-specific platform (OpenFlow router) move ‘config’ of a (pre-implemented!) flow-table Extremely limited flexibility (hardly an NF) Line-rate performance (TCAM/HW)
  38. 38. Network Functions reuse/migration 38 NFV-like VNF management General purpose Computing Platform (CPUs) specific VNF VM General purpose Computing Platform (CPUs) specific VNF VM SDN-like Configuration deployment The ‘traditional’ VNF’s view General purpose computing platform Deploy VNFs over the VMs Full flexibility (VNF = ‘anything’ coded in ‘any’ language) Performance limitations (slow path execution) Pre-implemented match/action table OpenFlow (HW) switch Flow table Entry Flow table Entry Flow table Entry flow-mod Flow table Entry Flow table Entry Flow table Entry flow-mod Pre-implemented match/action table OpenFlow (HW) switch Traditional SDN southbound (OpenFlow) Domain-specific platform (OpenFlow router) move ‘config’ of a (pre-implemented!) flow-table Extremely limited flexibility (hardly an NF) Line-rate performance (TCAM/HW) Lean towards ‘more domain specific’ network computing HW Lean towards ‘more expressive’ programming constructs / APIs
  39. 39. References • SUPERFLUIDITY project Home Page http://superfluidity.eu/ • G. Bianchi, et al. “Superfluidity: a flexible functional architecture for 5G networks”, Transactions on Emerging Telecommunications Technologies 27, no. 9, Sep 2016 • F. Manco, C. Lupu, F. Schmidt, J. Mendes, S. Kuenzer, S. Sati, K. Yasukata, C. Raiciu, F. Huici, “My VM is Lighter (and Safer) than your Container”, 26th ACM Symposium on Operating Systems Principles, SOSP 2017, October 28-31, 2017, Shanghai, China • P. L. Ventre, C. Pisa, S. Salsano, G. Siracusano, F. Schmidt, P. Lungaroni, N. Blefari-Melazzi, “Performance Evaluation and Tuning of Virtual Infrastructure Managers for (Micro) Virtual Network Functions”, IEEE NFV-SDN Conference, Palo Alto, USA, 7-9 November 2016 http://netgroup.uniroma2.it/Stefano_Salsano/papers/salsano-ieee-nfv-sdn-2016-vim-performance-for-unikernels.pdf 39 Architecture Unikernels
  40. 40. References • S. Salsano, F. Lombardo, C. Pisa, P. Greto, N. Blefari-Melazzi, “RDCL 3D, a Model Agnostic Web Framework for the Design and Composition of NFV Services”, 3rd IEEE International Workshop on Orchestration for Software Defined Infrastructures, O4SDI at IEEE NFV-SDN conference, Berlin, 6-8 November 2017 • S. Salsano, L. Chiaraviglio, N. Blefari-Melazzi, C. Parada, F. Fontes, R. Mekuria, D. Griffioen, “Toward Superfluid Deployment of Virtual Functions: Exploiting Mobile Edge Computing for Video Streaming”, Soft5 Workshop, 1st International Workshop on Softwarized Infrastructures for 5G and Fog Computing, in conjunction with 29th ITC conference, Genoa, Italy, 8th September 2017 40 NFV models and tools MEC Multi-access Edge Computing
  41. 41. References • L. Chiaraviglio, L. Amorosi, S. Cartolano, N. Blefari-Melazzi, P. Dell’Olmo, M. Shojafar, S. Salsano, “Optimal Superfluid Management of 5G Networks”, 3rd IEEE Conference on Network Softwarization, NetSoft 2017, 3-7 July 2017, Bologna, Italy. • L. Chiaraviglio, N. Blefari-Melazzi, C.F. Chiasserini, B. Iatco, F. Malandrino, S. Salsano, “An Economic Analysis of 5G Superfluid Networks”, 18th IEEE International Conference on High Performance Switching and Routing (IEEE HPSR), 18-21 June 2017, Campinas, Brazil. • M. Shojafar, L. Chiaraviglio, N. Blefari-Melazzi, S. Salsano, “P5G: A bio-inspired algorithm for the superfluid management of 5G Networks”, IEEE GLOBECOM 2017, 4-8 December, 2017, Singapore. 41 NFV Infrastructures optimal design, planning, management
  42. 42. Take home messages • Superfluid networking: a vision to fully exploit the network softwarization approach • Decomposition in “small” Reusable Functional Blocks to reduce the space granularity in the allocation of resources • Redesign of the orchestration models and tools for dynamic deployment of services to reduce the time granularity in the allocation of resources • Orchestration models and tools need to take into account heterogeneity of Execution Environment and support “nested” decomposition across multiple Execution Environments 42
  43. 43. Thank you. Questions? Contacts Stefano Salsano University of Rome Tor Vergata / CNIT stefano.salsano@uniroma2.it http://superfluidity.eu/ The work presented here only covers a subset of the work performed in the project 43
  44. 44. The SUPERFLUIDITY project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No.671566 (Research and Innovation Action). The information given is the author’s view and does not necessarily represent the view of the European Commission (EC). No liability is accepted for any use that may be made of the information contained. 44

×