NFV (Network functions virtualization)

Clouding Up the NFV Transition

A growing chorus of voices is warning that the virtualization of network functions won't accomplish the savings service providers are looking for unless the move to virtualization is coupled with the much tougher job of moving those functions into the cloud.

With that acknowledgement, however, comes the realization that true Network Functions Virtualization (NFV) will take significant work and may not have a real impact for two years or more.

The necessity of "cloudifying" the network -- and yes, that's the term being bandied about -- is certainly the premise of the recently formed CloudNFV group, but it's also a message resonating with the likes of Heavy Reading Senior Analyst Caroline Chappell as well as the TM Forum. (See New Group Ties NFV to the Cloud).

"Fundamentally, just to virtualize something, to put it on the hyperviser, on COTS [commercial off-the-shelf] hardware, doesn't change it all that much," Chappell says. By contrast, putting something in the cloud enables network operators to have "very dynamic resource pools, things that can contract and expand," as well as the ability to move things around very rapidly to meet changing needs or demands.

Virtualizing something without putting it into a cloud ecosystem just carves up the physical architecture into virtual machines, without the flexibility and elasticity of the cloud, notes Chappell.

So the TM Forum is focusing its efforts on what it will take to manage services in a virtualized world and is viewing the cloud as essential to that process, even though it's far from clear exactly how it all comes together, says Chief Strategy Officer Nik Willetts. The forum will be putting out a position paper this fall, in advance of its North American conference in San Jose Oct. 28-30, that looks in greater depth at its vision for the future.

"We are looking at what the ultimate operator end-to-end management platform will look like," says Willetts. "It is certainly going to be in the cloud, but whether it is a private cloud or public, and whether it is country-specific or whether there is one for large operators that fits across a large number of countries, there are all sorts of ways of how you go. We need to develop that vision and then work backwards in terms of how you get there, because it's not going to happen overnight."

In fact, Willetts says, the service provider CTOs and CIOs with whom he's talking are looking at a two-year process, even as everyone admits market pressures exist to move faster on anything that will get services to market more quickly.

The TM Forum is working with the CloudNFV group as well as the European Telecommunications Standards Institute (ETSI) NFV group on deciding network management requirements, Willetts says. The forum's intent is to take a practical approach to the process, as it has with its past 'Catalyst' projects. (See Carriers Peer Into Virtual World.)

CloudNFV is also trying to approach the issues practically, says Tom Nolle, president of CIMI Corp and a driving force behind that effort, which is promising to yield its first fruit this fall in a demonstration of virtualized IP Multimedia Subsystem (IMS) elements.

But Nolle, Chappell and Willetts all agree that this "cloudification" process will create new management headaches, especially since pulling together resources in dynamic fashion from their various virtualized locations will make the end-to-end assurance of a network service much more difficult.

The process itself is likely to spark a clash between the IT-oriented factions within a telecom operator that are accustomed to virtualization and dynamic reconfiguration, and the network-oriented factions that prefer the greater certainty and reliability of tried and true process.

So what can be done to overcome the looming NFV management challenge? That'll be the focus of my next NFV article.

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

Kevin Mitchell 8/13/2013 | 1:37:01 PM
re: Clouding Up the NFV Transition I believe the 2c/sub applies to only SOME of the solution. No SBC, no media gateway, no carrier services, no provisioning solutions or back-office management systems. All that still requires investment and ongoing OPEX and dedicated internal resources. While an impressive figure, it's an incomplete. The true cost is much higher.

And yes, I use gear here to hardware and software. It does indeed conjure up images of boxes with many wires.
Dredgie 7/31/2013 | 4:45:17 PM
re: Clouding Up the NFV Transition Hey, Kevin - by 'gear', in this case (re. your fist sentence), you are, of course, talking about software. The word has such a 'hardware' connotation! :-) Re. your other observation, you are right. Naturally this multi-tiered model (wholesale / retail) is dependent on getting the cost out of the service. A cloud-based IMS core, app servers and session border controllers will enable that. There is a simple worksheet on the Project Clearwater web site that enables anyone to calculate the cost of an IR-92 VoLTE service in a cloud environment. With current AWS it's under 2c per sub per year - and the way Amazon are slashing their prices, that'll only decrease over time.
Dredgie 7/31/2013 | 3:48:57 PM
re: Clouding Up the NFV Transition The ETSI NFV ISG is all about deploying functions within a cloud environment. Indeed, a lot of the work-in-progress is around management and orchestration (MANO) in such environments. CloudNFV can be seen as the 'plugfest' arm of the ISG, IMO. They will work closely with the (new-ish) proof-of-concept' (POC) arm of the NFV ISG. We will hear about the 6-founding members in September, I believe. Although we already know that the one non-founding member is Metaswitch, as the group is looking at Project Clearwater as the first POC.
Carol Wilson 7/30/2013 | 8:06:15 PM
re: Clouding Up the NFV Transition There's not really a disconnect - I think the Cloud NFV folks are looking to add some greater clarity on how delivering network functions virtualization through a cloud ecosystem delivers additional advantages. Cloud was initially part of NFV's charter, as I recall. CloudNFV will disclose its membership this fall, I believe. I don't think they were necessarily ready to start talking publicly but they were discovered by an eager reporter and have been gracious enough to share some basics.
sam masud 7/30/2013 | 3:14:09 PM
re: Clouding Up the NFV Transition Correct me if I'm wrong, but I not sure whether there is necessarily a disconnect between the NFV group and the CloudNFV project. My understanding is that NFV wants to get away from proprietary boxes--thus the software providing the services can run on COTS servers or in the cloud. In other words, NFV is not saying the service cannot or should not be in the cloud--it just does not want to buy boxes.

One thing I do find puzzling is that CloudNFV has not disclosed its membership, because typically when a group like this is formed, one of the first things they do is disclose the membership.
Kevin Mitchell 7/30/2013 | 12:55:29 PM
re: Clouding Up the NFV Transition Cloudifying the network still means the providers buy and operate gear even if they put it on someone else's servers "in the cloud". That's not the only choice and, for some services, we think the time has past where all providers must each run their own network. Cloudsourcing VoIP makes a ton of sense given the voice market dynamics, next gen network costs, and the importance of focusing limited resources on broadband, mobile, video and other strategic initiatives.

Cloud voice platforms enable the outsourcing ALL the aspects of the voice network to the cloud lets service providers stay in the triple-play game without the hefty bill or resource drain.
gleavieboy 7/30/2013 | 12:22:40 AM
re: Clouding Up the NFV Transition Couldn't agree more, Carol. While there will be some value in NFV on COTS, the long term play for Telcos has to be in the scalable, fault-tolerant, highly elastic cloud. Metaswitch first showed our Perimeta SBC working on AWS last year. Project Clearwater (open source IMS core) also runs on AWS - although the community has shown it spin-up in Azure as well. Of course, the software has to be designed with the cloud in mind (which does require some smarts to deliver real time comms in a traditionally async environment). I actually think the conversation is also going to tilt towards the public end of public/private clouds. Sure I get the desire/legacy that says Telcos "must own it themselves" but the cost benefits of public clouds are going to be compelling. And with Amazon co-locating in data centers around the world, there won't be performance trade-offs. The software telco will happen.
Sign In