NFV foundation/NFV For Dummies

Editor's Notes

• #4 operators gathered within the European Telecommunications Standards Institute’s (ETSI) and created the Industry Specification Group (ISG) for NFV to accelerate the progress of virtualizing network functions. Launched in January of 2013, the ETSI ISG for NFV has been working to develop the requirements and architecture of virtualized network functions in a telecommunication’s network. It included these components of the NFV framework: • NFV Infrastructure (NFVI) – The physical resources (compute, storage, network) and the virtual instantiations that make up the infrastructure. • Virtualized Network Functions (VNFs) – The software implementation of a network function. • NFV Management and Orchestration (NFV MANO) - The management and control layer that focuses on all the virtualization-specific management tasks required throughout the lifecycle of the VNF.
• #6 Since the original ETSI model for NFV was released, some operators have clamored for a more rapid and organic development of NFV platforms. Some operators have even put together their own technology programs, including developing their own open source projects which they then donate to the community (e.g. OSM/OpenMANO from Telefonica, ONAP comprising ECOMP from AT&T and Open-O from China Mobile).
• #7 *) The NFVI layer primarily interacts with two other NFV framework components: VNFs and the Virtualized Infrastructure Manager (VIM). *) the VNF software runs on NFVI *) The VIM is responsible for provisioning and managing the virtual infrastructure. *) VNF to NFVI interface (Vn-Nf) constitutes a datapath through which network traffic traverses, while the NFV to VIM interface (Nf-Vi) constitutes a control-path that is used solely for management but not for any network traffic. *) NFVI consists of three distinct layers: physical infrastructure, virtualization layer and the virtual infrastructure.
• #8 *) NFVI consists of three distinct layers: physical infrastructure, virtualization layer and the virtual infrastructure.
• #9 *) Open Compute Project (OCP) *) the VNF characteristics dictate the VM “flavor” (or in the future, the Container environment as Containers enter the fray as a viable VNF form factor). The VM flavors in turn dictate the exact specification of the server. This choice needs to be made very carefully to avoid underutilization of hardware. Over engineering any one parameter could massively degrade your total cost of ownership economics. *) For NFV workloads, there are major CSP vendors who are starting to provide converged and hyper-converged workloads and starting to tune them for more I/O-centric network services. *) edge computing (also called Fog Computing) where either a carrier grade server is required (e.g. in a central office) or a light-weight box is required to host just a few VMs (e.g. for a consumer’s house). *) the customer edge is morphing from having multiple dedicated boxes that provide different functions (line termination, firewalling, routing, WAN optimization, IP PBX etc) into foundational edge Virtual CPE (vCPE) platforms that run virtualization software including flavors of hypervisors, OSes with Linux Container support, stripped down OSes with ability to install VNF packages.
• #12 (VNFs may run in a regional data center, a central office edge location or on the CPE device itself). Corresponding business models are also being tested, including having CSPs that lease such NFVI vCPE platforms to its customers, with the ability to rent software on demand (security, acceleration, etc), or having enterprises purchase these platforms and rent OTT (over the top) services in the cloud.
• #14 Core factors: Image size, boot up time. Kernel sharing in container technologies creates security problems Container in VM solves kernel sharing but creates performance overhead. Clear container is answer to above problem. Initiated by intel to showcase container in VM but stripped down/ light weight version of VM Unikernels are VMs; however, rather than dragging around the entire Guest OS, unikernels link the application only to the libraries used by the application.
• #16 The virtualized infrastructure manager (VIM) is a key component of the NFV-MANO architectural framework. It is responsible for controlling and managing the NFVI compute, storage, and network resources, usually within one operator’s infrastructure domain.
• #18 In reality, there are use cases in which case a VIM is not necessary - for example in a relatively static environment where longer provisioning times are acceptable. The elimination of a VIM will dramatically reduce the benefits of NFV, but may be an easier way to try out NFV before embracing all of the ETSI architecture. In a deployment without a VIM, you can use virt-manager for KVM and VMware vCenter for vSphere.
• #22 VNFs are critical to realizing the business benefits outlined by the NFV architecture. They deliver the actual network functions that create value, and include the components that make up the mobile core (Virtual EPC), or the virtual edge (Virtual CPE). But they aren’t autonomous and require management. VNFMs are critical for scaling, changing operations, adding new resources, and communicating the states of VNFs to other functional blocks in the NFV-MANO architecture. A VNFM may be assigned the management of a single VNF instance or multiple VNF instances. The managed VNFs can be of the same or different types. the VNFM maintains the virtualized resources that support the VNF functionality without interfering with the logical functions performed by the VNFs. The services provided by the VNFM can be employed by authenticated and properly authorized NFV management and orchestration functions.
• #25 The MEF has started to work with its members on LSO (Lifecycle Service Orchestration) efforts to help bridge the gap between NFV and OSS/BSS. LSO binds together legacy OSS and Billing Support Systems (BSS) services,newer SDN and NFV software, and telecom hardware infrastructure. It is a new software platform that can take a customer order and implement service provisioning, orchestration, fulfillment, service assurance, and monitoring, serving as the central control panel for how services are delivered across the sprawling service provider network.
• #26 RIFT.io has taken the approach of commercializing the OpenMANO open-source implementation provided by ETSI with full product support. Telefonica contributed its original implementations of OpenMano to ETSI, RIFT.io provided an open-source component for orchestration and Canonical providing Juju as a generic VNFM in this implementation.
• #27 OpenBaton enables virtual Network Services deployments on top of heterogeneous NFV Infrastructures and integrates with OpenStack, and also provides a plugin mechanism for supporting additional VIM types. it provides auto-scaling and fault management based on monitoring information coming from the NFVI.
• #28 Tacker is an official OpenStack project building a Generic VNF Manager (VNFM) and a NFV Orchestrator (NFVO) to deploy and operate Network Services and Virtual Network Functions (VNFs) on an NFV infrastructure platform like OpenStack.
• #29 the OpenECOMP architecture which is reproduced below. Note OpenECOMP is the open-source name of the ECOMP project after AT&T contributed 8M lines of code to open-source as part of the creation of a Linux Foundation project.
• #33 The NFV framework is a virtualization framework aimed at telco workloads. Many organizations are deploying NFV frameworks in conjunction with SDN (software-defined networking) frameworks that span both physical and virtual appliances, including routers and switching gear.
• #35 a few vendors have engaged in “NFV washing” by simply porting a HW-based network product into a VM and pretending they have a full NFV VNF. Or by positioning offerings that require proprietary NFVI, or their own proprietary MANO, as an NFV VNF when in truth that product is still more akin to a virtual appliance rather than a true NFV application. Managing the underlying NFVI and pairing it with the appropriate VNFs (workload placement) is an area of active development. Other elements that continue to complicate matters include dealing with noisy neighbors on a VM implementation (where VMs that take more resources crowd out other VMs), and managing the mix of bare metal, VMs and container implementations of various VNFs.