NFV (Network functions virtualization)

NFV Group Kickstarts Proof-of-Concept Work

Network functions virtualization (NFV) took another important step towards real-world implementation today with the approval by the carrier-backed ETSI NFV Industry Specifications Group (ISG) of its first proof-of-concept application.

The application in question, which addresses the development of an open NFV platform (and is also tied to software-defined networking too), comes from the vendor-backed CloudNFV collective, which has been working hard in recent months to address real-world network operator requirements.

The decision to approve the CloudNFV application was confirmed on both the European Telecommunications Standards Institute (ETSI) NFV Wiki on proof of concepts and on the CloudNFV site, located here.

Tom Nolle, the veteran industry analyst who heads the CloudNFV group, which has brought together nine vendors and two service provider sponsors for its proof of concept, says the group's proposal was the first formal application filed and the first to be accepted. Work is expected to begin in mid-January with the first results due to be shared a month later, although the project will continue into the summer. The two service provider sponsors, Telefónica SA (NYSE: TEF) and Sprint Corp. (NYSE: S), will have access to the work on an ongoing basis for their continual feedback. (See Answering the NFV Management Challenge and CloudNFV Moves Quickly to Product Stage.)

The details of the CloudNFV application spell out eight specific goals, but Nolle highlighted a few key aspects in an interview with Light Reading.

"We are seeking to prove a much more comprehensive approach to openness than even the one mandated by ETSI," says Nolle, who is also the president of CIMI Corp. Specifically, CloudNFV wants to define an open platform that can handle any virtual function or legacy function as part of a service, without customization.

One of the challenges to virtualization is that simply moving from vendor-specific appliances that enable specific functions to vendor-specific software enabling those same functions won't deliver the necessary benefits of lower operations and costs and faster time to market for services, Nolle says. Many of today's virtualized functions are coming from vendors that may convert their appliances into software that can run in the cloud.

"But if you take proprietary software and move it to the cloud, you have a proprietary cloud," he comments. Furthermore, even "open" interfaces can be vendor-specific, which negates the portability of applications. What CloudNFV is developing in its proof of concept is a platform that doesn't require any customization of virtual functions.

In addition, that platform is being designed to support both virtual functions and legacy functions as part of a service, so that new services can be more quickly created from available resources.

"We are demonstrating NFV in a broad orchestration and operations context that includes operating legacy equipment and mixing virtual functions and legacy functions," Nolle says.

Another significant aspect of the CloudNFV work is that it is creating a service model for software-defined networking (SDN) to spell out how it can be used to accelerate service deployment, something that isn't always clear, Nolle says.

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

Carol Wilson 12/16/2013 | 9:48:50 PM
Re: Willpower and know-how... Seven,

I think that is the intent - through automation of some operations and simplication of others (and yes, that is down the road) jobs are eliminated. 


brookseven 12/16/2013 | 6:56:41 PM
Re: Willpower and know-how... Carol.

So if you talk to an HR person, they will tell you that Opex is directly related to headcount.  So, I tend to ask this question - "Because you implented X, how many people are you laying off?"  So before we lower Opex, what job functions are no longer required.


TomNolle 12/16/2013 | 6:52:45 PM
Re: Willpower and know-how... I think we need to measure vendor claims of "NFV" support by two things; first, have they submitted a PoC to validate their approach in the NFV process.  Second, have they met the goals of the two NFV white papers, which stress the need to improve operations, agaility, and (most of all) openness.

Carol Wilson 12/16/2013 | 6:09:13 PM
Re: Willpower and know-how... The thing that most intrigued me was the focus on openess and what that is going to mean in the virutal world. It's widely discussed but defined differently, depending on the company providing the definition. This seems to be a definition tuned to the needs of the service providers for faster time to market for their services and the promise of lower opex down the road. 
TomNolle 12/16/2013 | 2:40:02 PM
Re: Willpower and know-how... Thanks, Ray!  I think that PoCs are important to the body to accelerate their timeline and also to link their work as carefully as possible to the software frameworks for deployment and virtual function authoring.  The industry needs answers on schedule, and also the right answers!  My hope is that our approval will open the way for other groups to offer PoCs and advance the work of the ISG on multiple fronts.

[email protected] 12/16/2013 | 1:18:09 PM
Willpower and know-how... I have to say these are impresive timelines and makes me blieve that something tangible will actually happen within the timeline of the ETSI NFV ISG, which is almost half way through its pre-determined life (of two years' duration).

Credit to the team behind CloudNFV... 
Sign In