Light Reading's Big Telecom Event and the launch of the New IP Agency offered some pretty convincing proof that NFV needs a shot in the arm, or perhaps the wallet.
My own surveys of operators agree with those cited at the event -- most operators are having a problem making a business case for network functions virtualization (NFV). But it's not a lack of possible NFV benefits creating the problem here. NFV has been linked with reducing capex and opex and increasing service revenues. Benefit-wise, there's not much more you could say, and if sources of benefits aren't the issue then it's realizing the potential of those sources we have to consider.
If NFV is missing something here, then it needs to be addressed, and I think we can identify something to "fix" in each of the benefit areas.
The capex fix
If NFV is going to reduce capital expenditures, it has to do that by creating strong economies in infrastructure -- what European Telecommunications Standards Institute (ETSI) calls NFV Infrastructure or NFVI. In the ETSI spec, NFVI is connected via a piece of the management and orchestration (MANO) function called the Virtual Infrastructure Manager (VIM), and that's something I believe weakens NFV's vision of open infrastructure.
What's needed in NFV is something like "NFVI plug-and-play," meaning that any hardware that can be used to provide hosting or connectivity for virtual functions should be capable of being plugged into MANO and supporting deployment and management.
A VIM shouldn't be part of MANO, but part of NFVI. It should be the thing that represents hardware into NFV's world of orchestration, and that also means it shouldn't have to manage "virtual" infrastructure. We need to generalize VIMs to become Infrastructure Managers or IMs, and let any equipment vendor that can offer an IM for their gear to offer elements of NFVI -- any host, any hypervisor, any cloud stack, any network equipment. That's how you get economy of scale.
The opex fix
This IM-and-NFVI approach could also help realize opex efficiency gains for NFV. Few operators believe that every network device is going to turn into a virtual network function. Even in the long term, creating "NFV services" will demand cooperation between hosted virtual functions and legacy devices.
To build one of these hybrid services end-to-end efficiently will mean controlling both the NFV and legacy worlds, but if NFV's MANO orchestrates and manages only virtual stuff, who provides the higher-level end-to-end orchestration? If we say it's OSS/BSS or NMS or something like that, then operations efficiency isn't really an NFV benefit, but a benefit of OSS modernization.
If we can represent legacy infrastructure as part of NFVI via an IM, then we could orchestrate and manage legacy elements within MANO. We could handle the use of legacy services to connect virtual functions, to connect users to virtual functions, or even orchestrate services that had no virtual functions at all. This doesn't force operators to use NFV orchestration for everything but it allows them to integrate virtual and real-device orchestration if that's helpful in making operations more efficient.
The business case fix
The plug-and-play IM-NFVI combination raises an important issue that's part of operations efficiency and also of service agility and the realization of new revenues. A plug-and-play device isn't just some arbitrary piece of technology that somehow has to be analyzed to be used, it's a device that conveys its functionality.
Plug in a USB drive and the computer knows it's a disk -- the same is true for a printer or scanner. That means, in NFV terms, that we need to know what behaviors an IM-NFVI combination presents, and that means that we have to understand what behaviors of resources MANO can use to deploy and connect stuff.
We need a set of abstractions -- a set of models. If we have that, then the abstract model of behaviors could be translated to a standard set of parameters and status variables, so that MANO logic could understand the state of a connection or a deployment without having to know all the possible ways to deploy and connect -- the IM would harmonize the implementation underneath to the framework of the abstract behavior. Hosting is then hosting, no matter how you do it.
This is important for new services too. SDN is as important a development in network evolution as NFV, and if you can control forwarding explicitly, you can create all kinds of different service behaviors, things we don't get today from Ethernet or IP.
It would be easier to assume that such a new forwarding service could be incrementally revenue-generating than to suppose that users who were offered elastic bandwidth wouldn't use it to reduce their average cost by provisioning extra capacity only at peak periods. But how would such an SDN service even be described to NFV? If we had behaviors and abstractions, it would be just a new connection behavior.
Some would look at these steps and say the changes are too big to make, but I don't think they really demand much change at all. There's more that could be done by digging deeper into specifications and even into the process of writing the specs, but even if NFV took only these steps it could move a long way toward realizing the benefits that would make that elusive business case.
If the ETSI NFV ISG, or Open Platform for NFV Project Inc. , or the New IP Agency, are serious about moving NFV optimally forward, I'd suggest this is the way to start.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp., special to The New IP