Network Function Virtualization (NFV): the Road less Travelled – Part 2

Aug 08, 2013

As I noted in Part 1 of this series, the communications industry is abuzz with vendor and service provider interest in the NFV space. With the potential to completely transform the way communication networks are designed, built and operated, NFV promises a number of benefits such as reduced capital (CAPEX), reduced operational (OPEX) expenditures, reduced time for service turn up and a shift to a “fail fast” model for new services.

In part 1, we highlighted some of the key industry initiatives, such as the ETSI NFV ISG, that are driving the adoption of NFV, but emphasized that there are two further areas where innovation must take place in order for NFV to be successful.  We noted the areas that have not received as much attention thus far: Firstly, the business models for virtual network functions (VNFs) and secondly, how VNFs are authored for the cloud. Part 1 examined the NFV business models. In this part, we look at VNF authoring for the cloud.

Authoring VNFs for the Cloud
Among its benefits, NFV promises service agility and rapid new service creation while reducing CAPEX and OPEX. Let us look at this in more detail. NFV can reduce CAPEX by utilizing commodity industrial servers rather than purpose built devices. Saving are also realized by elastic scaling which enables the operator to exploit varied VNF usage patterns to rapidly scale up/down services and multiplex multiple services on the same infrastructure. For example, a session controller VNF may have primary usage in the day and is complimentary to a billing VNF that can be run flexibly, on the same infrastructure, in the night during off-peak times. CAPEX is also reduced, as we will see, by minimizing the need for 1+1 redundancy as is typical in current carrier infrastructure. OPEX is reduced primarily by automating the activation and assurance of the VNF-based customer services. Finally, NFV promises to boost the top line by driving the shift to a “fail fast” model supporting rapid creation and deployment of new services.  For more on “fail fast,” See the recent article by my colleague, Mark Durrett.

This has several implications for how VNFs need to be built for the cloud.

Elastic Scaling

In order to support dynamic scaling of VNFs, we need several features.

First, we have different VNF components that may scale differently. For example, a next-generation virtual firewall may have components that support NAT, IPS/IDS, VPN, routing, policy etc.  Each of these may scale differently depending on a number of different factors such as users, throughput, IP addresses etc.  The VNF should be authored such that each of these components can be scaled independent of each other as required.

Second, the scaling should be non-disruptive to the operations of the VNF. It should be possible to add or remove an instance of a VNF or a component of the VNF without any disruption to commissioned services. This typically requires a smart load balancer function in front of the component(s) being scaled. Further, depending on the nature of the VNF, scaling may be complicated by whether the VNF or VNF components are stateful or not. Stateful implementations may track anything from transaction state to session state. The less stateful that each component needs to be, the easier it is to scale.

Most telecom systems are engineered with purpose built devices and utilize 1+1 type of redundancy mechanisms.  While operators are very comfortable with this model, it results in a significant CAPEX overhead. With a properly designed NFV solution, this penalty can be reduced significantly by reserving a pool of shared compute capacity across multiple VNF services or instances in a M:N redundancy configuration. The desired resiliency targets can then be achieved using cloud techniques such as VM live migration or recovery – instead of a dedicated set of redundant hardware appliances. Live migration and recovery is further aided by storing long lived, persistent data in clustered, scalable cloud storage instead of tightly associating it with the VNF, itself. This has the additional benefit of bringing reliability to the application data, itself, by using the clustering and data replication mechanisms built into these cloud storage systems.

Operational Management
The ETSI ISG is defining mechanisms for automating the management and orchestration for VNFs. This is going to be important for controlling operational costs of managing VNFs and associated services. One important aspect is service monitoring and management. Whereas virtualization brings with it many benefits, it does make service management such as fault correlation more challenging.  This is because VNFs are not tied to easily identifiable physical network elements. Virtualization further complicates things by hiding the internal workings of the individual VNFs.  For example, the VM container hosting the VNF may be alive and well while the VNF inside it has crashed. A typical cloud monitoring system would have no visibility into such a failure condition.  So, if we are to overcome these challenges, the VNFs must expose their internal health status and requisite recovery actions. In addition the VNF must provide features to help correlate its state with that of the physical and virtualization infrastructure. It is clear that VNFs need to be authored from day one with an awareness of these service management requirements, or we will soon be drowning in OPEX costs.

Getting to Service Creation Nirvana
A bulk of the activity in the VNF vendor community today is focused on transplanting existing network functions into the virtual world. This is a necessary first step and, assuming it is done with the cloud in mind, it will bring a number of CAPEX and OPEX benefits as noted above. But in order to impact top line revenue, a second outcome is required: we must be able to create new services that we never envisioned.

A first option is to simply aggregate or combine the available VNFs to create new services. This is indeed on the radar of the ETSI ISG activities. A more complex option is to build new VNFs from a set of modular elements that can be easily reassembled to create new VNFs, this brings tremendous acceleration to new service creation.  If these building block elements are available from a diverse ecosystem of vendors, we will have achieved the requisite richness for successful service creation.  If we have both of the above service creation options, we would have arrived at what I call “service creation nirvana!”  I am not aware of any activities though in the vendor community or in standards bodies that aim to address the multi-vendor VNF building block idea.

I do know that the new service creation “fail fast” model is a vision that is gaining momentum within a number of service providers I meet with, and the VNF authoring needs to adapt to support this vision.

My research has identified only a few VNF vendors who are taking a clean slate approach to designing network functions for the cloud.  To date, the bulk of the vendors are still transplanting their non-virtual implementations into the virtual world verbatim. While transplanting is an easy first step, it does not realize the promised benefits of – and may in fact be detrimental to – the accelerated adoption of NFV.  I applaud the pioneering VNF vendors for taking the road less travelled and for driving the industry to the Promised Land of NFV.

About the Author
Ramesh Nagarajan is the head of Ensemble OSA™ product strategy and management at Overture networks. He has nearly 20 years of experience in the telecom and cloud computing arena in a variety of innovation focused  technology and business roles at IBM, Bell Labs, AT&T and Alcatel-Lucent. As a  technology consultant  and technologist, his work has shaped various leading product and services’ strategies as well as creation of new product and business segments. As a business leader, he has launched several new products and services, innovated business models, developed alliances and partnerships, managed development teams and financial management. Ramesh holds a Ph.D. in Electrical and Computer Engineering from University of Massachusetts, Amherst and has completed the core MBA requirements at Rutgers University

Network Function Virtualization (NFV): the Road less Travelled – Part 2 was last modified: July 1st, 2015 by Ramesh Nagarajan

Contact Overture to learn how you can increase profitability by transforming service delivery.