As an industry analyst looking through my microscope at the telecom technology industry, it is easy to lose track sometimes of just how niche some of the terminology that we bandy about really is. Take NFV for example. A Google Trends search of Network Function Virtualization* (NFV) shows interest in this search term has steadily grown since 2012 when ETSI published its first whitepaper on the topic. However, the search term "Software-Defined Networking" (SDN) is currently four times more popular than NFV. Moreover, the popularity of both terms pales into insignificance when we compare with searches for 5G and IoT.
So, if like the vast majority of the planet you are still wondering what NFV is, let us try to cut through the jargon and explain things clearly. The best place to start is with the initial ETSI whitepaper on NFV, which was written by network architects from various telecom operators (AT&T, CenturyLink and Verizon to name a few) and presented at the SDN and OpenFlow World Congress in October 2012. As the paper explains, one of the challenges that operators face with traditional network equipment is that each new network service often requires new proprietary hardware appliances. Given the rapid pace of innovation of new services (DSL, FTTC, 3G, 4G, etc.), operators are often hard-pressed to simply find room for the additional equipment. Moreover, managing a network with so many complex, hardware-based appliances requires highly specialized skills, which often makes the operator dependent on equipment suppliers for support. This in turn leads to vendor lock-in, which results in high operating and capital expenses.
NFV aims to address these issues by using standard virtualization technology, which has been used in enterprise IT systems since the 1990s. The concept of virtualization dates back even further to the 1960s when it was used to share mainframe computer capacity between different users. The basic idea behind NFV is to extract the functionality of a proprietary hardware appliance (router, firewall, etc.) as software and then run this software on industry-standard, high-volume servers, switches and storage. Not only can multiple software functions run simultaneously on the same physical device through the magic of virtualization, but these devices can be located anywhere in the network -- in a datacenter, in a network node or in the end customer premises. This avoids the space constraints that operators face in certain network nodes and avoids the need to deploy a new box at a customer site each time a new service (e.g., firewall) is requested. Moreover, as the hardware is all commercial off-the-shelf and industry standard this should be cheaper than the current practice of buying proprietary hardware with custom ASICs.
What has made NFV feasible now is recent improvements in packet handling within x86 processors. This has enabled CPU cores to be used as network processors with throughputs comparable to proprietary ASICs. However, the telcos want the vendors to go one step further, not just redesigning their products to run on industry standard hardware but to do so in a standardized way that enables the software to be run in a virtual machine or even in containers.
As well as saving on hardware and associated energy costs, NFV is also meant to make it easier for operators to roll out new services and to rapidly scale these up or down as required. Specifically, the ETSI whitepaper cites the possibility of running production, test and reference facilities on the same infrastructure to provide more efficient test and integration, reducing development costs and time to market.
If you've made it this far down the article, you may be wondering how NFV differs from SDN, which we also mentioned at the start. The ETSI whitepaper touches lightly on the overlap with SDN stating that the two are complementary but not interdependent. In a nutshell, SDN is about separating the control plane in network infrastructure from the data plane such that the control plane can be centralized (enabling easier management of the network) while the data, or forwarding plane, remains distributed in nodes at the network edge (reducing backhaul traffic and latency). NFV, on the other hand, is about redesigning a proprietary network device as software that runs on virtual machine instances, which in turn run on industry standard hardware. The two topics are related but quite different.
So, five years on from the original whitepaper where have operators got to with NFV? AT&T has been the most vocal on this with a goal of virtualizing 75% of its target workloads by 2020 up from 6% at the end of 2015. AT&T hit its target of 30% by the end of 2016. More recently China Telecom has said that it is working towards a goal of 80% virtualization by 2025 and representatives of Vodafone's German subsidiary have said they are aiming for 60% by 2020. (See Virtualization Frustration Sees Telcos Rebel.)
For most operators, NFV adoption is likely to be a gradual process. EXFO, a provider of network test and analytics solutions, thinks service providers will adopt NFV in three distinct phases:
- Virtualization: transitioning from hardware to software
- Service automation: automating service delivery processes
- Complete integration of service assurance (SA) into DevOps: reaching the ultimate goal of optimized operational efficiency, agile service creation and increased revenue
Right now, most service providers are in Phase 1, EXFO says, adding that a few of the more innovative operators are just starting to move into Phase 2.
Light Reading's sister site, Virtuapedia, runs a biannual operator survey on their virtualization plans and deployments. What these surveys tell us is that for most operators, virtualization will take many years to fully deploy. Generally, we find that telcos are taking longer than originally anticipated to identify all of their high-priority functions to virtualize. Furthermore, most respondents expect that the opex savings that NFV promises won't be achieved for at least another three to five years, if at all.
That's not to say that we should get despondent about NFV and dismiss it as hype. NFV does, in theory, make sense for operators. The trick is to make virtualized networks easier to operate than the current plethora of complex network platforms and support systems. There is no point trading one set of operational headaches for a different but equally intractable set of operational headaches introduced by NFV. Solving these operational issues will take time and forms part of a broader OSS transformation for operators worldwide.
This blog is sponsored by EXFO.
— James Crawshaw, Senior Analyst, OSS/BSS Transformation, Heavy Reading
* Searches for the acronym NFV are mostly looking for material on the Northern German Football Association -- Norddeutscher Fussball-Verband. Searches for SDN are generally looking for Malaysian limited companies, SDN being the equivalent of plc or Inc.