In short, Network Functions Virtualization or NFV is a modern methodology that replaces the traditional way of building network infrastructure using specific hardware, with software-based equivalents running on generic server-based platforms. These network functions can be routers, firewalls, session border controllers, SD-WAN or any function that exists on hardware today.
The concept of virtualization is not new. Take the office of the 1970’s. There would be a typewriter, phone, copying machine, traditional snail-mail. These functions can be integrated into a single PC with an all in one printer and headset. Also look at what we took on holiday in the 1990’s. A stills camera, a video camera, mobile phone, paper books, our travel tickets. All these functions can be virtualized and are able run on a single smartphone.
Origins of NFV
In October 2012, a specification group named “Network Functions Virtualization” published their first whitepaper on the subject. This group was part of the European Telecommunications Standards Institute (ETSI). This whitepaper focused on Software Defined Networking and OpenFlow (a related subject), but since then they have published many more use cases for NFV.
So why are we do service providers want to do this?
Well not all currently do. The business case for some providers simply does not work or is not yet fully understood. With many new and radical ideas, there was a lot of hype around the technology. And with NFV there has certainly been a lot of hype. So much so that there are businesses that stopped developing hardware-based solutions in order to focus on NFV. For many adopters they see some benefits in virtualizing network functions, but the reality is the take up is slow and benefits may fall short of what was promised in the initial hype phase. Nevertheless, NFV real and some service providers are starting to transition from dedicated routers, firewalls and SD-WAN solutions to visualized equivalents. A Gartner Hype Cycle curve best sums up where we are with NFV currently.
There are five sectors associated with the Garter Hype Cycle
|1||Technology Trigger||A potential technology breakthrough kicks things off. Early proof-of-concept stories and media interest trigger significant publicity. Often no usable products exist, and commercial viability is unproven.|
|2||Peak of Inflated Expectations||Early publicity produces several success stories. These are often accompanied by scores of failures. Some companies act, but most don’t.|
|3||Trough of Disillusionment||Interest wanes as experiments and implementations fail to deliver. Producers of the technology survive or fail. Investment continues only if the surviving providers improve their products to the satisfaction of early adopters.|
|4||Slope of Enlightenment||More instances of how the technology can benefit the enterprise start to crystallize and become more widely understood. Second and third generation products appear from technology providers. More enterprises fund pilots but conservative companies remain cautious.|
|5||Plateau of Productivity||Mainstream adoption starts to take off. Criteria for assessing provider viability are more clearly defined. The technology’s broad market applicability and relevance are clearly paying off. If the technology has more than a niche market, then it will continue to grow.|
Given that there are some adopters that have gone from the pilot to production stage, then it is fair to say that NFV is some way up the “Slope of Enlightenment”.
We do need to look further at the business drivers for NFV, but first let’s take a closer look at the technology.
The ETSI MANO Architecture
MANO stands for Management and Organization. These are terms we need to explore in more detail. There are essentially three elements we need to focus on for a basic understanding of NFV technology. A diagram of the architecture is show below.
The NFV Infrastructure (NFV-I)
This part of the architecture would host the Network Functions. It may be located on the customer premises as CPE or be in the datacenter for more centralized NFV. Either way, it is generally a generic server-based technology running an x86 processor. The server would generally, run each Network function as a separate virtual machine. OpenStack tends to be the base technology used to provide this virtual machine infrastructure, although many NFV vendors optimize OpenStack to remove parts they do not need or to make the deployment easier. Bear in mind OpenStack does take compute resources and these are precious at the network edge. So, these optimized derivatives of OpenStack are common in NFV.
OpenStack requires on operating system to run. The OS tends to be Linux based and so it is not uncommon to find that the x86 based compute node runs Linux and then OpenStack provides the virtualization layer that in turn hosts the network functions as virtual machines. Running network functions in isolated virtual machines is not much use. An operator will need to interface these to external ports and interconnect them together. This process is called service chaining. The compute node will also need to run some form of virtual switch. Open vSwitch is a common base to work with although it does currently have performance limitations that some vendors address with proprietary improvements.
More about service chaining later.
Virtual Infrastructure Manager
The ETSI MANO architecture allows for the management of the infrastructure. This layer of management is akin to traditional FCAPs management. An operator would want to monitor the health of the infrastructure and collect events and alarms. They would want to see service topologies and measure the performance of the installation. Beneficial features like Zero Touch provisioning can also be controlled within this part of the ETSI MANO architecture.
Service Orchestration is an important and interesting aspect of NFV. The orchestration function allows an operator to create network service templates that define service chains. For example, a site may need a Fortinet firewall and Cisco router. The Network Service Template defines how these virtual functions are interconnected and what physical ports are used on the host NFV-I server. Essentially, a site topology. The orchestrator also must “on-board” VNFs. The process of ”on-boarding” is more than simply storing the software image. The service provider must also define what resources that VNF needs in terms of CPU cores, RAM and disk space. Another task of the orchestrator will be to store the day-zero configuration of that VNF to allow Zero Touch configuration and testing of that VNF whether it be a router, firewall or anything else.
OSS and BSS layers
The OSS (Operational Support Systems) and BSS (Business Support Systems) layers tend to be outside of the NFV MANO and NFV-I and are generally not discussed when learning about NFV. These functions will be those that the operator uses for customer interfacing. They will perform billing and customer management amongst other things. Interworking between the NFV MANO and the OSS/BSS layer will be through Application Programming Interfaces (APIs)
More about Service Chaining
A typical service chain is shown below.
This comprises firewall and router that would be typical within a Customer Premises Equipment environment. In a legacy deployment the router and firewall would be discrete devices. Each would have their own power supply, rack pace and would be interconnected with Ethernet cables.
The service chain would be designed as part of the Network Service Template. The LAN side of the firewall will be connected to a physical port on the NFV-I device, as too would be the WAN side of the router. In this example, we have allowed for a management network to be configured in the service chain. This too is connected to an external port and allows management connectivity to the network functions from the physical location. The WAN side of the firewall and the LAN side of the router need interconnecting. A virtual network with no physical ports is defined on the NFV-I to do this. This typically uses a vSwitch within the NFV-I software.
Open and Closed Solutions
NFV solutions can be either open or closed.
A closed solution is one that is provided by a single vendor. They will provide the NFV-I hardware and software and all the MANO components as well as the Network Functions. The attraction of this is that the operator has a one stop shop for the entire solution. They will have fewer choices to make compared with an open solution and support should be easier. It should take less time to push a solution into production. Given that telecommunication companies traditionally do not have the skills set to program APIs, then the closed system approach may be attractive. The down side is that is creates vendor lock-in. Once a vendor is entrenched in a customer, they can exploit this fact for commercial gain. Also, the functionality provided may not be optimal and smaller customers simply may not have influence on the development roadmap.
An open solution is one that uses open standards and probably generic whitebox servers. Having open and standard API means that the customers can choose best of breed solutions for the NFV-I and MANO. This choice prevents vendor lock-in, but means they have more testing to do and more choices to make when selecting components. However, this open solution means they can shop around for best price, have control and have fewer constraints when selecting Network Functions. However, support will be more complex, and they will need to recruit people who have the skills to program APIs. Currently, those skills are rare.
Business Drivers for NFV
I was in the position of being able to talk to early adopters about NFV and the possible business benefits they perceived from its very inception. When we look at the business drivers, we can refer to the Garter Hype Cycle. At the Technology Trigger Stage, there was a lot of cynicism. However, there was a belief amongst the potential customer base that NFV would simply be cheaper than the hardware equivalent. Afterall, this is just software – right? Moore’s Law was often quoted to highlight the fact that processing power was increasing at an exponential rate and so with time there would be no need for expensive, dedicated packet processors. This is true to some degree, but do not forget some applications such as 5G require delivery of very accurate synchronization and time. This can only be done today on dedicated hardware. The complexities of the MANO where not understood either. There was a view that a MANO was not needed, or the existing OSS systems could simply be upgraded. Another major factor is the cost of MANO systems. There is often a large up-front cost for the MANO software, and this was a deterrent.
As time progressed, more and more NFV-I and MANO solutions where being developed and the concept proven in trials. Potential customers realized that NFV-I devices were never going to be cheaper than their hardware equivalents (well at least not soon), but orchestrated NFV could offer service agility and service flexibility that simply could not be achieved through dedicated hardware. Take a customer site with a router and firewall as an example. With dedicated hardware each device must ordered configured, shipped and installed by a field engineer or competent customer. The same service with NFV can be setup using predefined Network Service Template on the orchestrator and the IP addressing also assigned centrally using the MANO. A generic box can be shipped to site and simply racked and powered by the customer. A ZTP process can be initiated and the whole thing builds itself without human intervention. The whole process, design to implementation, takes minutes. There are real savings to be had when you factor in the true cost of field and logistical support associated with traditional builds.
So, concept proved, what was needed to push NFV from a trial stage to production was a killer app. This app currently is SD-WAN. You can see my blog on SD-WAN here. SD-WAN delivers on the promise of reducing access circuit costs by using any access medium in place of expensive MPLS edge services. Real financial savings. The business case is even stronger when provisioning is automated through NFV based ZTP rather the using dedicated SD-WAN appliances.
Further financial savings can be made by vendors being creative with pricing. The MANO inparticular can be expensive, but the industry is pushing vendors to offer “pay as you grow” pricing structures where you pay per installed end point rather than a large cost up front. This leads to lower upfront costs, but the vendors can make more money when the client has a large installation base.
I hope I have given you a basic overview of what NFV is and what the technology comprises. I have included some background on the commercial drivers based on my experience. The fact is NFV is real and is being deployed. There is a desire amongst service provider to disaggregate their networks and decouple software from hardware. If this trend continues, then NFV will soon take hold. In my view, the most successful solutions will be based on open source components using whitebox servers and will be controlled by open APIs. So, if you want to get into network design having Linux and programming skills will be of huge benefit to you in your career choice. Focus less on traditional CLI technologies such as Cisco routing and more on programming and coding skills.