Computers and software have gotten a lot more powerful and flexible over the last couple of decades, and this has brought networking to the point where it’s logical to start thinking of network/service features as being something you host in a server and not embed in a device.

Virtual switching/routing has been around a long time, and software-defined networking depends on software control of packet forwarding. In a limited way, we’re already using software to define the next-generation network, or NGN. What’s missing is a generalized model to support any network feature through hosted software. That could save a lot in capital costs by substituting inexpensive servers for proprietary appliances, but it could also create a more agile network, a network better able to respond to market changes and opportunities. If that’s not what the NGN is supposed to be, I’m missing something.

But this utopian model of generic hosting of features is missing a few things too. How do we deploy software elements to perform what hard-wired boxes used to do? Where’s the best place to put a virtual component of a service, how do we connect the pieces, and how do we manage the whole collection of virtual service stuff without driving operations cost increases that would overwhelm any capital cost saving? This is the question network operators undertook to answer with their “Call for Action” on NFV in the fall of 2012, and the question that the ETSI (News - Alert) Industry Specification Group on NFV was formed to address. It’s a revolutionary, perhaps even visionary, goal.

The NFV ISG is working to define the broad rules for deploying services based in whole or in part on virtual functions, and managing them efficiently once they’re deployed. While this work is targeted initially at displacing purpose-built appliances in favor of hosted software components, it is also generating a model for the creation of future services based on virtual devices that may not even exist today. 

Unlike networks of real devices whose features change slowly with time, networks of virtual devices can support any service feature you can imagine – and that you can develop as a software component. That sort of thing can be a game-changer for network operators that have been trying to monetize their own expensive infrastructure, to get into the higher-level service game. Because of that, NFV could define a shift of network infrastructure investment away from boxes and toward data centers and software – toward the cloud.

NFV has to address three questions. First, where do the virtual functions that make up services and replace devices come from? Will vendors be willing to make software versions of their products available, or will a developer community provide the resources needed? Second, how are these virtual functions deployed? Do we support the cloud, or virtualization, or bare-metal servers, or even blades in existing network devices – perhaps all of the above? Finally, how can virtual resources be managed so that operations costs don’t eradicate cost savings on equipment?

The first question is fairly easy. We have a whole industry of open-source developers that can be harnessed, and competitive pressure is likely to induce most vendors to provide at least some of their products in software form. For the second question, logic says that most virtual functions will be hosted in the cloud eventually, but more specialized hosting might prevail in early deployment. That means that the NGN might be a supercloud, a cross between the Internet and virtualized resources and software. For management, current OSS/BSS systems will have to be accommodated, but also evolved to meet the needs of virtual management.

The devil is in the details, as always, and the only way we’ll get to them is through implementation. The NFV ISG is not only permitting but encouraging prototyping of its concepts even before everything is firm. I know of seven implementations under way, of which three (Alcatel-Lucent’s (News - Alert) CloudBand, Amartus SDS, and CloudNFV, a project driven by a group vendors) are public at this point. 

Multiplicity here isn’t an invitation to proprietary solutions either. All implementations will likely conform to the work of the NFV ISG when that work is completed. More approaches now means better feedback into the ISG’s work and a better solution for all. In fact, we’ll need some real-world comparisons and competition to bring out the implementation issues – and to show us that elusive NGN just as soon as possible.

Tom Nolle (News - Alert) is president and founder of consulting and analyst firm CIMI Corp. (www.cimicorp.com) and a founding member of the CloudNFV initiative.