Network functions virtualization (NFV) is a framework for building network services from pieces of software-hosted...
functionality. These individual "feature pieces" are called virtual network functions, or VNFs, and one of the hottest issues in NFV today is to determine which VNFs are most important in the near term. Operators that pick the correct VNFs may enjoy early success and build a foundation that permits them to build new services easily as the market evolves. Those operators that pick the wrong ones could face failure, and in the process, possibly compromise the whole NFV value proposition.
"Where do I start?" may be the most important question in NFV, but is a hard one to answer. The best way to approach it is to consider both the service revenues that could be generated by the VNFs and the operational requirements posed by the VNF selection.
Gauge competition before rolling out managed service
The best revenue opportunities come from visible and retail-oriented service features. Many of the most useful virtualizable features -- including network address translation, domain name system, Dynamic Host Configuration Protocol (DHCP) and firewalls -- are already available.
For operators, the most compelling proposition is to offer these service features as managed services. Under this framework, the network operator takes responsibility for sustaining the feature, keeping it up to date, guaranteeing its performance, and ensuring availability.
Picking a VNF set from those features directly visible to the user will require careful market planning. Among the considerations, it's important to know how many new network customers enter the operators' markets in a year, how many new sites are added for existing customers, and how long customer network equipment that provides the target features can be expected to last. Knowing the local labor market is also important. In general, however, many operators believe security and facilities monitoring offer the best opportunities. That’s because budgets in both areas are growing and premises-based products and approaches are generally less trusted by users.
A managed security, management and monitoring framework could give users a reason to commit to NFV-based features. Once that occurs, the incremental cost of extending NFV offerings to other areas --including communication, collaboration and integrating applications and networks into cloud service offerings -- is lower. That makes an important point about direct-to-user VNF-based services. Early success builds a platform for extended success, so begin where willingness to buy is strong.
Understanding operational impacts
In contrast to visible features, infrastructure features lack direct revenue opportunities. These include components of operator services, including mobile services, content delivery and voice. Because these features are already part of an operator's own menu of services, any benefit provided in converting them to VNFs has to come from cost reduction, which means trimming Capex, Opex or both.
In general, operators have reported that substituting a hosted software component for a custom appliance that provides service infrastructure features will save only about 15% in Capex if the VNFs come from the same vendor that provided the appliance. Savings can grow to about 25% from independent VNF resources, including open source. For applications like evolved packet core and content delivery networks where horizontal scaling under load is valuable, these savings can grow to as much as about 35%.
Opex savings raises the issue of evaluating the operational requirements of the specific VNF. A VNF-based configuration of features often involves several virtual machines on several different servers -- plus network connections between them and with the rest of the service infrastructure. This combination is more complex to manage than the simple device that the VNFs replaced. As a result, it's critical to understand just what the operational impact will be. Unfortunately, this is very difficult to assess except in the context of a test or trial.
Hosting VNF's an emerging landscape
Operational requirements also include the tools needed to host VNFs, which go beyond the simple virtualization or cloud software elements that host application components. ETSI specifications indicate that VNFs will have to be managed (via a VNF manager); they'll also need to be integrated with the NFV management/orchestration (MANO) element for deployment and horizontal scaling, and potentially with NFV infrastructure (NFVI) to obtain management status from the resources hosting the VNFs. These connections are a part of a now emerging product category -- NFV platform software.
Emerging perhaps, but not yet mature. The standards to provide these connections have not been finalized, nor has it been determined whether they'd be adequate to support efficient operations. Thus, vendors may generate proprietary approaches. Some VNFs may run only with specific MANO, VNF manager and NFVI implementations. As a result, it's important to consider whether your early-stage VNFs will lock you into a platform that may exclude some of your later VNF choices.
Where to start with VNFs is an important query, but it's only a part of the broader question, "Where do I go?" Every VNF decision can affect your platform requirements, your future VNF capabilities and the services that can be composed quickly without adding new VNFs. To that end, it's important to consider the benefits -- both long-term and near-term -- when you pick your initial VNF targets.
Understanding the nexus between SDN, NFV
Why service agility isNFV's payoff