It's time to update your scorecard tracking the industry groups engaged in virtualization efforts for carrier networks. A new group, CloudNFV, tiptoed out of stealth mode this week, nudged along by early press coverage, but ready nonetheless to make some bold statements about how Network Functions Virtualization (NFV) must be developed as a cloud service.
The father of CloudNFV and, thus far, its public spokesman, is longtime industry analyst and software guru Tom Nolle of CIMI Corp. He says the impetus for the new group is the belief that, rather than design NFV to run on anything from "bare metal servers" to the cloud, the industry should move immediately to a cloud-based implementation, and that a prototype should be developed as quickly as possible to become a guide for implementation. Nolle explains his early thinking in this blog.
"We believe it is simple and more effective to run OpenStack on top of any server environment and create a private cloud environment for NFV," Nolle tells Light Reading.
At this point, CloudNFV consists of six vendors who share Nolle's thinking about NFV deployment, but network service providers are taking notice, in part because this approach guarantees them a critical advantage against over-the-top (OTT) service providers, Nolle says.
"We have built a platform that doesn't distinguish between the functions that make up a service and the components that make up an application," he explains. "So you can combine things that are typically thought of as applications components, like calendars, naturally and easily with things that are typically considered communications components."
That will enable some long-sought but never achieved benefits of Unified Communications to actually reach commercialization, Nolle says. It's not accidental that CloudNFV's first project is a cloud-based implementation of IP Multimedia Subsystem (IMS), the architecture designed to support converged services and enable network functions to be broken into reusable modular segments.
CloudNFV will go one step further in taking TM Forum-oriented operations processes and melding them into cloud deployment strategies that enable network management and Operations and Support System (OSS) functions to be engaged as well. Most likely there will be a software layer created that sits between the existing OSS/Business Support Systems, although Nolle says the data models for CloudNFV will include specs that would enable non-standard systems to be connected with simple Java apps.
Because service providers know how to enable apps that surpass Internet best-effort standards and run well enough "to make someone want to pay for it," Nolle comments, they can leverage a cloud-based deployment of converged capabilities that exceeds what a mere OTT player can accomplish.
CloudNFV will be ready for selective beta-style demos within the next six weeks, Nolle says, and ready for a public demo "no later than mid-October." The vendor partners are not yet public but will be shortly, he promises.
re: New Group Ties NFV to the Cloud Good points, Tom.
I see many operators that have some virtualized network functions already, that plan to do more, and that hope to port all this over to a "Cloud NFV" platform in future.
The logic is “we can get this running on VMware, and then we can port it over to whatever hypervisor and orchestration layer we end up using later.”
A challenge for operators is that they can’t wait for the platform to be ready before virtualizing at least some applications, and therefore they need to work on both at once. This is essentially the transition from waterfall to agile in telco networking.
As a side note, I’ve been quite surprised at the willingness (and, in fact, the desire) of operators to buy vertically assured solutions from vendors – so it might be say, a virtualized PCRF or a TAS running on HP or IBM servers, but supplied by a Big Vendor.
re: New Group Ties NFV to the Cloud I think there are really two risks there, Gabriel. First, for sure there is a strong likelihood that implementations of NFV would come from the major vendors in a proprietary form, with bare minimum accommodations to openness. That's the big reason we didn't want large vendors in our activity; it would almost surely have stalled our progress. Second, there is also a risk that NFV will focus on the relatively simple task of virtualizing real devices and stopping there. That will undershoot benefits so much that it would put the whole concept at risk in my view. NFV is, potentially, an architecture to define how you operationalize software, or service-features, as a service--an anything-as-a-service deployment and management strategy. That's how we've seen it from the first, so it's what we're doing. We hope to help the ISG see the potential of its own work.
re: New Group Ties NFV to the Cloud Came cross my first *unprompted* mention of Project Clearwater from a tech exec at a big operator last week. Conceptually people like it.
The idea that apps written with the constraints / optimizations of a box in mind will need to be re-written (perhaps from the ground up) for the "NFV Cloud" is, I think, now dominant among carriers.
Vendors want to do a straight port of their applications to COTS. They are having a hard time modelling how to invest a bunch of money into software R&D only to go and lose revenue from lost hardware sales.
re: New Group Ties NFV to the Cloud Good post Tom. What chance do you think there is that NFV will, in practice, replicate the classic appliance model, where operators buy a vertically assured solution from the vendor?
Yes, it may be a virtualized app, and, yes, it would run on COTS, but still the operator buys a pre-integrated solution from the vendor?
I know this runs contrary to the concept of NFV and "NFV Cloud", and people kick-back against this idea of running network function on dedicated x86 servers, but I speak to a lot of operators that see this as perhaps a practical first step to NFV.
re: New Group Ties NFV to the Cloud To set some minds at ease: First, CloudNFV is a prototype of the ISG work, and all the vendors involved are ISG members. Future integration partners will also have to be members. Second, the ISG is developing a standard and not an implementation, so it was always the case that multiple implementations would exist. Will they interwork? Yes, at interfaces sanctioned by the ISG. Third, CloudNFV is going to be a totally open process. You can't build something while involving a cast of thousands, so we've selected a smaller group. But we have provided for interfaces to integrate others at multiple levels and in multiple ways, and we'll publish all the options when we open up.
re: New Group Ties NFV to the Cloud They got together during the 1st NFV meeting in Santa Clara. I look at it as an interop group. A virtual plugfest maybe?! Worst case, they uncover interop issues that the ISG would not, as they are totally theoretical.
re: New Group Ties NFV to the Cloud Is there a danger that we will end up with many splintered NFV development groups all pulling in slightly different directions? That wouldn't help. I'd be amazed if all the parties involved aren't in some way connected to the NFV work going on at the carrier-led ETSI group, so maybe that will become the organization that will be at the center of what CloudNFV and others are doing/planning.
re: New Group Ties NFV to the Cloud What we do know from that early coverage is that Project Clearwater (@prjclearwater), the IMS cloud initiative launched by Metaswitch a few months back, will form the foundation of the IMS functions CloudNFV initially aims to virtualize using NFV guidelines. It’s apparent that Tom believes the foundations are in place: To quote: "That, my friends, is how abstraction should work."
To save this item to your list of favorite Light Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
(9) | 
Digg
Del.icio.us
Reddit
Tweet This