APNIC, profile picture
Uploaded byAPNIC
1,477 views

Network Function Virtualisation: a tutorial

NFV aims to virtualize network functions that were traditionally run on dedicated hardware appliances. This allows the functions to run on commercial off-the-shelf servers and switches in data centers. NFV promises to reduce costs, increase flexibility and speed up innovation cycles compared to proprietary hardware appliances. A key enabler is virtualization technology which allows multiple virtual machines to run in isolation on shared server hardware through the use of hypervisors.

Embed presentation

1 © Nokia 2018 Network Function Virtualisation Public A tutorial • Paresh Khatri • Feb 27, 2018
2 © Nokia 2018 1. Introduction 2. Virtualisation for network engineers: a primer 3. ETSI NFV ISG Framework: a. NFVI b. MANO c. VNFs 4. Performance 5. Open source 6. State of industry Public Agenda
3 © Nokia 2018 introduction Public
4 © Nokia 2018 Public Specialization versus generalization … repeating cycle of technology evolution Specialization Generalization • Ability to finely tune and optimize for high performance • High efficiency • Limited to specific functions • Limited flexibility • Higher cost due to reduced economies of scale • Flexibility – ability to perform multiple, diverse functions • Lower cost due to economies of scale • Not overly efficient at any one particular task • Lower efficiency and performance … NFV is the latest phase in this cycle
5 © Nokia 2018 Public The evolution of the humble router 1969 Interface Message Processor (IMP) • Router for the first TCP/IP network – ARPANET • Ruggedized Honeywell DDP-516 minicomputer • Special-purpose interfaces and software 1981 Multi-protocol routers • Stanford/MIT researchers • IP/AppleTalk/DECnet/ Xerox protocols • General-purpose mini-computers Late 1990s Internet-scale routers • Very-high throughput based on specialised forwarding ASICs • Optimized for IP Early 2000s Multi-service routers • Continued hardware evolution • Programmable network processors • Optimized for multi- services over IP Basic packet processing in software Addition of QoS, access control, control plane protocols Optimization of hardware for line- rate performance Programmable hardware, massive parallel processing, L4-7 services
6 © Nokia 2018 When faced with new or different problems, “we” have… Public Solving network-layer problems developed new protocols optimised with new hardware
7 © Nokia 2018 So what’s the problem, really ? Anatomy of a telco application (ATCA) System Control & Management Cards ® Specialised OAM middleware I/O and load distribution ® Specialised application middleware Application Function A ® More cards for more capacity Application Function B ® More (different) cards for more capacity Specialised blades with dedicated processors ® Many different/specialised OS’s Standard components in specialised configuration => ‘box scaling rules’ ATCA = Advanced Telecommunications Computing Architecture Public
8 © Nokia 2018 The world before NFV Pre-NFV • Specialized network software running on purpose-built hardware (ASICs, NPUs) • Different devices generally required for different functions • Each function is independently dimensioned, scaled and deployed. • Lifecycles dictated primarily by hardware evolution Public
9 © Nokia 2018 Public A call to action… • Seminal white paper written by representatives of 13 major carriers • Published at the “SDN and OpenFlow World Congress”, Darmstadt-Germany in October 2012 … and thus, NFV was born http://portal.etsi.org/NFV/NFV_White_Paper.pdf
10 © Nokia 2018 • White paper 2 (http://portal.etsi.org/NFV/NFV_White_Paper2.pdf): - Published October 15-17, 2013 at the “SDN and OpenFlow World Congress”, Frankfurt-Germany. - Provided an update on the work of the ETSINFV ISG and a summary of the documents produced thus far - Highlighted need for standardisation of interfaces (reference points) between various elements of the reference architecture • White paper 3 (http://portal.etsi.org/NFV/NFV_White_Paper3.pdf): - October 14-17, 2014 at the “SDN & OpenFlow World Congress”, Dusseldorf-Germany. Public Follow-up white papers http://portal.etsi.org/NFV/NFV_White_Paper.pdf
11 © Nokia 2018 • Large numbers of diverse, proprietary hardware appliances. • Increasing costs of energy, capital investment challenges difficulties in finding skillsets to support ever more complex network architectures Public Challenges articulated by operators • New network services require newer varieties of hardware with the resultant requirement for space and power • Relatively small lifetime of hardware- based appliances (getting shorter all the time) necessitating an endless cycle of procure-design-integrate- deploy hardware Roll-out of new services is slow
12 © Nokia 2018 disaggregation /dɪsˈaɡrɪɡeɪʃ(ə)n/ noun past tense: disaggregated; past participle: disaggregated separate (something) into its component parts. usage: "a method for disaggregation of large conglomerates" Public Disaggregation Definition In a networking context: Disaggregation is the process of decomposing the elements of an integrated system into discrete, individual components so that they may be individually sourced to provide an optimal mix of software and hardware
13 © Nokia 2018 Public NFV disaggregation The basic model • Consolidation of different types of network equipment onto industry- standard high-volume servers, storage and switches. Vertically Integrated System NFV Network Function Purpose- built Hardware Virtual Network Function COTS Hardware Basic Premise (Simplified)
14 © Nokia 2018 NFV vs SDN SDN Monolithic switches/routers Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Standard high volume servers, storage, switches Orchestrated, automatic & remote lifecycle management SDN Controller Network Mgmt Programmability, separate control plane, centralized view NFV Physical appliances Public
15 © Nokia 2018 Public SDN disaggregation The basic model Net- work Apps Net- work Apps Net- work Apps VERTICALLY INTEGRATED SYSTEM SDN Network Apps Forwarding Hardware Northbound Interfaces Southbound Interfaces FORWARDING PLANE ELEMENTS CONTROL PLANE ELEMENTS APPLICATION PLANE ELEMENTS Network Apps Network Apps Network Operating SystemNetwork Operating System Forwarding Hardware Lightweight OS Forwarding Hardware Lightweight OS Forwarding Hardware Lightweight OS
16 © Nokia 2018 NFV: challenging the status quo Public Why NFV? NFV Key premises: • Decouple hardware from software • Use COTS hardware SERVICE VELOCITY Reduce time-to-market of new services OPENNESS Reduce vendor lock-in MULTI-TENANCY Greater efficiency of network usage OPERATIONAL EFFICIENCY Homogeneity of physical elements, elasticity Optimize network resources, Reduce opex, Open ecosystem IMPROVED NETWORK ECONOMICS
17 © Nokia 2018 Enablers Public Cloud Computing • Hardware virtualisation via hypervisors • Virtual (software-based) Ethernet switches • Multi-core CPUs • Smart Ethernet NICs • Poll-mode drivers • Compute management systems for lifecycle management of VMs • Open APIs for management COTS Hardware • Economies of scale of compute platforms • Competitive market for server components, avoiding vendor lock-in • Improving performance over time
18 © Nokia 2018 • Development of virtualized applications that are portable between different hypervisors, hardware etc. • Inter-working in a mixed virtual-physical environment • Evolution of OSS/BSS systems to support virtualised systems • Management and orchestration of virtual appliances • Achieving acceptable performance and resilience compared to hardware-based functions • Support of multi-vendor environments Public Perceived challenges Significant challenges would have to be surmounted
19 © Nokia 2018 • A new operator-led Industry Specification Group (ISG) was set up under ETSI to support NFV development • While ETSI is an SDO, the objective of the ISG was not to produce standards but to identify requirements and develop architectures. It would reference the work of other SDOs as required. • Produced the following (release 1 documents): - NFV Use Cases document - NFV Requirements document - NFV Architectural Framework document - NFV Terminology document - NFV Proof-of-concept framework Public Consequences Formation of ETSI NFV ISG
20 © Nokia 2018 Original 2-year term of the ISG expired in early 2015. • Extended for an additional 2 years with the objective of: - Completion of the definition of key interface specifications to allow inter-operable implementations of NFV components: • Orchestrator <-> VIM • Orchestrator <-> VNF • VNFM <-> VNF • VNF <-> NFVI - Study of how NFV infrastructures will interact with legacy OSS/BSS systems • How OSS/BSS systems need to evolve to support NFV • OSS/BSS <-> Orchestrator interface • OSS/BSS <-> Element manager interface Public ETSI NFV ISG Phase 2
21 © Nokia 2018 • Elaborated on requirements, information models and interface specifications for key interfaces identified in the reference architectures • Produced the following Release 2 documents in early 2015: - NFVI: • NFV Infrastructure Overview • NFV Compute Domain • NFV Hypervisor Domain • NFV Infrastructure Network Domain - Management and Orchestration document • Detailed functionality of NFVO, VNFM and VIM • Phase 3: - Third 2-year period of work ongoing with a view to producing Release 3 documents Public ETSI NFV ISG Release 2
22 © Nokia 2018 virtualisation for network engineers: a primer Public
23 © Nokia 2018 • Motivation: - Better use of hardware resources: significant waste of compute resources when using bare-metal server. - Requirement to be able to pool hardware resources and get better efficiency. - Reduce power and space requirements via consolidation - Ability to ship applications as a package that can run anywhere • Requirements: - Isolation between different applications sharing server hardware - Isolation (or allocation) of resources to different applications sharing the hardware platform - No significant loss of performance Public Server virtualisation
24 © Nokia 2018 • Emulation - Make one system behave like or imitate a different one; software mimicking hardware - Take an entire system and make it run on a platform it was not designed for (includes totally different CPU architectures) (Example: play your Sega Megadrive games on your PC) - Huge performance impact - Very useful for ensuring the continuation of required legacy hardware/software and for migrations Public Virtualisation Overview Types of Virtualisation (1) VM HWHW VMM VM Real driver XReal driver X Real driver Y Emulated HW
25 © Nokia 2018 • (Full) Virtualisation - Known as many things (HVM, Accelerated Virtualisation, Hardware Assisted Virtualisation, Native Virtualisation)…essentially emulation, but with support of virtualization in hardware - Hypervisor: software that allows hosting of multiple “virtual machines” on a single guest machine by turning physical resources into logical resources which can be supplied/requested to/from guests e.g KVM - Guest operating system is unaware that it is operating in a virtualized environment and therefore, requires no modification to operate in the virtualised environment; Guests use unmodified drivers to connect to the virtualised resources Public Virtualisation Overview Types of Virtualisation (2) - Host and Guest architectures must be the same architecture (e.g. x86_64) - Calls to hardware need to be intercepted by the hypervisor - Hardware support for virtualization is required e.g. Intel VT-x VM Real driver HW VM Real driver HW VM Real driver HW VMM HW VM Real driver (As seen by VM) (As seen by VMM)
26 © Nokia 2018 • Para-Virtualisation (PV) - The code of an operating system is modified in order to allow that operating system to run as a guest; most OS’s today ship with para-virtualization interfaces - Rather than calls directly being made by the guest to hardware, which are then intercepted by the hypervisor (or Virtual Machine Monitor, VMM) and converted, the calls are instead made from the guest directly to the VMM Public Virtualisation Overview Types of Virtualisation (3) - The guest is aware that it is running in a virtualized system. - Can provide better performance than full (software-based) virtualization - The VMM is aware of the requirements on the guest(s) and can manage resources accordingly - For high I/O where the guest knows that it is virtualised (most situations these days) para-virtualisation (VirtIO drivers on KVM, VMware Tools on VMware ) can be used Driver itf VM modified driver HWHW VMMReal driver VM modified driver Driver itf
27 © Nokia 2018 • Hybrid Virtualisation - Combination of para-virtualisation for some hardware functions (e.g. virtio for I/O) and full virtualisation for others. - Can provide better performance without requiring full para-virtualization - Can provide the best of both worlds - Example: KVM uses hardware virtualization extensions but also supports para-virtualisation driver for network devices (via virtio) etc. Public Virtualisation Overview Types of Virtualisation (4)
28 © Nokia 2018 • Also know as a Virtual Machine Monitor (VMM) • Software that allows hosting of multiple “virtual machines” on a single guest machine by turning physical resources into logical resources which can be supplied/requested to/from guests • Interfaces with the physical host hardware allowing it to be presented to multiple virtualised guests • Marshals the sharing of resources between guests (access to CPU, GPU, memory and other hardware) Public Virtualisation Overview Hypervisors
29 © Nokia 2018 Type 1: Native Hypervisor Virtualisation Overview Hypervisors (1) Hardware Native Hypervisor Virtual Hardware Virtual Hardware Virtual Hardware Spare Guest Operating System (VNF) Guest Operating System (VNF) Guest Operating System (VNF) Public Type 1: Native/Bare-Metal Hypervisors Examples: VMware ESXi, Microsoft Hyper-V, Citrix XEN The host operating system is the Hypervisor software. Hypervisor has direct access to all hardware and features of the underlying machine.
30 © Nokia 2018 Hardware Conventional (Host) Operating System Virtual Hardware Virtual Hardware Virtual Hardware Hosted Hypervisor Apps on Host Operating System Guest Operating System (VNF) Guest Operating System (VNF) Guest Operating System (VNF) Virtualisation Overview Hypervisors (2) Public Type 2: Hosted Hypervisors Examples: VMware Workstation, Parallels, Oracle Virtual Box Relies on the underlying host operating system for access to the hardware. If the underlying host O/S develops an issue the guests can fail. More resource overhead than Type-1 hypervisors [Linux KVM is actually a kernel module that converts the operating system to a type-1 hypervisor so can be said to exhibit characteristics of both type-1 and type-2 hypervisors] Type 2: Hosted Hypervisor
31 © Nokia 2018 Virtualisation Overview Common Hypervisors Public
32 © Nokia 2018 • VM-based virtualisation operates at a hardware-level i.e. it attempts to provide a distinct, virtual hardware environment for each VM. • Containers are a new approach that provides separate operating environments for each application via a single, shared kernel i.e. OS- virtualisation instead of machine virtualisation • Uses Linux kernel features cgroups and namespaces, which provide an isolated execution environment with its own PID space, network device, filesystems, CPU, RAM etc. Public Containers Containers Hardware Host operating system kernel Container 1 Container 2 Container 3 Container 4 App App App App Container engine Bins/ Libraries Bins/ Libraries Bins/ Libraries Bins/ Libraries
33 © Nokia 2018 • Advantages over VMs: - No duplication of operating system resources - VMs have higher overheads (each VM is a complete machine) - Smaller and light-weight - Higher scale - Faster loading times • Challenges: - Isolation and sharing concerns need to be resolved; VMs provide much better isolation as each VM operates in a separate, virtual hardware context. - All containers on a single hardware server must use the same operating system and kernel • Outlook: - Use cases exist for both VM and container applications; hard to see containers completely replacing VMs in the near future Public Containers Comparing and contrasting with VMs
34 © Nokia 2018 • LXC • Docker(Uses LXC) • OpenVz • Parallels Virtuozzo • Solaris Containers • HP-UX containers Public Containers Implementations
35 © Nokia 2018 Leverage: Agility & Cost Effectiveness EXTEND Real-time and 5 9s Distributed Architecture Unrestricted Networking Optimized Operations Security IT Best Practices Open Source SW Commodity HW Cloud Technology Data Centre Technology What makes NFV different from public cloud? Public
36 © Nokia 2018 etsi nfv reference architecture Public
37 © Nokia 2018 Public NFV disaggregation The basic model NFV Vertically Integrated System Network Function Purpose- built Hardware Virtual Network Function COTS Hardware Basic Premise (Simplified) `VNF Virtual Network Functions (VNFs) VNF VNF NFV Infrastructure (NFVI) Virtual Compute Virtual Storage Virtual Network Virtualization Layer Storage Hardware Network Hardware Compute Hardware NFVManagement& Orchestration(MANO) ETSI High-level NFV Framework
38 © Nokia 2018 High-level ETSI NFV Framework ETSI GS NFV 002 Public NFV Management and Orchestration (MANO) Virtual Network Functions (VNFs) VNF VNF VNF VNF VNF NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage Source: ETSI GS NFV 002 Underlying physical resources Virtualised resources Virtualised instances of network functions All tasks required for management of the VNF lifecycle Hypervisor, containers etc
39 © Nokia 2018 • In charge of orchestration and management of NFV infrastructure, software resources and realizing network services. • Network Service lifecycle management. Responsible for VNF lifecycle management (e.g. instantiation, update, query, scaling, termination)NS Catalog VNF Catalog NFV Instances NFVI Resources OSS/BSS EM VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) NFV Orchestrator (NFVO) VNF NFV Infrastructure (NFVI) Execution reference points Other reference points Main NFV reference points NFV MANO Or-ViNf-Vi Vi-Vnfm Ve-Vnfm-em Ve-Vnfm-vnf Or-Vnfm Vn-Nf Os-Ma- nfvo ETSI NFV E2E Architecture ETSI GS NFV-MAN 001 Controls and manages the interaction with the virtualized infrastructure (compute, network and storage resources) All hardware and software components which build up the environment in which VNFs are deployed, managed and executed Public
40 © Nokia 2018 etsi nfv reference architecture nfvi Public
41 © Nokia 2018 • All of the hardware and software components which provide the environment in which VNFs are deployed • Provides virtual resources required to run VNFs; includes COTS hardware, accelerator components and a software layer which virtualizes and abstracts the underlying hardware. • Multi-tenant environment Public NFVI Framework
42 © Nokia 2018 NFVI Public Framework Virtualised Infrastructure Manager (VIM) May include SDN controller for network virtualisation Virtual Network Functions (VNFs) VNF VNF VNF VNF VNF Vn-Nf Nf-Vi NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage Underlying physical resources Virtualised resources Hypervisor, containers etc
43 © Nokia 2018 • Hardware resources - compute: - VNF requirements still dictate server specifications • Key challenge as a one-size-fits-all-VNFs policy could result in over-engineered servers, with impact on TCO and large amounts of unused capacity - Typically rack servers but blade servers also popular - Dominated by Intel (Intel has >90% market share in servers) • Intel Xeon E5-2600 processors offering good price vs performance characteristics Public NFVI Hardware resources NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
44 © Nokia 2018 • Hardware resources - storage: - Particularly important for storage-intensive VNFs such as caching, analystics - Direct Attached Storage (DAS) • Attached directly to the server - Network Attached Storage (NAS) • Provides network access to file-level data storage - Storage Area Network (SAN) • Provides network access to block-level data storage - Software-Defined Storage (SDS) • Akin to SDN for networks • Separates management and control software from underlying storage hardware (industry-standard storage-optimized servers) Public NFVI Hardware resources NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
45 © Nokia 2018 • Hardware resources - network: - Traditional, proprietary L2 or L3 switches - Open, industry-standard, switches: • bare-metal switches • white-box switches • brite-box switches (brite = branded white-box, a Gartner-coined term) Public NFVI Hardware resources NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
46 © Nokia 2018 Public NFVI Virtualisation layer • Hypervisor sits on top of the hardware resources and provides a mechanism to share them across virtual machines (VMs) • Abstracts and logically partitions physical resources - Emulates a physical machine for each VM - Provides isolation between VMs - Emulates NIC cards for each VM • Major deployments based on KVM and Vmware vSphere - Others include Oracle XEN and Microsoft Hyper-V • Emphasis has been on virtual machines but containers are now being looked at as a future option NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
47 © Nokia 2018 • Virtualised CPU (vCPU): virtualised CPU created for a VM by a hypervisor • Virtualised NIC (vNIC): virtualised NIC created for a VM by a hypervisor • Virtualised Switch (vSwitch): Ethernet switch implemented by the hypervisor that interconnects vNICs of VMs with each other and with the NIC of the compute node Public NFVI Terminology Source: ETSI GS NFV 003 V1.3.1
48 © Nokia 2018 • Virtual resources - compute: - Created by the hypervisor - APIs to support VM lifecycle actions: create, start, stop, pause, shutdown, migrate, delete, manage etc. Public NFVI Virtual resources - compute NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
49 © Nokia 2018 • Virtual resources - network: - Software switch or router on the hypervisor - Functions: • Allows communication between VMs • Tunneling for overlay services • ACLs • Distributed routing - Switching solutions: • OpenVSwitch (OVS) • FD.io (“fido”) • vSphere Distributed Switch (VDS) - Data-plane acceleration technologies: • DPDK • OpenDataPlane (ODP) Public NFVI Virtual resources - network NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
50 © Nokia 2018 • Hardware: - Specialised I/O processors - Smart NICs: ability to offload functions such as ACL, tunnel encapsulation/decapsulation, switching, encryption and acceleration from the CPU • Virtualisation layer: - Maturation of container technology (use of Operating System virtualization instead of virtual machine virtualization. - Concerns around isolation need to be addressed Public NFVI What’s next ?
51 © Nokia 2018 VIM Public Framework Virtualised Infrastructure Manager (VIM) Or-Vi NFV Infrastructure (NFVI) Orchestrator VNFM Nf-Vi Vi-Vnfm • VIM - Manages the NFV Infrastructure (NFVI), performance and fault management - Maintains inventory of hardware and software resources - Maintains inventory of allocation of virtual resources to physical resources - Manages lifecycle of virtual resources - Interacts with MANO layer
52 © Nokia 2018 • Two dominant solutions today: - OpenStack - Vmware vCloud Director (vCD) • New solution focus areas: - Seamless integration with MANO and automation solutions - Management of containers and bare metal in addition to VMs • Emerging solutions: - OpenVIM: part of OpenMANO, lightweight VIM - Kubernetes: container orchestration project that came out of Google, now under the Linux Foundation Public VIMs
53 © Nokia 2018 etsi nfv reference architecture vnfs Public
54 © Nokia 2018 VNFs Public NFV Management and Orchestration (MANO) Virtual Network Functions (VNFs) VNF VNF VNF VNF VNF NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage Source: ETSI GS NFV 002 software implementation of a network function which is capable of running over the NFVI. Corresponds to the software component of today’s network devices, delivered as pure software that is hardware- independent (or at least capable of running on industry-standard servers) Physical Network Function (PNF): physical version of a network function i.e. a network function designed to run on purpose-built hardware
55 © Nokia 2018 • Network Function (NF): functional block within a network infrastructure that has well- defined external interfaces and well-defined functional behavior; network node or physical appliance today e.g. BNG, firewall, IDS, IPS • Physical Network Function (PNF): implementation of a NF via a tightly coupled software and hardware system • Virtualised Network Function (VNF): implementation of an NF that can be deployed on a Network Function Virtualisation Infrastructure (NFVI) Public VNFs Terminology Source: ETSI GS NFV 003 V1.3.1
56 © Nokia 2018 • Virtualised Network Function Component (VNFC): internal component of a VNF providing a VNF Provider a defined sub-set of that VNF's functionality, with the main characteristic that a single instance of this component maps 1:1 against a single Virtualisation Container • Virtualised Network Function Descriptor (VNFD): configuration template that describes a VNF in terms of its deployment and operational behaviour, and is used in the process of VNF on-boarding and managing the lifecycle of a VNF instance Public VNFs Terminology Source: ETSI GS NFV 003 V1.3.1
57 © Nokia 2018 VM • Functional behaviour and state of a NF are largely independent of whether the NF is virtualised or not. The functional behaviour and the external operational interfaces of a Physical Network Function (PNF) and a VNF are expected to be the same. • A VNF can be composed of multiple internal components. For example, one VNF can be deployed over multiple VMs, where each VM hosts a single component of the VNF. However, in other cases, the whole VNF can be deployed in a single VM as well. Public VNFs Decomposition VNFC 1 VNF 1 VM VNFC 2b VNF 2 VM VNFC 2a VM VNFC 2c Simple VNF Composite VNF
58 © Nokia 2018 • Tends to be focussed more on L4-L7 functions today. • Top NFV use cases today are CPE virtualisation and mobile core virtualisation. Public VNFs Key functions vCPE Move fast evolving functions into the cloud vEPC Easy deployment of customer specific mobile services vDNS,vFW Virtualizatio n of simple network appliances vIMS Rapid deployment of new communicat ions services
59 © Nokia 2018 • A simple porting of a network function from a proprietary hardware element to a virtualised version capable of running on industry-standard servers is not sufficient: - Unless network functions are optimised for the hardware on which they are intended to run, they will not deliver a level of performance that makes the transition economically viable; low-level code needs to be re-written to be able to enhance performance, particularly for data-plane-intensive functions - To truly achieve the benefits of virtualisation, monolithic applications may need to be disaggregated into their constituent components, leading to an architecture that is more cloud- native - New horizontal scaling mechanisms need to be introduced, something that is not readily realised in today’s hardware-based systems Public VNFs Porting
60 © Nokia 2018 VNFs VNF Descriptor Template Node template Relationship template Group Inputs Outputs node_templates: rra: type: tosca.nodes.Compute properties: num_cpus: 2 mem_size: 2048 image_name: { get_input: ImageName } keypair_name: { get_input: keypair_input } (De-facto) standards: • OpenStack HOT • OASIS TOSCA VNF Descriptor (VNFD): A template describing the application specifics and topology Public
61 © Nokia 2018 • A lot VNFs today are not truly cloud-optimised, being simple ports of PNFs (“NFV washing”). This is a necessary step, however, for the industry to start gaining experience with virtualisation without waiting for full, cloud-native functions. • Achieving high performance (for data-plane functions) remains a challenge. VNFs are shipping with vendor-specified minimum requirements for hardware. • The ability to use common hardware for all VNFs is not there yet. Extensive inter- operability testing is still required between VNFs and the underlying NFVI. • Licensing for VNFs is not as straightforward as the hardware-equivalent; VNFs have different characteristics and performance, can scale in and out and are a lot more dynamic. How do you price this ? • Managing VNFs (via the MANO infrastructure) is vastly different to managing network hardware. Newer skills will be required for operators. Public VNFs Challenges
62 © Nokia 2018 etsi nfv reference architecture mano Public
63 © Nokia 2018 • Purpose of the MANO function is to: - Manage and orchestrate VNFs - Manage and orchestrate NFV infrastructure …in order to allow NFV Network Services (chain of VNFs and/or PNFs) to be created, maintained and destroyed MANO NS Catalog VNF Catalog NFV Instances NFVI Resources OSS/BSS EM VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) NFV Orchestrator (NFVO) VNF NFV Infrastructure (NFVI) Execution reference points Other reference points Main NFV reference points Or-ViNf-Vi Vi-Vnfm Ve-Vnfm-em Ve-Vnfm-vnf Or-Vnfm Vn-Nf Os-Ma- nfvo Public
64 © Nokia 2018 • Lifecycle management: set of functions required to manage the instantiation, maintenance and termination of a VNF or NS • Scaling out/in: ability to scale by add/remove resource instances (e.g. VM) • Scaling up/down: ability to scale by changing allocated resource, e.g. increase/decrease memory, CPU capacity or storage size • Virtualisation Deployment Unit (VDU): construct that can be used in an information model, supporting the description of the deployment and operational behaviour of a subset of a VNF, or the entire VNF if it was not componentized in subsets NOTE: In the presence of a hypervisor, the main characteristic of a VDU is that a single VNF or VNF subset instance created based on the construct can be mapped to a single VM. A VNF may be modelled using one or multiple such constructs, as applicable. Public VNFM Terminology Source: ETSI GS NFV 003 V1.3.1
65 © Nokia 2018 • VNFM: - performs orchestration and management (i.e. Lifecycle management) functions of VNFs - responsible for maintaining of resources required for the operation of the VNF, not the function of the VNF - invoked by the NFVO - interacts with the Element Manager (EM) and the VNF for provisioning, configuration, and fault and alarm management - May manage one or more instances or even types of VNFs; the reality today is that VPF- specific VNFMs are required for a lot of VNFs MANO VFNM NS Catalog VNF Catalog NFV Instances NFVI Resources VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) NFV Orchestrator (NFVO) Or-Vi Vi-Vnfm Or-Vnfm Public
66 © Nokia 2018 • VNF life cycle management functions: - onboard a VNF - instantiate a VNF - scale a VNF - update a VNF - terminate a VNF Public MANO VNF Life Cycle Management (LCM) ONBOARD 1 DEPLOY 2 MONITOR3 SCALE 4 HEAL 5 UPDATE 6 TERMINATE 7 Life of a VNF
67 © Nokia 2018 • NFVO: - Two key functions: • orchestration functions of NFVI resources across multiple VIMs • lifecycle management of network services. - Has to ensure that there are sufficient compute, storage and network resources to provision a network service - interacts with the OSS/BSS for provisioning, configuration, capacity management, and policy-based management - Constructs and end-to-end service between one or more VNFs by communicating with VNFMs and VIMs MANO NFVO NS Catalog VNF Catalog NFV Instances NFVI Resources VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) NFV Orchestrator (NFVO) Or-Vi Vi-Vnfm Or-Vnfm Public
68 © Nokia 2018 • Network Service: composition of Network Function(s) and/or Network Service(s), defined by its functional and behavioural specification • Network Service Descriptor: template that describes the deployment of a Network Service including service topology (constituent VNFs and the relationships between them, Virtual Links, VNF Forwarding Graphs) as well as Network Service characteristics such as SLAs and any other artefacts necessary for the Network Service on-boarding and lifecycle management of its instances • Network Service Orchestration: subset of NFV Orchestrator functions that are responsible for Network Service lifecycle management Public NFVO Terminology (1) Source: ETSI GS NFV 003 V1.3.1
69 © Nokia 2018 • NF set: collection of NFs with unspecified connectivity between them • Network Forwarding Path (NFP): ordered list of connection points forming a chain of NFs, along with policies associated to the list • NF forwarding graph: graph of logical links connecting NF nodes for the purpose of describing traffic flow between these network functions • Virtual Link: set of connection points along with the connectivity relationship between them and any associated target performance metrics (e.g. bandwidth, latency, QoS). NOTE: The Virtual Link can interconnect two or more entities (VNF components, VNFs, or PNFs) and it is supported by a Virtual Network (VN) of the NFVI. • VNF Forwarding Graph (VNF FG): NF forwarding graph where at least one node is a VNF Public NFVO Terminology (2) Source: ETSI GS NFV 003 V1.3.1
70 © Nokia 2018 • An end-to-end network service (e.g. mobile voice/data, Internet access, a virtual private network) can be described by an NF Forwarding Graph of interconnected Network Functions (NFs) and end points. • A network service can be viewed architecturally as a forwarding graph of Network Functions (NFs) interconnected by supporting network infrastructure Public NFVO Network Service Source: ETSI GS NFV 002 V1.2.1
71 © Nokia 2018 NFVO Public Network Service with a nested forwarding graph Source: ETSI GS NFV 002 V1.2.1
72 © Nokia 2018 • Most current network services are defined by statically combining network functions in a way that can be expressed using an NF Forwarding Graph or NF Set construct. A major change brought by NFV is that virtualisation enables additional dynamic methods rather than just static ones to construct and manage the network function graphs or sets combining these network functions. A major focus of NFV is to enable and exploit the dynamic construction and management of network function graphs or sets. • VNF Forwarding Graph: covers the case where network connectivity between VNFs is specified, e.g. a chain of VNFs on the path to a web server tier (e.g. firewall, NAT, load balancer) • VNF Set covers the case where the connectivity between VNFs is not specified, e.g. a Web server pool, independent virtualised residential gateways Public NFVO Forwarding Graphs
73 © Nokia 2018 • Functions responsible for coordinating the lifecycle of VNFs that jointly realise a Network Service. Include: - on-boarding a Network Service - management of resources used by the Network Service - managing dependencies between different VNFs composing the Network Service - managing the forwarding graphs between the VNFs. Public NFVO Network Service Orchestration
74 © Nokia 2018 • Described by a set of descriptors: - VNF Descriptors (VNFD) - Network Service Descriptors (NSD) - VNF Forwarding Graph Descriptors (VNFFGD) - Virtual Link Descriptors (VLD). • Descriptors are essentially deployment templates that describe the resource and operational requirements for each of the above components Public NFVO Information Models
75 © Nokia 2018 VNF C VNF A VNF B PNF A PNF B VL Virtual Link: Logical connection between one or more VNFs [VLAN/VxLAN/subnet] CP Connection Point: Interface on a VNF/PNF which connects to the VL [vPort/vNIC/pNIC] VNFFG VNF Forwarding Graph: Defines traffic flows between VNFs within the NS NFP Network Forwarding Paths: Ordered list of CPs that form chains of VNFs with associated policies CP VL CP CPCP CP CP CP VL VL Network service VL CP VL CP CP NFVO Network Service Descriptor example
76 © Nokia 2018 MANO Public Industry Players ETSI Driving NFV specifications TMForum Next-gen OSS/BSS with virtualisation MEF Reference architectures for Lifecycle Service Orchestration (LSO) Linux Foundation Hosting large number of open- source NFV projects
77 © Nokia 2018 • Huge number of open-source initiatives to tackle this space: - ONAP (from a merging of Open-O and AT&T’s ECOMP [OpenECOMP]) - OSM - Tacker - OpenLSO - OpenBaton - Tacker • Many different approachs: - Some provide NFVO with a generic VNFM and VIM - Some provide an extensible plugin architecture for supporting different VNFMs and VIMs Public MANO Implementations
78 © Nokia 2018 • Large number of solutions , (overlapping) open-source and proprietary, are being developed • Elements outside of the NFV framework being identified as gaps • Increased importance of assurance capabilities being recognised • MANO ecosystem seen as immature and requiring considerable work • For operators to be able to exploit NFV capabilities, they have to be able to integrate their current OSS and BSS systems with their new NFV orchestration systems. This is an area of work that is still in its infancy. Public MANO Current market state
79 © Nokia 2018 • Lifecycle management of Network Services (NS) • Integration of OSS/BSS systems • Inter-operation in hybrid PNF/VNF environments • Certification for better portability of VNFs • Comprehensive assurance mechanisms Public MANO Evolution – Focus Areas
80 © Nokia 2018 use cases Public
81 © Nokia 2018 • Currently architected using purpose-built hardware for different functions such as PDN- GE, S-GW, HSS, MME etc • Opportunity to further decompose these functions • Allow independent scaling of each (sub-) function. • Already being deployed by a number of mobile operators worldwide • 5G mobile core likely to be exclusively based on virtualised deployment Public Use cases Virtualisation of EPC Source: ETSI GS NFV 001
82 © Nokia 2018 • Currently designed for peak-hour requirements. May be vastly unused during off-peak times • No mechanism to cost-effectively and dynamically provide additional capacity to handle unforeseen demand • Virtualisation allows CDN capacity to be dynamically scaled on demand • vCDN caches can be instantiated closer to users to reduce bandwidth requirement through the network Public Use cases Virtualisation of CDNs Source: ETSI GS NFV 001
83 © Nokia 2018 Use cases Public Virtualisation of the home environment Source: ETSI GS NFV 001 From… To…
84 © Nokia 2018 performance Public
85 © Nokia 2018 • Would an industry standard server be capable of supporting realistic network workloads ? • How can we provide provide predictable behaviour for new network functions ? • How can we achieve 99.999% service availability using server hardware with 99.9% availability ? • Ideally: - Hardware vendors would be agnostic to the VNFs that would end up running on their servers - VNF vendors would be able to provide a guarantee of predictable performance subject to minimal hardware requirements without explicit knowledge of actual hardware system they will run on i.e. VNF performance is predictable, consistent and vendor-agnostic Public Performance Challenges and expectations as identified during inception of NFV
86 © Nokia 2018 • Measures of performance: - Packet processing rates (bps, pps) - Processing latency - Jitter • Key difference between network services and traditional cloud-computing workloads is that they are more I/O-intensive. • Performance and scalability are important since the implementation of a VNF may have a per-instance capacity that is less than that of a corresponding physical network function on dedicated hardware. Therefore, methods are needed to split the workload across many distributed/clustered VNF instances. Public Performance
87 © Nokia 2018 • Two key approaches to improving performance: - CPU enhancements and acceleration technologies: • SR-IOV • DPDK • PCI-passthrough • Huge page support • CPU pinning - Hardware offload • Smart NICs with offloads for virtual switching, encryption, compression etc. • Co-processors • Intel QuickAssist Technology (QAT): hardware-based acceleration services for encryption and compression Public Performance Achieving higher performance
88 © Nokia 2018 open source Public
89 © Nokia 2018 • Number of operator-initiated open-source projects that were subsequently put into the public domain: - Open Source MANO (OSM): project initiated by Telefonica as OpenMANO, now hosted under ETSI - ONAP: result of merging of AT&T’s ECOMP and Open-O • Open Compute Platform (OCP) - Founded by Facebook, Intel and Rackspace - Applies open-source principals to hardware • Linux Foundation hosts the following NFV-related projects: - ONAP, OPNFV, ODL, FD.io, OVS, CORD, DPDK and many more • OpenStack Foundation • Telecom Infra Project (TIP): founded by Facebook Public Open source projects
90 © Nokia 2018 • Launched in September 2014 under the Linux Foundation • Objective is to create an open reference platform for NFV consisting of open hardware and software interfaces based on open source projects such as OpenDaylight, OpenStack etc. • Focused on system-level integration, deployment and testing to create a reference implementation rather than direct software development Public OPNFV
91 © Nokia 2018 • CORD = Central Office Re-architected as a Datacenter (CORD) • Founded by ON.Lab • Focusses on how traditional telco exchange architectures can be translated to a cloud environment Public CORD
92 © Nokia 2018 • ONAP: result of merging of AT&T’s ECOMP and Open-O • Open-O: - Joint effort between China Mobile, China Telecom and a number of vendors • ECOMP: - Developed by AT&T together with Amdocs Public ONAP
93 © Nokia 2018 state of industry Public Source: SDxCentral 2017 NFV Report Series Part I Foundations of NFV: NFV Infrastructure and VIM
94 © Nokia 2018 • In the 5 years since the inception of the ETSI NFV ISG, significant investment has been made in: - industry-standard commercial off-the-shelf (COTS) hardware - hypervisors and Virtualized Infastructure Managers (VIMs) - Virtual Network Functions (VNFs) - management and orchestration (MANO) Public Progress
95 © Nokia 2018 • A lot VNFs today are not truly cloud-optimised, being simple ports of PNFs (“NFV washing”). This is a necessary step, however, for the industry to start gaining experience with virtualisation without waiting for full, cloud-native functions. • Achieving high performance (for data-plane functions) remains a challenge. VNFs are shipping with vendor-specified minimum requirements for hardware. • The ability to use common hardware for all VNFs is not there yet. Extensive inter- operability testing is still required between VNFs and the underlying NFVI. • Licensing for VNFs is not as straightforward as the hardware-equivalent; VNFs have different characteristics and performance, can scale in and out and are a lot more dynamic. How do you price this ? • Managing VNFs (via the MANO infrastructure) is vastly different to managing network hardware. Newer skills will be required for operators. Public VNFs Current market state
96 © Nokia 2018 • Large number of solutions , (overlapping) open-source and proprietary, are being developed • Elements outside of the NFV framework being identified as gaps • Increased importance of assurance capabilities being recognised • MANO ecosystem seen as immature and requiring considerable work • For operators to be able to exploit NFV capabilities, they have to be able to integrate their current OSS and BSS systems with their new NFV orchestration systems. This is an area of work that is still in its infancy. Public MANO Current market state
97 © Nokia 2018 • For operators to be able to exploit NFV capabilities, they have to be able to link their current OSS and BSS systems to their new NFV orchestration systems. This is a big hurdle today: - OSS/BSS systems are complex and not geared for virtualization. - Operators are deeply invested in these systems so a straight replacement is neither practical nor economically viable. - The systems tend to be highly customized, often developed by their IT teams over many years; there is no one-size-fits-all making integration even more complex. - Even prior to the advent of NFV, OSS integration was a costly and complex exercise; NFV has the capability to simplify future integration but the OSS systems need to ”catch up” with the virtualized world first. - The MEF LSO framework is helping to bridge the gap between legacy OSS and BSS systems and NFV. Public OSS/BSS integration
98 © Nokia 2018 bibliography/references Public
99 © Nokia 2018 • NFV whitepapers: - http://portal.etsi.org/NFV/NFV_White_Paper.pdf - http://portal.etsi.org/NFV/NFV_White_Paper2.pdf - http://portal.etsi.org/NFV/NFV_White_Paper3.pdf • ETSI ISG specifications: http://www.etsi.org • Insights on current state of NFV industry have been quoted from: - SDxCentral 2017 NFV Report Series Part I Foundations of NFV: NFV Infrastructure and VIM - SDxCentral 2017 NFV Report Series Part 2: Orchestrating NFV - MANO and Service Assurance - SDxCentral 2017 NFV Report Series Part 3: Powering NFV - Virtual Network Functions (VNFs) Public Acknowledgements
Network Function Virtualisation: a tutorial

More Related Content

PPTX
NETCONF YANG tutorial
byTail-f Systems
 
PPTX
NFV +SDN (Network Function Virtualization)
byHamidreza Bolhasani
 
PPTX
Ericsson 5G learning portfolio 2018
byEricsson
 
PDF
MPLS L3 VPN Deployment
byAPNIC
 
PDF
6G: Potential Use Cases and Enabling Technologies
by3G4G
 
PDF
eTOM - Working Together - ITIL and eTOM v11.2.pdf
byChris Bian Ong
 
PDF
LTE KPI and PI Formula_NOKIA.pdf
byVahidZibakalam3
 
PDF
LTE: X2 interface
bySchwannden Kuo
 
NETCONF YANG tutorial
byTail-f Systems
 
NFV +SDN (Network Function Virtualization)
byHamidreza Bolhasani
 
Ericsson 5G learning portfolio 2018
byEricsson
 
MPLS L3 VPN Deployment
byAPNIC
 
6G: Potential Use Cases and Enabling Technologies
by3G4G
 
eTOM - Working Together - ITIL and eTOM v11.2.pdf
byChris Bian Ong
 
LTE KPI and PI Formula_NOKIA.pdf
byVahidZibakalam3
 
LTE: X2 interface
bySchwannden Kuo
 

What's hot

PDF
netconf, restconf, grpc_basic
byGyewan An
 
PDF
한국정보통신기술협회 5 g-b5g 표준기술 세미나-배포용
byYoungbeomKim5
 
PDF
Blueplanet Inventory & Federation - Alvaro Osle, blueplanet
byNeo4j
 
PDF
5 g core network and the cloud - A standards perspective
bySridhar Bhaskaran
 
PPTX
5gc call flow
byKoorosh Hoveyda
 
PPTX
5G End to-end network slicing Demo
byITU
 
PDF
netfilter and iptables
byKernel TLV
 
PDF
4G/5G RAN architecture: how a split can make the difference
byEricsson
 
PDF
End-to-End QoS in LTE
byRadisys Corporation
 
PDF
5 g core overview
byHemraj Kumar
 
PPTX
DC-HSPA+ technology
byNadisanka Rupasinghe
 
PPTX
NSA Mobility Managment.pptx
byErayUyanik
 
PDF
4G to 5G Evolution
byManoj Singh
 
PDF
3GPP SON Series: RACH Optimization
by3G4G
 
PDF
Beginners: Different Types of RAN Architectures - Distributed, Centralized & ...
by3G4G
 
PDF
3GPP SON Series: Mobility Load Balancing (MLB)
by3G4G
 
PPTX
Linux 802.11 subsystem and brcmsmac WLAN driver
byMidhun Lohidakshan
 
PDF
Mobile Network Sharing
by3G4G
 
PPTX
Introduction to CNI (Container Network Interface)
byHungWei Chiu
 
PDF
5G Network Architecture Options
by3G4G
 
netconf, restconf, grpc_basic
byGyewan An
 
한국정보통신기술협회 5 g-b5g 표준기술 세미나-배포용
byYoungbeomKim5
 
Blueplanet Inventory & Federation - Alvaro Osle, blueplanet
byNeo4j
 
5 g core network and the cloud - A standards perspective
bySridhar Bhaskaran
 
5gc call flow
byKoorosh Hoveyda
 
5G End to-end network slicing Demo
byITU
 
netfilter and iptables
byKernel TLV
 
4G/5G RAN architecture: how a split can make the difference
byEricsson
 
End-to-End QoS in LTE
byRadisys Corporation
 
5 g core overview
byHemraj Kumar
 
DC-HSPA+ technology
byNadisanka Rupasinghe
 
NSA Mobility Managment.pptx
byErayUyanik
 
4G to 5G Evolution
byManoj Singh
 
3GPP SON Series: RACH Optimization
by3G4G
 
Beginners: Different Types of RAN Architectures - Distributed, Centralized & ...
by3G4G
 
3GPP SON Series: Mobility Load Balancing (MLB)
by3G4G
 
Linux 802.11 subsystem and brcmsmac WLAN driver
byMidhun Lohidakshan
 
Mobile Network Sharing
by3G4G
 
Introduction to CNI (Container Network Interface)
byHungWei Chiu
 
5G Network Architecture Options
by3G4G
 

Similar to Network Function Virtualisation: a tutorial

PDF
NFV and OpenStack
byMarie-Paule Odini
 
PDF
Nfv short-course-sbrc14-full
byChristian Esteve Rothenberg
 
PDF
Network Functions Virtualization Fundamentals
byDamien Magoni
 
PPTX
Network Function Virtualization : Overview
bysidneel
 
PPTX
Software defined networking(sdn) vahid sadri
byVahid Sadri
 
PDF
Network function virtualization
bySatish Chavan
 
PDF
NFV Tutorial
byRashid Mijumbi
 
PDF
NFV & Openstack
byMarie-Paule Odini
 
PDF
Network Function Virtualization Orchestration LI
byKrishnamoorthy Arvind
 
PPTX
Modern Networking Unit 3 Network Function virtualization
byeticket4403
 
PDF
Why Network Functions Virtualization sdn?
byidrajeev
 
PDF
NFV Linaro Connect Keynote
byLinaro
 
PPTX
Feec telecom-nw-softwarization-aug-2015
byChristian Esteve Rothenberg
 
PDF
Software Defined Networks Network Function Virtualization Pivotal Technologies
byOpen Networking Summits
 
PDF
NFV - Telco Transformation Unfolded
byBangladesh Network Operators Group
 
PPTX
2017 dagstuhl-nfv-rothenberg
byChristian Esteve Rothenberg
 
PDF
7th SDN Expert Group Seminar - Session4
byNAIM Networks, Inc.
 
PDF
Service provider-considerations
byWeam Salem
 
PDF
NFV Tutorial
byRashid Mijumbi
 
PDF
Introduction to nfv movilforum
byvideos
 
NFV and OpenStack
byMarie-Paule Odini
 
Nfv short-course-sbrc14-full
byChristian Esteve Rothenberg
 
Network Functions Virtualization Fundamentals
byDamien Magoni
 
Network Function Virtualization : Overview
bysidneel
 
Software defined networking(sdn) vahid sadri
byVahid Sadri
 
Network function virtualization
bySatish Chavan
 
NFV Tutorial
byRashid Mijumbi
 
NFV & Openstack
byMarie-Paule Odini
 
Network Function Virtualization Orchestration LI
byKrishnamoorthy Arvind
 
Modern Networking Unit 3 Network Function virtualization
byeticket4403
 
Why Network Functions Virtualization sdn?
byidrajeev
 
NFV Linaro Connect Keynote
byLinaro
 
Feec telecom-nw-softwarization-aug-2015
byChristian Esteve Rothenberg
 
Software Defined Networks Network Function Virtualization Pivotal Technologies
byOpen Networking Summits
 
NFV - Telco Transformation Unfolded
byBangladesh Network Operators Group
 
2017 dagstuhl-nfv-rothenberg
byChristian Esteve Rothenberg
 
7th SDN Expert Group Seminar - Session4
byNAIM Networks, Inc.
 
Service provider-considerations
byWeam Salem
 
NFV Tutorial
byRashid Mijumbi
 
Introduction to nfv movilforum
byvideos
 

More from APNIC

PDF
IPv6 Deployment and Best Practices, presented by Makito Lay
byAPNIC
 
PDF
APNIC Update, presented at PHNOG 2025 by Shane Hermoso
byAPNIC
 
PDF
ICP -2 Review – What It Is, and How to Participate and Provide Your Feedback
byAPNIC
 
PDF
DNSSEC Made Easy, presented at PHNOG 2025
byAPNIC
 
PDF
Global Networking Trends, presented at the India ISP Conclave 2025
byAPNIC
 
PDF
Triggering QUIC, presented by Geoff Huston at IETF 123
byAPNIC
 
PDF
The Internet - By the numbers, presented at npNOG 11
byAPNIC
 
PPTX
APNIC Report, presented at APAN 60 by Thy Boskovic
byAPNIC
 
PDF
DDoS in India, presented at INNOG 8 by Dave Phelan
byAPNIC
 
PDF
Make DDoS expensive for the threat actors
byAPNIC
 
PDF
APNIC's Role in the Pacific Islands, presented at Pacific IGF 2205
byAPNIC
 
PDF
DDos Mitigation Strategie, presented at bdNOG 19
byAPNIC
 
PDF
Transmission Control Protocol (TCP) and Starlink
byAPNIC
 
PDF
Measuring Starlink Protocol Performance, presented at LACNIC 43
byAPNIC
 
PDF
APNIC Update - Global Synergy among the RIRs: Connecting the Regions
byAPNIC
 
PDF
BGP Security Best Practices that Matter, presented at PHNOG 2025
byAPNIC
 
PDF
The Internet -By the Numbers, Sri Lanka Edition
byAPNIC
 
PDF
Cleaning up your RPKI invalids, presented at PacNOG 35
byAPNIC
 
PDF
RPKI Status Update, presented by Makito Lay at IDNOG 10
byAPNIC
 
PDF
Fast Reroute in SR-MPLS, presented at bdNOG 19
byAPNIC
 
IPv6 Deployment and Best Practices, presented by Makito Lay
byAPNIC
 
APNIC Update, presented at PHNOG 2025 by Shane Hermoso
byAPNIC
 
ICP -2 Review – What It Is, and How to Participate and Provide Your Feedback
byAPNIC
 
DNSSEC Made Easy, presented at PHNOG 2025
byAPNIC
 
Global Networking Trends, presented at the India ISP Conclave 2025
byAPNIC
 
Triggering QUIC, presented by Geoff Huston at IETF 123
byAPNIC
 
The Internet - By the numbers, presented at npNOG 11
byAPNIC
 
APNIC Report, presented at APAN 60 by Thy Boskovic
byAPNIC
 
DDoS in India, presented at INNOG 8 by Dave Phelan
byAPNIC
 
Make DDoS expensive for the threat actors
byAPNIC
 
APNIC's Role in the Pacific Islands, presented at Pacific IGF 2205
byAPNIC
 
DDos Mitigation Strategie, presented at bdNOG 19
byAPNIC
 
Transmission Control Protocol (TCP) and Starlink
byAPNIC
 
Measuring Starlink Protocol Performance, presented at LACNIC 43
byAPNIC
 
APNIC Update - Global Synergy among the RIRs: Connecting the Regions
byAPNIC
 
BGP Security Best Practices that Matter, presented at PHNOG 2025
byAPNIC
 
The Internet -By the Numbers, Sri Lanka Edition
byAPNIC
 
Cleaning up your RPKI invalids, presented at PacNOG 35
byAPNIC
 
RPKI Status Update, presented by Makito Lay at IDNOG 10
byAPNIC
 
Fast Reroute in SR-MPLS, presented at bdNOG 19
byAPNIC
 

Recently uploaded

PDF
Modernize everything Microsoft session.pdf
byjeyfox1
 
PDF
Dublin Core Metadata : Library’s Digital DNA
byDeepanshu Kumar Yadav
 
PDF
The Role of Micro-interactions in Modern Web Design
bydigitalcrafters0810
 
PPTX
Victoria University Transcripts
byvgki5qphpa
 
PDF
Top 7 Instagram Monitoring Apps of 2025 – Feature Overview
byMichael Carter
 
PDF
Enshittification and the Current State of UX/Product
byAndrew Turnbull
 
PPTX
Universidad Internacional Villanueva Transcripts
bynxv6x4gd42
 
DOCX
Get Verified Payeer Accounts_ Complete Payeer Account Verification Guide (202...
byBEST IT SMM
 
PDF
2025 Archive - Zsolt Nemeth web blogging
byZsolt Nemeth
 
PDF
How to Verify Someone from Dating or Marketplace Apps
bySocial Searcher
 
PDF
Network Security Services for Businesses: 5 Simple Ways to Protect Your Network
byPreemptive Technofield
 
Modernize everything Microsoft session.pdf
byjeyfox1
 
Dublin Core Metadata : Library’s Digital DNA
byDeepanshu Kumar Yadav
 
The Role of Micro-interactions in Modern Web Design
bydigitalcrafters0810
 
Victoria University Transcripts
byvgki5qphpa
 
Top 7 Instagram Monitoring Apps of 2025 – Feature Overview
byMichael Carter
 
Enshittification and the Current State of UX/Product
byAndrew Turnbull
 
Universidad Internacional Villanueva Transcripts
bynxv6x4gd42
 
Get Verified Payeer Accounts_ Complete Payeer Account Verification Guide (202...
byBEST IT SMM
 
2025 Archive - Zsolt Nemeth web blogging
byZsolt Nemeth
 
How to Verify Someone from Dating or Marketplace Apps
bySocial Searcher
 
Network Security Services for Businesses: 5 Simple Ways to Protect Your Network
byPreemptive Technofield
 

Network Function Virtualisation: a tutorial

  • 1.
    1 © Nokia2018 Network Function Virtualisation Public A tutorial • Paresh Khatri • Feb 27, 2018
  • 2.
    2 © Nokia2018 1. Introduction 2. Virtualisation for network engineers: a primer 3. ETSI NFV ISG Framework: a. NFVI b. MANO c. VNFs 4. Performance 5. Open source 6. State of industry Public Agenda
  • 3.
    3 © Nokia2018 introduction Public
  • 4.
    4 © Nokia2018 Public Specialization versus generalization … repeating cycle of technology evolution Specialization Generalization • Ability to finely tune and optimize for high performance • High efficiency • Limited to specific functions • Limited flexibility • Higher cost due to reduced economies of scale • Flexibility – ability to perform multiple, diverse functions • Lower cost due to economies of scale • Not overly efficient at any one particular task • Lower efficiency and performance … NFV is the latest phase in this cycle
  • 5.
    5 © Nokia2018 Public The evolution of the humble router 1969 Interface Message Processor (IMP) • Router for the first TCP/IP network – ARPANET • Ruggedized Honeywell DDP-516 minicomputer • Special-purpose interfaces and software 1981 Multi-protocol routers • Stanford/MIT researchers • IP/AppleTalk/DECnet/ Xerox protocols • General-purpose mini-computers Late 1990s Internet-scale routers • Very-high throughput based on specialised forwarding ASICs • Optimized for IP Early 2000s Multi-service routers • Continued hardware evolution • Programmable network processors • Optimized for multi- services over IP Basic packet processing in software Addition of QoS, access control, control plane protocols Optimization of hardware for line- rate performance Programmable hardware, massive parallel processing, L4-7 services
  • 6.
    6 © Nokia2018 When faced with new or different problems, “we” have… Public Solving network-layer problems developed new protocols optimised with new hardware
  • 7.
    7 © Nokia2018 So what’s the problem, really ? Anatomy of a telco application (ATCA) System Control & Management Cards ® Specialised OAM middleware I/O and load distribution ® Specialised application middleware Application Function A ® More cards for more capacity Application Function B ® More (different) cards for more capacity Specialised blades with dedicated processors ® Many different/specialised OS’s Standard components in specialised configuration => ‘box scaling rules’ ATCA = Advanced Telecommunications Computing Architecture Public
  • 8.
    8 © Nokia2018 The world before NFV Pre-NFV • Specialized network software running on purpose-built hardware (ASICs, NPUs) • Different devices generally required for different functions • Each function is independently dimensioned, scaled and deployed. • Lifecycles dictated primarily by hardware evolution Public
  • 9.
    9 © Nokia2018 Public A call to action… • Seminal white paper written by representatives of 13 major carriers • Published at the “SDN and OpenFlow World Congress”, Darmstadt-Germany in October 2012 … and thus, NFV was born http://portal.etsi.org/NFV/NFV_White_Paper.pdf
  • 10.
    10 © Nokia2018 • White paper 2 (http://portal.etsi.org/NFV/NFV_White_Paper2.pdf): - Published October 15-17, 2013 at the “SDN and OpenFlow World Congress”, Frankfurt-Germany. - Provided an update on the work of the ETSINFV ISG and a summary of the documents produced thus far - Highlighted need for standardisation of interfaces (reference points) between various elements of the reference architecture • White paper 3 (http://portal.etsi.org/NFV/NFV_White_Paper3.pdf): - October 14-17, 2014 at the “SDN & OpenFlow World Congress”, Dusseldorf-Germany. Public Follow-up white papers http://portal.etsi.org/NFV/NFV_White_Paper.pdf
  • 11.
    11 © Nokia2018 • Large numbers of diverse, proprietary hardware appliances. • Increasing costs of energy, capital investment challenges difficulties in finding skillsets to support ever more complex network architectures Public Challenges articulated by operators • New network services require newer varieties of hardware with the resultant requirement for space and power • Relatively small lifetime of hardware- based appliances (getting shorter all the time) necessitating an endless cycle of procure-design-integrate- deploy hardware Roll-out of new services is slow
  • 12.
    12 © Nokia2018 disaggregation /dɪsˈaɡrɪɡeɪʃ(ə)n/ noun past tense: disaggregated; past participle: disaggregated separate (something) into its component parts. usage: "a method for disaggregation of large conglomerates" Public Disaggregation Definition In a networking context: Disaggregation is the process of decomposing the elements of an integrated system into discrete, individual components so that they may be individually sourced to provide an optimal mix of software and hardware
  • 13.
    13 © Nokia2018 Public NFV disaggregation The basic model • Consolidation of different types of network equipment onto industry- standard high-volume servers, storage and switches. Vertically Integrated System NFV Network Function Purpose- built Hardware Virtual Network Function COTS Hardware Basic Premise (Simplified)
  • 14.
    14 © Nokia2018 NFV vs SDN SDN Monolithic switches/routers Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Standard high volume servers, storage, switches Orchestrated, automatic & remote lifecycle management SDN Controller Network Mgmt Programmability, separate control plane, centralized view NFV Physical appliances Public
  • 15.
    15 © Nokia2018 Public SDN disaggregation The basic model Net- work Apps Net- work Apps Net- work Apps VERTICALLY INTEGRATED SYSTEM SDN Network Apps Forwarding Hardware Northbound Interfaces Southbound Interfaces FORWARDING PLANE ELEMENTS CONTROL PLANE ELEMENTS APPLICATION PLANE ELEMENTS Network Apps Network Apps Network Operating SystemNetwork Operating System Forwarding Hardware Lightweight OS Forwarding Hardware Lightweight OS Forwarding Hardware Lightweight OS
  • 16.
    16 © Nokia2018 NFV: challenging the status quo Public Why NFV? NFV Key premises: • Decouple hardware from software • Use COTS hardware SERVICE VELOCITY Reduce time-to-market of new services OPENNESS Reduce vendor lock-in MULTI-TENANCY Greater efficiency of network usage OPERATIONAL EFFICIENCY Homogeneity of physical elements, elasticity Optimize network resources, Reduce opex, Open ecosystem IMPROVED NETWORK ECONOMICS
  • 17.
    17 © Nokia2018 Enablers Public Cloud Computing • Hardware virtualisation via hypervisors • Virtual (software-based) Ethernet switches • Multi-core CPUs • Smart Ethernet NICs • Poll-mode drivers • Compute management systems for lifecycle management of VMs • Open APIs for management COTS Hardware • Economies of scale of compute platforms • Competitive market for server components, avoiding vendor lock-in • Improving performance over time
  • 18.
    18 © Nokia2018 • Development of virtualized applications that are portable between different hypervisors, hardware etc. • Inter-working in a mixed virtual-physical environment • Evolution of OSS/BSS systems to support virtualised systems • Management and orchestration of virtual appliances • Achieving acceptable performance and resilience compared to hardware-based functions • Support of multi-vendor environments Public Perceived challenges Significant challenges would have to be surmounted
  • 19.
    19 © Nokia2018 • A new operator-led Industry Specification Group (ISG) was set up under ETSI to support NFV development • While ETSI is an SDO, the objective of the ISG was not to produce standards but to identify requirements and develop architectures. It would reference the work of other SDOs as required. • Produced the following (release 1 documents): - NFV Use Cases document - NFV Requirements document - NFV Architectural Framework document - NFV Terminology document - NFV Proof-of-concept framework Public Consequences Formation of ETSI NFV ISG
  • 20.
    20 © Nokia2018 Original 2-year term of the ISG expired in early 2015. • Extended for an additional 2 years with the objective of: - Completion of the definition of key interface specifications to allow inter-operable implementations of NFV components: • Orchestrator <-> VIM • Orchestrator <-> VNF • VNFM <-> VNF • VNF <-> NFVI - Study of how NFV infrastructures will interact with legacy OSS/BSS systems • How OSS/BSS systems need to evolve to support NFV • OSS/BSS <-> Orchestrator interface • OSS/BSS <-> Element manager interface Public ETSI NFV ISG Phase 2
  • 21.
    21 © Nokia2018 • Elaborated on requirements, information models and interface specifications for key interfaces identified in the reference architectures • Produced the following Release 2 documents in early 2015: - NFVI: • NFV Infrastructure Overview • NFV Compute Domain • NFV Hypervisor Domain • NFV Infrastructure Network Domain - Management and Orchestration document • Detailed functionality of NFVO, VNFM and VIM • Phase 3: - Third 2-year period of work ongoing with a view to producing Release 3 documents Public ETSI NFV ISG Release 2
  • 22.
    22 © Nokia2018 virtualisation for network engineers: a primer Public
  • 23.
    23 © Nokia2018 • Motivation: - Better use of hardware resources: significant waste of compute resources when using bare-metal server. - Requirement to be able to pool hardware resources and get better efficiency. - Reduce power and space requirements via consolidation - Ability to ship applications as a package that can run anywhere • Requirements: - Isolation between different applications sharing server hardware - Isolation (or allocation) of resources to different applications sharing the hardware platform - No significant loss of performance Public Server virtualisation
  • 24.
    24 © Nokia2018 • Emulation - Make one system behave like or imitate a different one; software mimicking hardware - Take an entire system and make it run on a platform it was not designed for (includes totally different CPU architectures) (Example: play your Sega Megadrive games on your PC) - Huge performance impact - Very useful for ensuring the continuation of required legacy hardware/software and for migrations Public Virtualisation Overview Types of Virtualisation (1) VM HWHW VMM VM Real driver XReal driver X Real driver Y Emulated HW
  • 25.
    25 © Nokia2018 • (Full) Virtualisation - Known as many things (HVM, Accelerated Virtualisation, Hardware Assisted Virtualisation, Native Virtualisation)…essentially emulation, but with support of virtualization in hardware - Hypervisor: software that allows hosting of multiple “virtual machines” on a single guest machine by turning physical resources into logical resources which can be supplied/requested to/from guests e.g KVM - Guest operating system is unaware that it is operating in a virtualized environment and therefore, requires no modification to operate in the virtualised environment; Guests use unmodified drivers to connect to the virtualised resources Public Virtualisation Overview Types of Virtualisation (2) - Host and Guest architectures must be the same architecture (e.g. x86_64) - Calls to hardware need to be intercepted by the hypervisor - Hardware support for virtualization is required e.g. Intel VT-x VM Real driver HW VM Real driver HW VM Real driver HW VMM HW VM Real driver (As seen by VM) (As seen by VMM)
  • 26.
    26 © Nokia2018 • Para-Virtualisation (PV) - The code of an operating system is modified in order to allow that operating system to run as a guest; most OS’s today ship with para-virtualization interfaces - Rather than calls directly being made by the guest to hardware, which are then intercepted by the hypervisor (or Virtual Machine Monitor, VMM) and converted, the calls are instead made from the guest directly to the VMM Public Virtualisation Overview Types of Virtualisation (3) - The guest is aware that it is running in a virtualized system. - Can provide better performance than full (software-based) virtualization - The VMM is aware of the requirements on the guest(s) and can manage resources accordingly - For high I/O where the guest knows that it is virtualised (most situations these days) para-virtualisation (VirtIO drivers on KVM, VMware Tools on VMware ) can be used Driver itf VM modified driver HWHW VMMReal driver VM modified driver Driver itf
  • 27.
    27 © Nokia2018 • Hybrid Virtualisation - Combination of para-virtualisation for some hardware functions (e.g. virtio for I/O) and full virtualisation for others. - Can provide better performance without requiring full para-virtualization - Can provide the best of both worlds - Example: KVM uses hardware virtualization extensions but also supports para-virtualisation driver for network devices (via virtio) etc. Public Virtualisation Overview Types of Virtualisation (4)
  • 28.
    28 © Nokia2018 • Also know as a Virtual Machine Monitor (VMM) • Software that allows hosting of multiple “virtual machines” on a single guest machine by turning physical resources into logical resources which can be supplied/requested to/from guests • Interfaces with the physical host hardware allowing it to be presented to multiple virtualised guests • Marshals the sharing of resources between guests (access to CPU, GPU, memory and other hardware) Public Virtualisation Overview Hypervisors
  • 29.
    29 © Nokia2018 Type 1: Native Hypervisor Virtualisation Overview Hypervisors (1) Hardware Native Hypervisor Virtual Hardware Virtual Hardware Virtual Hardware Spare Guest Operating System (VNF) Guest Operating System (VNF) Guest Operating System (VNF) Public Type 1: Native/Bare-Metal Hypervisors Examples: VMware ESXi, Microsoft Hyper-V, Citrix XEN The host operating system is the Hypervisor software. Hypervisor has direct access to all hardware and features of the underlying machine.
  • 30.
    30 © Nokia2018 Hardware Conventional (Host) Operating System Virtual Hardware Virtual Hardware Virtual Hardware Hosted Hypervisor Apps on Host Operating System Guest Operating System (VNF) Guest Operating System (VNF) Guest Operating System (VNF) Virtualisation Overview Hypervisors (2) Public Type 2: Hosted Hypervisors Examples: VMware Workstation, Parallels, Oracle Virtual Box Relies on the underlying host operating system for access to the hardware. If the underlying host O/S develops an issue the guests can fail. More resource overhead than Type-1 hypervisors [Linux KVM is actually a kernel module that converts the operating system to a type-1 hypervisor so can be said to exhibit characteristics of both type-1 and type-2 hypervisors] Type 2: Hosted Hypervisor
  • 31.
    31 © Nokia2018 Virtualisation Overview Common Hypervisors Public
  • 32.
    32 © Nokia2018 • VM-based virtualisation operates at a hardware-level i.e. it attempts to provide a distinct, virtual hardware environment for each VM. • Containers are a new approach that provides separate operating environments for each application via a single, shared kernel i.e. OS- virtualisation instead of machine virtualisation • Uses Linux kernel features cgroups and namespaces, which provide an isolated execution environment with its own PID space, network device, filesystems, CPU, RAM etc. Public Containers Containers Hardware Host operating system kernel Container 1 Container 2 Container 3 Container 4 App App App App Container engine Bins/ Libraries Bins/ Libraries Bins/ Libraries Bins/ Libraries
  • 33.
    33 © Nokia2018 • Advantages over VMs: - No duplication of operating system resources - VMs have higher overheads (each VM is a complete machine) - Smaller and light-weight - Higher scale - Faster loading times • Challenges: - Isolation and sharing concerns need to be resolved; VMs provide much better isolation as each VM operates in a separate, virtual hardware context. - All containers on a single hardware server must use the same operating system and kernel • Outlook: - Use cases exist for both VM and container applications; hard to see containers completely replacing VMs in the near future Public Containers Comparing and contrasting with VMs
  • 34.
    34 © Nokia2018 • LXC • Docker(Uses LXC) • OpenVz • Parallels Virtuozzo • Solaris Containers • HP-UX containers Public Containers Implementations
  • 35.
    35 © Nokia2018 Leverage: Agility & Cost Effectiveness EXTEND Real-time and 5 9s Distributed Architecture Unrestricted Networking Optimized Operations Security IT Best Practices Open Source SW Commodity HW Cloud Technology Data Centre Technology What makes NFV different from public cloud? Public
  • 36.
    36 © Nokia2018 etsi nfv reference architecture Public
  • 37.
    37 © Nokia2018 Public NFV disaggregation The basic model NFV Vertically Integrated System Network Function Purpose- built Hardware Virtual Network Function COTS Hardware Basic Premise (Simplified) `VNF Virtual Network Functions (VNFs) VNF VNF NFV Infrastructure (NFVI) Virtual Compute Virtual Storage Virtual Network Virtualization Layer Storage Hardware Network Hardware Compute Hardware NFVManagement& Orchestration(MANO) ETSI High-level NFV Framework
  • 38.
    38 © Nokia2018 High-level ETSI NFV Framework ETSI GS NFV 002 Public NFV Management and Orchestration (MANO) Virtual Network Functions (VNFs) VNF VNF VNF VNF VNF NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage Source: ETSI GS NFV 002 Underlying physical resources Virtualised resources Virtualised instances of network functions All tasks required for management of the VNF lifecycle Hypervisor, containers etc
  • 39.
    39 © Nokia2018 • In charge of orchestration and management of NFV infrastructure, software resources and realizing network services. • Network Service lifecycle management. Responsible for VNF lifecycle management (e.g. instantiation, update, query, scaling, termination)NS Catalog VNF Catalog NFV Instances NFVI Resources OSS/BSS EM VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) NFV Orchestrator (NFVO) VNF NFV Infrastructure (NFVI) Execution reference points Other reference points Main NFV reference points NFV MANO Or-ViNf-Vi Vi-Vnfm Ve-Vnfm-em Ve-Vnfm-vnf Or-Vnfm Vn-Nf Os-Ma- nfvo ETSI NFV E2E Architecture ETSI GS NFV-MAN 001 Controls and manages the interaction with the virtualized infrastructure (compute, network and storage resources) All hardware and software components which build up the environment in which VNFs are deployed, managed and executed Public
  • 40.
    40 © Nokia2018 etsi nfv reference architecture nfvi Public
  • 41.
    41 © Nokia2018 • All of the hardware and software components which provide the environment in which VNFs are deployed • Provides virtual resources required to run VNFs; includes COTS hardware, accelerator components and a software layer which virtualizes and abstracts the underlying hardware. • Multi-tenant environment Public NFVI Framework
  • 42.
    42 © Nokia2018 NFVI Public Framework Virtualised Infrastructure Manager (VIM) May include SDN controller for network virtualisation Virtual Network Functions (VNFs) VNF VNF VNF VNF VNF Vn-Nf Nf-Vi NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage Underlying physical resources Virtualised resources Hypervisor, containers etc
  • 43.
    43 © Nokia2018 • Hardware resources - compute: - VNF requirements still dictate server specifications • Key challenge as a one-size-fits-all-VNFs policy could result in over-engineered servers, with impact on TCO and large amounts of unused capacity - Typically rack servers but blade servers also popular - Dominated by Intel (Intel has >90% market share in servers) • Intel Xeon E5-2600 processors offering good price vs performance characteristics Public NFVI Hardware resources NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
  • 44.
    44 © Nokia2018 • Hardware resources - storage: - Particularly important for storage-intensive VNFs such as caching, analystics - Direct Attached Storage (DAS) • Attached directly to the server - Network Attached Storage (NAS) • Provides network access to file-level data storage - Storage Area Network (SAN) • Provides network access to block-level data storage - Software-Defined Storage (SDS) • Akin to SDN for networks • Separates management and control software from underlying storage hardware (industry-standard storage-optimized servers) Public NFVI Hardware resources NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
  • 45.
    45 © Nokia2018 • Hardware resources - network: - Traditional, proprietary L2 or L3 switches - Open, industry-standard, switches: • bare-metal switches • white-box switches • brite-box switches (brite = branded white-box, a Gartner-coined term) Public NFVI Hardware resources NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
  • 46.
    46 © Nokia2018 Public NFVI Virtualisation layer • Hypervisor sits on top of the hardware resources and provides a mechanism to share them across virtual machines (VMs) • Abstracts and logically partitions physical resources - Emulates a physical machine for each VM - Provides isolation between VMs - Emulates NIC cards for each VM • Major deployments based on KVM and Vmware vSphere - Others include Oracle XEN and Microsoft Hyper-V • Emphasis has been on virtual machines but containers are now being looked at as a future option NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
  • 47.
    47 © Nokia2018 • Virtualised CPU (vCPU): virtualised CPU created for a VM by a hypervisor • Virtualised NIC (vNIC): virtualised NIC created for a VM by a hypervisor • Virtualised Switch (vSwitch): Ethernet switch implemented by the hypervisor that interconnects vNICs of VMs with each other and with the NIC of the compute node Public NFVI Terminology Source: ETSI GS NFV 003 V1.3.1
  • 48.
    48 © Nokia2018 • Virtual resources - compute: - Created by the hypervisor - APIs to support VM lifecycle actions: create, start, stop, pause, shutdown, migrate, delete, manage etc. Public NFVI Virtual resources - compute NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
  • 49.
    49 © Nokia2018 • Virtual resources - network: - Software switch or router on the hypervisor - Functions: • Allows communication between VMs • Tunneling for overlay services • ACLs • Distributed routing - Switching solutions: • OpenVSwitch (OVS) • FD.io (“fido”) • vSphere Distributed Switch (VDS) - Data-plane acceleration technologies: • DPDK • OpenDataPlane (ODP) Public NFVI Virtual resources - network NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage
  • 50.
    50 © Nokia2018 • Hardware: - Specialised I/O processors - Smart NICs: ability to offload functions such as ACL, tunnel encapsulation/decapsulation, switching, encryption and acceleration from the CPU • Virtualisation layer: - Maturation of container technology (use of Operating System virtualization instead of virtual machine virtualization. - Concerns around isolation need to be addressed Public NFVI What’s next ?
  • 51.
    51 © Nokia2018 VIM Public Framework Virtualised Infrastructure Manager (VIM) Or-Vi NFV Infrastructure (NFVI) Orchestrator VNFM Nf-Vi Vi-Vnfm • VIM - Manages the NFV Infrastructure (NFVI), performance and fault management - Maintains inventory of hardware and software resources - Maintains inventory of allocation of virtual resources to physical resources - Manages lifecycle of virtual resources - Interacts with MANO layer
  • 52.
    52 © Nokia2018 • Two dominant solutions today: - OpenStack - Vmware vCloud Director (vCD) • New solution focus areas: - Seamless integration with MANO and automation solutions - Management of containers and bare metal in addition to VMs • Emerging solutions: - OpenVIM: part of OpenMANO, lightweight VIM - Kubernetes: container orchestration project that came out of Google, now under the Linux Foundation Public VIMs
  • 53.
    53 © Nokia2018 etsi nfv reference architecture vnfs Public
  • 54.
    54 © Nokia2018 VNFs Public NFV Management and Orchestration (MANO) Virtual Network Functions (VNFs) VNF VNF VNF VNF VNF NFV Infrastructure (NFVI) Virtualisation Layer Virtual Compute Virtual Network Virtual Storage Hardware Resources Compute NetworkStorage Source: ETSI GS NFV 002 software implementation of a network function which is capable of running over the NFVI. Corresponds to the software component of today’s network devices, delivered as pure software that is hardware- independent (or at least capable of running on industry-standard servers) Physical Network Function (PNF): physical version of a network function i.e. a network function designed to run on purpose-built hardware
  • 55.
    55 © Nokia2018 • Network Function (NF): functional block within a network infrastructure that has well- defined external interfaces and well-defined functional behavior; network node or physical appliance today e.g. BNG, firewall, IDS, IPS • Physical Network Function (PNF): implementation of a NF via a tightly coupled software and hardware system • Virtualised Network Function (VNF): implementation of an NF that can be deployed on a Network Function Virtualisation Infrastructure (NFVI) Public VNFs Terminology Source: ETSI GS NFV 003 V1.3.1
  • 56.
    56 © Nokia2018 • Virtualised Network Function Component (VNFC): internal component of a VNF providing a VNF Provider a defined sub-set of that VNF's functionality, with the main characteristic that a single instance of this component maps 1:1 against a single Virtualisation Container • Virtualised Network Function Descriptor (VNFD): configuration template that describes a VNF in terms of its deployment and operational behaviour, and is used in the process of VNF on-boarding and managing the lifecycle of a VNF instance Public VNFs Terminology Source: ETSI GS NFV 003 V1.3.1
  • 57.
    57 © Nokia2018 VM • Functional behaviour and state of a NF are largely independent of whether the NF is virtualised or not. The functional behaviour and the external operational interfaces of a Physical Network Function (PNF) and a VNF are expected to be the same. • A VNF can be composed of multiple internal components. For example, one VNF can be deployed over multiple VMs, where each VM hosts a single component of the VNF. However, in other cases, the whole VNF can be deployed in a single VM as well. Public VNFs Decomposition VNFC 1 VNF 1 VM VNFC 2b VNF 2 VM VNFC 2a VM VNFC 2c Simple VNF Composite VNF
  • 58.
    58 © Nokia2018 • Tends to be focussed more on L4-L7 functions today. • Top NFV use cases today are CPE virtualisation and mobile core virtualisation. Public VNFs Key functions vCPE Move fast evolving functions into the cloud vEPC Easy deployment of customer specific mobile services vDNS,vFW Virtualizatio n of simple network appliances vIMS Rapid deployment of new communicat ions services
  • 59.
    59 © Nokia2018 • A simple porting of a network function from a proprietary hardware element to a virtualised version capable of running on industry-standard servers is not sufficient: - Unless network functions are optimised for the hardware on which they are intended to run, they will not deliver a level of performance that makes the transition economically viable; low-level code needs to be re-written to be able to enhance performance, particularly for data-plane-intensive functions - To truly achieve the benefits of virtualisation, monolithic applications may need to be disaggregated into their constituent components, leading to an architecture that is more cloud- native - New horizontal scaling mechanisms need to be introduced, something that is not readily realised in today’s hardware-based systems Public VNFs Porting
  • 60.
    60 © Nokia2018 VNFs VNF Descriptor Template Node template Relationship template Group Inputs Outputs node_templates: rra: type: tosca.nodes.Compute properties: num_cpus: 2 mem_size: 2048 image_name: { get_input: ImageName } keypair_name: { get_input: keypair_input } (De-facto) standards: • OpenStack HOT • OASIS TOSCA VNF Descriptor (VNFD): A template describing the application specifics and topology Public
  • 61.
    61 © Nokia2018 • A lot VNFs today are not truly cloud-optimised, being simple ports of PNFs (“NFV washing”). This is a necessary step, however, for the industry to start gaining experience with virtualisation without waiting for full, cloud-native functions. • Achieving high performance (for data-plane functions) remains a challenge. VNFs are shipping with vendor-specified minimum requirements for hardware. • The ability to use common hardware for all VNFs is not there yet. Extensive inter- operability testing is still required between VNFs and the underlying NFVI. • Licensing for VNFs is not as straightforward as the hardware-equivalent; VNFs have different characteristics and performance, can scale in and out and are a lot more dynamic. How do you price this ? • Managing VNFs (via the MANO infrastructure) is vastly different to managing network hardware. Newer skills will be required for operators. Public VNFs Challenges
  • 62.
    62 © Nokia2018 etsi nfv reference architecture mano Public
  • 63.
    63 © Nokia2018 • Purpose of the MANO function is to: - Manage and orchestrate VNFs - Manage and orchestrate NFV infrastructure …in order to allow NFV Network Services (chain of VNFs and/or PNFs) to be created, maintained and destroyed MANO NS Catalog VNF Catalog NFV Instances NFVI Resources OSS/BSS EM VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) NFV Orchestrator (NFVO) VNF NFV Infrastructure (NFVI) Execution reference points Other reference points Main NFV reference points Or-ViNf-Vi Vi-Vnfm Ve-Vnfm-em Ve-Vnfm-vnf Or-Vnfm Vn-Nf Os-Ma- nfvo Public
  • 64.
    64 © Nokia2018 • Lifecycle management: set of functions required to manage the instantiation, maintenance and termination of a VNF or NS • Scaling out/in: ability to scale by add/remove resource instances (e.g. VM) • Scaling up/down: ability to scale by changing allocated resource, e.g. increase/decrease memory, CPU capacity or storage size • Virtualisation Deployment Unit (VDU): construct that can be used in an information model, supporting the description of the deployment and operational behaviour of a subset of a VNF, or the entire VNF if it was not componentized in subsets NOTE: In the presence of a hypervisor, the main characteristic of a VDU is that a single VNF or VNF subset instance created based on the construct can be mapped to a single VM. A VNF may be modelled using one or multiple such constructs, as applicable. Public VNFM Terminology Source: ETSI GS NFV 003 V1.3.1
  • 65.
    65 © Nokia2018 • VNFM: - performs orchestration and management (i.e. Lifecycle management) functions of VNFs - responsible for maintaining of resources required for the operation of the VNF, not the function of the VNF - invoked by the NFVO - interacts with the Element Manager (EM) and the VNF for provisioning, configuration, and fault and alarm management - May manage one or more instances or even types of VNFs; the reality today is that VPF- specific VNFMs are required for a lot of VNFs MANO VFNM NS Catalog VNF Catalog NFV Instances NFVI Resources VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) NFV Orchestrator (NFVO) Or-Vi Vi-Vnfm Or-Vnfm Public
  • 66.
    66 © Nokia2018 • VNF life cycle management functions: - onboard a VNF - instantiate a VNF - scale a VNF - update a VNF - terminate a VNF Public MANO VNF Life Cycle Management (LCM) ONBOARD 1 DEPLOY 2 MONITOR3 SCALE 4 HEAL 5 UPDATE 6 TERMINATE 7 Life of a VNF
  • 67.
    67 © Nokia2018 • NFVO: - Two key functions: • orchestration functions of NFVI resources across multiple VIMs • lifecycle management of network services. - Has to ensure that there are sufficient compute, storage and network resources to provision a network service - interacts with the OSS/BSS for provisioning, configuration, capacity management, and policy-based management - Constructs and end-to-end service between one or more VNFs by communicating with VNFMs and VIMs MANO NFVO NS Catalog VNF Catalog NFV Instances NFVI Resources VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) NFV Orchestrator (NFVO) Or-Vi Vi-Vnfm Or-Vnfm Public
  • 68.
    68 © Nokia2018 • Network Service: composition of Network Function(s) and/or Network Service(s), defined by its functional and behavioural specification • Network Service Descriptor: template that describes the deployment of a Network Service including service topology (constituent VNFs and the relationships between them, Virtual Links, VNF Forwarding Graphs) as well as Network Service characteristics such as SLAs and any other artefacts necessary for the Network Service on-boarding and lifecycle management of its instances • Network Service Orchestration: subset of NFV Orchestrator functions that are responsible for Network Service lifecycle management Public NFVO Terminology (1) Source: ETSI GS NFV 003 V1.3.1
  • 69.
    69 © Nokia2018 • NF set: collection of NFs with unspecified connectivity between them • Network Forwarding Path (NFP): ordered list of connection points forming a chain of NFs, along with policies associated to the list • NF forwarding graph: graph of logical links connecting NF nodes for the purpose of describing traffic flow between these network functions • Virtual Link: set of connection points along with the connectivity relationship between them and any associated target performance metrics (e.g. bandwidth, latency, QoS). NOTE: The Virtual Link can interconnect two or more entities (VNF components, VNFs, or PNFs) and it is supported by a Virtual Network (VN) of the NFVI. • VNF Forwarding Graph (VNF FG): NF forwarding graph where at least one node is a VNF Public NFVO Terminology (2) Source: ETSI GS NFV 003 V1.3.1
  • 70.
    70 © Nokia2018 • An end-to-end network service (e.g. mobile voice/data, Internet access, a virtual private network) can be described by an NF Forwarding Graph of interconnected Network Functions (NFs) and end points. • A network service can be viewed architecturally as a forwarding graph of Network Functions (NFs) interconnected by supporting network infrastructure Public NFVO Network Service Source: ETSI GS NFV 002 V1.2.1
  • 71.
    71 © Nokia2018 NFVO Public Network Service with a nested forwarding graph Source: ETSI GS NFV 002 V1.2.1
  • 72.
    72 © Nokia2018 • Most current network services are defined by statically combining network functions in a way that can be expressed using an NF Forwarding Graph or NF Set construct. A major change brought by NFV is that virtualisation enables additional dynamic methods rather than just static ones to construct and manage the network function graphs or sets combining these network functions. A major focus of NFV is to enable and exploit the dynamic construction and management of network function graphs or sets. • VNF Forwarding Graph: covers the case where network connectivity between VNFs is specified, e.g. a chain of VNFs on the path to a web server tier (e.g. firewall, NAT, load balancer) • VNF Set covers the case where the connectivity between VNFs is not specified, e.g. a Web server pool, independent virtualised residential gateways Public NFVO Forwarding Graphs
  • 73.
    73 © Nokia2018 • Functions responsible for coordinating the lifecycle of VNFs that jointly realise a Network Service. Include: - on-boarding a Network Service - management of resources used by the Network Service - managing dependencies between different VNFs composing the Network Service - managing the forwarding graphs between the VNFs. Public NFVO Network Service Orchestration
  • 74.
    74 © Nokia2018 • Described by a set of descriptors: - VNF Descriptors (VNFD) - Network Service Descriptors (NSD) - VNF Forwarding Graph Descriptors (VNFFGD) - Virtual Link Descriptors (VLD). • Descriptors are essentially deployment templates that describe the resource and operational requirements for each of the above components Public NFVO Information Models
  • 75.
    75 © Nokia2018 VNF C VNF A VNF B PNF A PNF B VL Virtual Link: Logical connection between one or more VNFs [VLAN/VxLAN/subnet] CP Connection Point: Interface on a VNF/PNF which connects to the VL [vPort/vNIC/pNIC] VNFFG VNF Forwarding Graph: Defines traffic flows between VNFs within the NS NFP Network Forwarding Paths: Ordered list of CPs that form chains of VNFs with associated policies CP VL CP CPCP CP CP CP VL VL Network service VL CP VL CP CP NFVO Network Service Descriptor example
  • 76.
    76 © Nokia2018 MANO Public Industry Players ETSI Driving NFV specifications TMForum Next-gen OSS/BSS with virtualisation MEF Reference architectures for Lifecycle Service Orchestration (LSO) Linux Foundation Hosting large number of open- source NFV projects
  • 77.
    77 © Nokia2018 • Huge number of open-source initiatives to tackle this space: - ONAP (from a merging of Open-O and AT&T’s ECOMP [OpenECOMP]) - OSM - Tacker - OpenLSO - OpenBaton - Tacker • Many different approachs: - Some provide NFVO with a generic VNFM and VIM - Some provide an extensible plugin architecture for supporting different VNFMs and VIMs Public MANO Implementations
  • 78.
    78 © Nokia2018 • Large number of solutions , (overlapping) open-source and proprietary, are being developed • Elements outside of the NFV framework being identified as gaps • Increased importance of assurance capabilities being recognised • MANO ecosystem seen as immature and requiring considerable work • For operators to be able to exploit NFV capabilities, they have to be able to integrate their current OSS and BSS systems with their new NFV orchestration systems. This is an area of work that is still in its infancy. Public MANO Current market state
  • 79.
    79 © Nokia2018 • Lifecycle management of Network Services (NS) • Integration of OSS/BSS systems • Inter-operation in hybrid PNF/VNF environments • Certification for better portability of VNFs • Comprehensive assurance mechanisms Public MANO Evolution – Focus Areas
  • 80.
    80 © Nokia2018 use cases Public
  • 81.
    81 © Nokia2018 • Currently architected using purpose-built hardware for different functions such as PDN- GE, S-GW, HSS, MME etc • Opportunity to further decompose these functions • Allow independent scaling of each (sub-) function. • Already being deployed by a number of mobile operators worldwide • 5G mobile core likely to be exclusively based on virtualised deployment Public Use cases Virtualisation of EPC Source: ETSI GS NFV 001
  • 82.
    82 © Nokia2018 • Currently designed for peak-hour requirements. May be vastly unused during off-peak times • No mechanism to cost-effectively and dynamically provide additional capacity to handle unforeseen demand • Virtualisation allows CDN capacity to be dynamically scaled on demand • vCDN caches can be instantiated closer to users to reduce bandwidth requirement through the network Public Use cases Virtualisation of CDNs Source: ETSI GS NFV 001
  • 83.
    83 © Nokia2018 Use cases Public Virtualisation of the home environment Source: ETSI GS NFV 001 From… To…
  • 84.
    84 © Nokia2018 performance Public
  • 85.
    85 © Nokia2018 • Would an industry standard server be capable of supporting realistic network workloads ? • How can we provide provide predictable behaviour for new network functions ? • How can we achieve 99.999% service availability using server hardware with 99.9% availability ? • Ideally: - Hardware vendors would be agnostic to the VNFs that would end up running on their servers - VNF vendors would be able to provide a guarantee of predictable performance subject to minimal hardware requirements without explicit knowledge of actual hardware system they will run on i.e. VNF performance is predictable, consistent and vendor-agnostic Public Performance Challenges and expectations as identified during inception of NFV
  • 86.
    86 © Nokia2018 • Measures of performance: - Packet processing rates (bps, pps) - Processing latency - Jitter • Key difference between network services and traditional cloud-computing workloads is that they are more I/O-intensive. • Performance and scalability are important since the implementation of a VNF may have a per-instance capacity that is less than that of a corresponding physical network function on dedicated hardware. Therefore, methods are needed to split the workload across many distributed/clustered VNF instances. Public Performance
  • 87.
    87 © Nokia2018 • Two key approaches to improving performance: - CPU enhancements and acceleration technologies: • SR-IOV • DPDK • PCI-passthrough • Huge page support • CPU pinning - Hardware offload • Smart NICs with offloads for virtual switching, encryption, compression etc. • Co-processors • Intel QuickAssist Technology (QAT): hardware-based acceleration services for encryption and compression Public Performance Achieving higher performance
  • 88.
    88 © Nokia2018 open source Public
  • 89.
    89 © Nokia2018 • Number of operator-initiated open-source projects that were subsequently put into the public domain: - Open Source MANO (OSM): project initiated by Telefonica as OpenMANO, now hosted under ETSI - ONAP: result of merging of AT&T’s ECOMP and Open-O • Open Compute Platform (OCP) - Founded by Facebook, Intel and Rackspace - Applies open-source principals to hardware • Linux Foundation hosts the following NFV-related projects: - ONAP, OPNFV, ODL, FD.io, OVS, CORD, DPDK and many more • OpenStack Foundation • Telecom Infra Project (TIP): founded by Facebook Public Open source projects
  • 90.
    90 © Nokia2018 • Launched in September 2014 under the Linux Foundation • Objective is to create an open reference platform for NFV consisting of open hardware and software interfaces based on open source projects such as OpenDaylight, OpenStack etc. • Focused on system-level integration, deployment and testing to create a reference implementation rather than direct software development Public OPNFV
  • 91.
    91 © Nokia2018 • CORD = Central Office Re-architected as a Datacenter (CORD) • Founded by ON.Lab • Focusses on how traditional telco exchange architectures can be translated to a cloud environment Public CORD
  • 92.
    92 © Nokia2018 • ONAP: result of merging of AT&T’s ECOMP and Open-O • Open-O: - Joint effort between China Mobile, China Telecom and a number of vendors • ECOMP: - Developed by AT&T together with Amdocs Public ONAP
  • 93.
    93 © Nokia2018 state of industry Public Source: SDxCentral 2017 NFV Report Series Part I Foundations of NFV: NFV Infrastructure and VIM
  • 94.
    94 © Nokia2018 • In the 5 years since the inception of the ETSI NFV ISG, significant investment has been made in: - industry-standard commercial off-the-shelf (COTS) hardware - hypervisors and Virtualized Infastructure Managers (VIMs) - Virtual Network Functions (VNFs) - management and orchestration (MANO) Public Progress
  • 95.
    95 © Nokia2018 • A lot VNFs today are not truly cloud-optimised, being simple ports of PNFs (“NFV washing”). This is a necessary step, however, for the industry to start gaining experience with virtualisation without waiting for full, cloud-native functions. • Achieving high performance (for data-plane functions) remains a challenge. VNFs are shipping with vendor-specified minimum requirements for hardware. • The ability to use common hardware for all VNFs is not there yet. Extensive inter- operability testing is still required between VNFs and the underlying NFVI. • Licensing for VNFs is not as straightforward as the hardware-equivalent; VNFs have different characteristics and performance, can scale in and out and are a lot more dynamic. How do you price this ? • Managing VNFs (via the MANO infrastructure) is vastly different to managing network hardware. Newer skills will be required for operators. Public VNFs Current market state
  • 96.
    96 © Nokia2018 • Large number of solutions , (overlapping) open-source and proprietary, are being developed • Elements outside of the NFV framework being identified as gaps • Increased importance of assurance capabilities being recognised • MANO ecosystem seen as immature and requiring considerable work • For operators to be able to exploit NFV capabilities, they have to be able to integrate their current OSS and BSS systems with their new NFV orchestration systems. This is an area of work that is still in its infancy. Public MANO Current market state
  • 97.
    97 © Nokia2018 • For operators to be able to exploit NFV capabilities, they have to be able to link their current OSS and BSS systems to their new NFV orchestration systems. This is a big hurdle today: - OSS/BSS systems are complex and not geared for virtualization. - Operators are deeply invested in these systems so a straight replacement is neither practical nor economically viable. - The systems tend to be highly customized, often developed by their IT teams over many years; there is no one-size-fits-all making integration even more complex. - Even prior to the advent of NFV, OSS integration was a costly and complex exercise; NFV has the capability to simplify future integration but the OSS systems need to ”catch up” with the virtualized world first. - The MEF LSO framework is helping to bridge the gap between legacy OSS and BSS systems and NFV. Public OSS/BSS integration
  • 98.
    98 © Nokia2018 bibliography/references Public
  • 99.
    99 © Nokia2018 • NFV whitepapers: - http://portal.etsi.org/NFV/NFV_White_Paper.pdf - http://portal.etsi.org/NFV/NFV_White_Paper2.pdf - http://portal.etsi.org/NFV/NFV_White_Paper3.pdf • ETSI ISG specifications: http://www.etsi.org • Insights on current state of NFV industry have been quoted from: - SDxCentral 2017 NFV Report Series Part I Foundations of NFV: NFV Infrastructure and VIM - SDxCentral 2017 NFV Report Series Part 2: Orchestrating NFV - MANO and Service Assurance - SDxCentral 2017 NFV Report Series Part 3: Powering NFV - Virtual Network Functions (VNFs) Public Acknowledgements