NFV (Network functions virtualization)

NFV in the Cloud: It's Complicated

No one ever thought that Network Functions Virtualization (NFV) would be easy to implement. But did everyone realize how tough it would actually be?

Even the staunchest advocates of NFV as a cloud-based process admit that the cloud world is an ultra-complex environment that will require fundamentally new approaches to the orchestration and management of services. (See Clouding Up the NFV Transition.)

That's a major reason the whole process of virtualizing network functions may take longer to be fully implemented than initially thought. (See Clouding Up the NFV Transition).

While the cloud is a more dynamic and flexible environment for implementing virtualization, and the one that offers the best chance of actually achieving the efficiency and flexibility gains that has the network operators so fired up, distributing functions in the cloud can (and probably will) change every aspect of how services and applications are developed and delivered.

"In a virtualized world, an application sits in one virtual machine," says Caroline Chappell, senior analyst with Heavy Reading and one of the authors of a new report, SDN & NFV: A Revolution in the Making. "In cloud world, it may be in a number of VMs [virtual machines] in different tiers of the virtualization process -- Web, compute or storage -- and those tiers may have very different requirements, such as different thresholds for when they need to be spun up and spun down. The data tier may need to be located in a single country, for example, for regulatory reasons, but you might be able to have Web tier anywhere," explains Chappell.

Engineering challenge
As a result, the entire way apps and services are engineered in the cloud changes, as things become untethered, creating the need for a new set of orchestrations for each app and, arguably, a new approach to managing services.

And for telecom service providers to reach their ultimate goal of plug and play services and apps that are assembled from the virtualized functions located in the cloud, it is essential that these new approaches remain open and sustain interoperability, says Nik Willetts, chief strategy officer for the TM Forum.

"It's a case of knowing where you are heading," he says. "Or you can end up with a bunch of proprietary solutions that don't integrate all that well but happen to be running on virtualized bits of kit rather than proprietary bits of kit."

The challenges have not gone unnoticed by the operators keen to benefit from NFV and software-defined networking (SDN). The European Telecommunications Standards Institute (ETSI) NFV working group has described a management and orchestration layer, but that is still in development.

"If you take that concept literally, you would be adding a pretty significant software function that could be a massive development activity and a monumental single point of failure, if you have all management requests going through one thing," says Tom Nolle, president of CIMI Corp. and the catalyst behind the Cloud NFV organization. (See New Group Ties NFV to the Cloud).

Avoiding the proprietary trap
There are multiple efforts to create open interfaces to avoid the proprietary trap and any NFV deployment is likely to draw on these, including OpenStack and the work being done by the Open Daylight project. But there is still uncertainty over how all of this happens.

"Open Stack does some of the things you need -- it gives you the ability to manage the virtual machines and the network connectivity of those virtual machines, and it gives you overall visibility," says Metaswitch Networks CTO Martin Taylor. "But it doesn't do things like aggregating statistics, and it doesn't do things like monitoring the load on the systems and adjusting the number of instances of a particular process up or down to perform automatic elastic scaling."

Those developing software platforms, such as Metaswitch's Project Clearwater, are looking to a third party to provide those kinds of generic functions so they can focus on maximizing the quality and functionality of their NFV software.

"We don't know yet who is going to step up to the plate and do that software work," Taylor comments.

There is some general uncertainty hanging over the management aspect of NFV, admits Graham Finnie, chief analyst for Heavy Reading, but that's not uncommon given how early it is in this process. In its research for the above-mentioned SDN & NFV report, Heavy Reading found there is a lack of consensus among operators about how they view NFV in relation to their existing Operations Support Systems and network management processes.

Internal affairs
While some see operational changes as essential to taking advantage of the scalability and elasticity that virtualization is promising, others are too wary of internal organizational issues and would prefer the that any implementation of NFV and SDN capabilities doesn't touch their legacy OSS, Finnie says.

"At this point, it's a real dog's dinner," Finnie says, like a true Brit.

Speaking of food for thought, the final article in this mini-series looks at what CloudNFV and others have cooked up to address these virtualization complications.

— Carol Wilson, Editor-at-Large, Light Reading

Kevin Mitchell 6/24/2014 | 2:09:23 PM
Muddying the Multi-Vendor World NFV means multiplying the multi-vendor environment? or at last adding a few to the mix? If software providers remain, then you add the server guys (which realistically were already there but are now more intimately involved in end-to-end signaling/media flow and fixing issues).

Cloud Voice Platform: NFV from A Single Vendor
Ray Le Maistre 8/1/2013 | 10:05:33 AM
re: NFV in the Cloud: It's Complicated I think you just hit the nail on the head. This is the big REAL big test -- can the operators break away from the standard telco/tech procurement process? And will they be prepared to let go of the process?
gleavieboy 8/1/2013 | 2:05:43 AM
re: NFV in the Cloud: It's Complicated Ray - Verizon's an example of a service provider that has that kind of knowledge. Conversation at http://bit.ly/15dpqyQ between Martin Taylor and VZ's Stu Elby touches on this point, starting at 1:43. Admittedly they got there discussing SDN but so many in the industry insist on writing SDN/NFV that I'll take that liberty too:)
philharvey 7/31/2013 | 10:27:33 PM
re: NFV in the Cloud: It's Complicated Nah. You need project managers and VPs who won't be fired for doing what ETSI described in its NFV white paper. I think developers can partner with software specialists that do understand select pieces of the puzzle. If you try to do everything in-house or you stay with the standard telco/tech procurement process you will completely miss the point of NFV.
philharvey 7/31/2013 | 10:21:02 PM
re: NFV in the Cloud: It's Complicated 13th graf, 2nd sentence. The word "thinks" should be "things."
Carol Wilson 7/31/2013 | 9:19:22 PM
re: NFV in the Cloud: It's Complicated Everyone is going to have to have that combination of expertise. Most of the principles of virtualization have their roots in the IT realm, but without an understanding of telecom network functions, virtualization has very limited benefits.
Ray Le Maistre 7/31/2013 | 6:58:02 PM
re: NFV in the Cloud: It's Complicated So, basically, what you need is a team that has a deep understanding of telco infrastructure and legacy OSS + deep non-telco IT knowledge. Who REALLY has that combination? Anyone?
Sign In