Network Virtualization 101: NFV & VNF

Copyrights © Dhiman Deb Chowdhury, 2015. All rights reserved.

In the previous articles ( http://www.dhimanchowdhury.blogspot.com ), I discussed how the need to share resources led to gradual development of technologies concerning network programmability and virtualization. I am hopeful that readership is now conversant on the notion of network virtualization (NV) and SDN and how network programmability technologies such as SDN coexist with topological virtualization of physical network. I connoted that both SDN and NV decouple network abstractions, the difference is that SDN separates data plane from control plane providing centralize network control and programming mechanisms while NV decouples physical infrastructure from logical topologies.

Figure 1. A diagrammatical representation of the interworks of NV and SDN.

With this distinction in mind, we embark on yet another discussion about how the needs for network programmability (i.e. SDN) and virtualization (i.e. NV) find common ground in NFV (Network Function Virtualization) architectural framework.

In October, 2012 some of major network/telecom operators got together at Darmstadt in Germany to devise a framework for NFV (Network Function Virtualization) (Haleplidis et al., 2015) penciling ideas from the technological advances in system virtualization, SDN and NV. It is an architectural framework that make use of virtualization technologies to define virtual elements of entire classes of node (compute, storage and network) functions into building block that can be connected or chained to deliver communication services.  The framework is devised under the stewardship of ETSI (European Telecom Standard Institute) and various workgroups within ETSI entrusted with the responsibility to define different aspects of NFV framework (e.g. network elements and APIs etc).

The need for network/telecom operators to devise a white paper on the NFV framework comes from the growing challenges to accommodate customer demands for improve services while reducing CAPEX (Capital Expenditure) and OPEX (Operational Expenditure). The NFV framework aims to address those challenges by virtualizing network functions (NF) [e.g. load balancer, firewall, PE Router, CG-NAT etc] and allowing network/telecom operators to deploy those NFs at will on high end devices. One of the major challenges in NFV deployment is the orchestration and management of network functions (NF) such as load balancer, firewall and other control functionalities. A workgroup within ETSI NFV undertaking, namely “MANO” (Management and Orchestration) was formed to develop specification on management and orchestration framework for NFV architecture (figure 2). We will discuss framework of MANO later in this article but for now think of NFV framework as the main architectural construct or reference model for which VNF, NF and Management/Orchestrations are the elements or subsets.

Figure 2. Timeline on NFV related research works at ETSI (source: ETSI, 2015; ETSI, 2014).

One more important subset of NFV framework is the NFVI (Network Function Virtualization Infrastructure). The NFVI specifies various physical resources and how abstraction of those resources are virtualized, e.g. virtual compute, virtual network and virtual storage. Applying our understanding of system virtualization (hypervisor/VM concept) [if you need further clarification, please visit my blog: http://www.dhimanchowdhury.blogspot.com/2015/07/network-virtualization-101-prelude.html ], the NFVI framework can be understood as hardware resources (compute, storage and network) virtualized by hypervisor for which VM is virtual instances and VNFs (Virtual Network Functions) are implemented as application on top of VMs. Please refer to the NFV reference model as depicted in figure 3. The NFV reference model comprises of three main subsets: NFVI, VNFs and NFV Management and Orchestration. The element management system (EMS) is commonly used in a typical telecom network to manage network element. In my good old Nortel days, we used element manager to retrieve configuration information in various networking and telecom gears while pulling device information through NMS. Once a device is found in the network using NMS network map, you could double click on the device to open up element manager to configure and manage the device in a way that is not possible through simply using MIBs as you would through the NMS. I hope this imparts you the usefulness and purpose of EMS. In a telecom network EMS brings many values, for example, you could integrate different vendors and their element manager to a NMS and manage the entire group of systems through a single NMS.

Figure 3. The NFV reference Model.

The OSS (Operational/Operation Support System) and BSS (Business Support Systems) are back-office software applications to supports activities related to services. For example, OSS includes software toolsets that are related to management and operation aspects of network services while BSS toolsets are used for billing, order management and CRM etc. For telecom professional these terms and software toolsets are nothing new but for rest of the readership this brief explanation is useful. 

Now that we understand some key terms and functional elements that connects with NFV framework, let us explore essential components of NFV reference model. Please note that NFVI specifies hypervisor based virtualization but it is also possible to use containers (a notion mainly associated with LinuX Container) to support same VNF instances as in hypervisor/VM based system. The notion of container was born in 2005, out of necessities for webscale services at Google Data center. Google was experimenting with hypervisor based virtualization at the time but soon realized that performance penalty for such virtualization is too high and was not elastic enough to support a web-based services at scale (Bottomley, 2014). During the time, a group of engineers were working on Linux around a concept based on cgroup called process container who were later hired by Google to advance experimentation for webscale services. Some of these Cgroup technology later found its way into Linux Kernel and the LinuX Container (LXC) project was born in January 2008.
To date, implementation of containers are mainly done at server level system virtualization but works are underway to realize some benefits of container based virtualization at networking gears. As such, implementation of VNFs in networking switching gears may well be done using container virtualization techniques within next two years.

The VNFs (Virtual Network Functions) are simply network node or network functions (NF) running as virtual instance on top of VMs (virtual machines) (Vilalta, et al., 2014). For example, a VNF can be load balancer, NAT/firewall and many other similar network/network node functions. Today, much of the VNF implementations are done at server level but it is also possible to implement VNFs on networking gears. NFV framework (ETSI, 2014) did not constrained use case scenarios of VNFs and works are already underway to have server like experience in networking gears making it possible to implements VNFs in various use case scenarios, such as Residential, CDN, Fixed Access Networks, Mobile Station and Mobile Core & IMS deployments. This implies that even future residential or CPE gateways will have VNFs implemented on them allowing service providers to deploy service at will.

The Management and configuration of VNFs and other subsets of the NFV reference model (as depicted in figure 3) is done through MANO (Management and Orchestration) toolsets. The MANO architecture presents three elements: VIM (Virtual Infrastructure Manager), VNF manager and Orchestrator. The VIM is used for the management and allocation of virtual resources, e.g. add/remove and modification of resources related to compute, network and storage. The Openstack constitutes a close reality to ideal VIM but requires further works related to various plugins and integration of automation/configuration chef and puppet tools to realize its deployment in service provider network.  

The VNF managers handle the configuration, lifecycle management, and element management of the virtualized network functions. Within Openstack initiative, the “Tracker” project aims to deliver VNF manger and NFV orchestration capabilities for NFV platforms. For further information on “Tracker”, please visit https://wiki.openstack.org/wiki/Tacker .

Figure 4. The diagrammatical representation of Openstack “Open NFV Orchestration” "Tracker” project focus. (Openstack, 2015).

Apart from the Openstack Tracker project, many other vendors also offer application solutions but challenges remain to develop a comprehensive toolsets due to complexities of unified transport networks systems.

I hope this article provided a brief overview of NFV reference model: readership should follow the work of ETSI at http://www.etsi.org/technologies-clusters/technologies/nfv  to advance their understanding and stay in touch with the latest works in this field.  In the next article, we will explore various APIS of SDN and understand how SDN and NFV are deployed in a given network scenario.

Please stay tune and follow me. If you are interested, please join me in the free live webinar on “Open Networking” at https://lnkd.in/bhydy6x .

Reference

[Bottomley, 2014] Bottomley, J., 2014. What is All the Container Hype? Parallels.

[Haleplidis et al., 2001] Haleplidis, E., Salim H. J., Denazis, S. & Koufopavlou, O, 2015. Towards a Network Abstraction Model for SDN. Network System Management (2015) 23:309-327.

[ETSI, 2014] ETSI, 2014. Network Functions Virtualisation – White Paper #3. ETSI NFV portal. Available online at https://portal.etsi.org/Portals/0/TBpages/NFV/Docs/NFV_White_Paper3.pdf

[ETSI, 2015] ETSI, 2015. NFV activity report 2014. ETSI NFV Portal. Available online at https://portal.etsi.org/TBSiteMap/NFV/ActivityReport.aspx

[Openstack, 2015] Openstack, 2015. Tacker. Available online at https://wiki.openstack.org/wiki/Tacker .

[Vilalta, et al., 2014] Vilalta, R., Muñoz, R., Casellas, R., Martínez, R., López, V., & López, D., 2014). Transport PCE network function virtualization. In European Conf. Optical Communications, Cannes, France.