Network Function Virtualization (NFV) is the latest chapter in computer networks that tries to solve some of the pressing concerns with traditional networks. What is NFV and why is it all the rage? How does it differ from traditional networks? How does it benefit us? Let’s try to answer these questions in this article.
The problem with traditional networks
Traditional computer networks suffer from hardware middleboxes. Hardware middleboxes are network functions such as firewalls, Network Access Translation (NAT), load balancers, and Intrusion Detection Systems (IDS) that are available as hardware devices. Network administrators deploy these hardware middleboxes in networks to provide network solutions. For example, a web host could deploy a firewall and a load balancer in front of the web servers to secure the servers and satisfy QoS requirements. So, what’s wrong with them?
The network functions in and of themselves are not a problem. The problem is the fact that network administrators have to deploy them as dedicated hardware devices. So, deploying new network functions means introducing new hardware, which is going to consume space. Besides, the power consumption of the network also goes up as the number of functions increases. Administrators also have to reconfigure the network every time they have to insert a new function. Scaling functions dynamically according to demand is also not practically possible as it requires manual configuration.
Such issues hold back innovation. Using new network protocols is not possible without upgrading to the latest hardware. This leads to protocol ossification. This can not only impact the revenue of the network providers, but it can also hold the industry as a whole back. So, how do we fix this?
Network Function Virtualization (NFV)
Enter NFV. NFV tries to solve the issue of hardware middleboxes by virtualizing the network functions. Network administrators can then deploy these Virtual Network Functions (VNFs) on commercial servers. This offers a lot of advantages. To begin with, this reduces the Capital Expenditure (CAPEX) as network operators simply need to purchase software instead of entire hardware. Administrators can also deploy multiple VNFs on one server, greatly cutting down the space and power requirements. This reduces the Operating Expenses (OPEX). But the benefits don’t end here.
Since the network functions are now just software, upgrading to the latest protocols becomes easier. This addresses the issue of ossification, accelerating growth and innovation. Network operators also avoid the problem of vendor lock-in by using open-source VNFs. Moreover, removing a network function or adding a new one also becomes straightforward as this requires no topological changes. At the same time, administrators can easily scale up or down VNFs based on demand ensuring they meet the QoS requirements. This flexibility also creates an environment conducive to making networks at least partially autonomous.
However, NFV comes with its own unique challenges. The most important challenge is that of management and orchestration. This is about deploying VNFs on the physical infrastructure, establishing network connections between different VNFs, managing their lifecycle, scaling them up or down, and making optimal use of the hardware resources available. This is a very complicated problem, and the research community is hard at work trying to find solutions.
Nonetheless, the European Telecommunication Standard Institute (ETSI) proposed the NFV architectural framework circa 2014 to guide the development effort. This high-level framework focuses on the changes virtualization brings to an operator’s network.
The following diagram shows the NFV architectural framework.
Now, let’s try to understand the different components of this architecture.
VNF and EM
VNF, as we have already seen, is a Virtual Network Function such as a firewall. An EM is an Element Management that manages a VNF.
The NFV Infrastructure (NFVI) consists of all the hardware and software that make up the physical infrastructure on top of which we deploy the VNFs. This consists of the hardware resources, the virtualization layer, and the virtualized resources.
The hardware resources are of three types, namely computing, storage, and network. Computing hardware consists of commercial off-the-shelf servers. The storage can be either the storage found in servers or Network Attached Storage (NAS). Routers, switches, and physical links form the network hardware.
The virtualization layer abstracts the underlying hardware resources and provides an interface for the VNFs to access the virtualized infrastructure. This is typically the hypervisor, but it can also be just an Operating System (OS) in a non-virtualized server.
Virtualized computing, storage, and network resources are logical partitions provided by the virtualization layer that the VNFs can utilize.
NFV Management and Orchestration
NFV Management and Orchestration (MANO) is responsible for deploying VNFs and managing their lifecycle. The Operations Support System (OSS), which manages the network, and the Business Support System (BSS), which takes care of the business aspects, interacts with NFV MANO to provision VNFs, manage their lifecycles, and obtain analytical information. NFV MANO consists of the NFV Orchestrator, VNF Managers, and Virtualized Infrastructure Managers.
Virtualized Infrastructure Managers
Virtualized Infrastructure Managers are responsible for managing the inventory of computing, storage, network, and software resources in NFVI. They also allocate Virtual Machines (VMs) to hypervisors, establish network connectivity, and manage the allocated resources. On top of this, they also engage in fault detection and data collection.
VNF Managers are in charge of the lifecycle of VNFs which includes instantiation, updating, querying, scaling, and termination. They are also the ones that deploy VNFs on NFVI.
NFV Orchestrator orchestrates and manages NFVI through Virtualized Infrastructure Managers. In addition, the orchestrator also talks to VNF Managers to help them configure the VNFs.
ETSI has initiated an effort to implement its architecture and develop an Open-Source MANO (OSM). The open-source implementation, named Charmed OSM, developed in collaboration with Canonical is now available for usage.
In this article, we first discussed the shortcomings in traditional networks such as their cost, static nature, and protocol ossification. Then, we saw how NFV can solve the issues afflicting traditional networks by virtualizing the network functions. Finally, we discussed the NFV architectural framework and what each component in the architecture does before briefly discussing the implementation of this architecture.