Torbz - Fotolia
Three advances making NFV deployments better for the business
NFV deployments made progress this year, thanks to three significant developments, but will they be enough to make NFV's business case more compelling among other industry changes?
Like all technology shifts -- especially ones that have a profound effect on infrastructure and operations -- network functions virtualization, or NFV, has to make a business case to advance. While it would be premature to say that happened in 2016, three significant initiatives moved the industry toward an approach that could drive NFV deployments. Let's look at this year's advances.
The first step involved the European Telecommunications Standards Institute (ETSI) NFV Industry Specification Group (NFV ISG) accepting a broader model for NFV deployments. The original NFV specification work, launched in 2013, focused on the specific issue of deploying virtual functions on servers and building their connections. This seemed like a logical beginning, since it was the specific attribute that differentiated NFV from building traditional networks. But this focus cut the work off from broader service management and end-to-end deployment activity. That, in turn, reduced NFV's ability to address operations efficiency and service agility -- the two benefits operators had already turned to by late 2013 to justify NFV deployments.
The NFV ISG this year opened work on multilayer orchestration, with the intent to apply the principles of NFV's management and orchestration (MANO) functions to both legacy devices and to higher network management and operations support systems/business support systems layers. With that work, software automation based on orchestration would be possible throughout the entire service lifecycle -- regardless of what components are used and what management and operations processes are involved.
One thing that drove the NFV ISG's decision to broaden the model for NFV deployments was the announcement of complete transformation architectures by operators like AT&T and Verizon. Other network operators subsequently became interested in following the model these architectures represented.
AT&T's Enhanced Control, Orchestration, Management and Policy (ECOMP) software-defined networking platform was particularly influential, largely because AT&T announced it would make ECOMP available in open source form and work with other operators globally to facilitate its adoption and improve its functionality. Orange S.A. -- formerly France Telecom S.A. -- quickly announced it would be a partner in the initiative.
The early ETSI work was a compromise hammered out between network operators and network equipment vendors. And, like most compromises, it didn't make anyone completely happy. Operator support for some broad NFV architecture is critical. And by defining their own architectures, AT&T and Verizon gave the industry a template for the features and capabilities an operator would demand from not only NFV, but also from SDN.
Service modeling leads the way for NFV
The second 2016 advance began with the approaches of AT&T and Verizon to NFV, which unlike the early ETSI NFV ISG work, focused on multilayer service modeling. ETSI followed the lead of AT&T and Verizon in accepting that orchestration would take place in multiple layers, starting with service operations and working downward.
Service modeling is an essential step toward defining an open approach for applying software automation to service lifecycle management -- from deployment to termination, including fault handling. The fact that both architectures proposed multiple layers of modeling and orchestration has already prompted the ETSI NFV ISG to focus more on that critical topic. Both architectures also proposed the use of open source components, and AT&T's ECOMP will itself be open-sourced, paving the way for this year's third advance.
Open source foundation
The third advance is operator acceptance of open source software as the foundation for its transformation projects. While open source software has been increasingly important in IT and the cloud, operators have resisted it in favor of open implementations of standards that allow the use of proprietary software tools. But even before NFV, efforts were made to promote open source as the basis for software-based network tools, especially in the area of management. Projects with that aim were first launched more than a decade ago, in fact.
There have been multiple open source NFV projects, too -- some with a broad aim of defining the NFV ecosystem, like Open Platform for NFV, and others with a more focused approach, such as Open Orchestrator Project and Open Source MANO. These initiatives, based on the ETSI NFV ISG specification, inherited the narrow application scope the initial ETSI work established. With the introduction of broad transformation architecture like ECOMP, it's likely all other open source activity will be absorbed into a broad model that can actually harness enough benefits to drive NFV forward.
One question not yet fully answered is how this open source interest will affect vendor interest in advancing NFV. For network equipment vendors, NFV savings are likely to come, at least in part, through spending reductions that will hurt vendors' bottom lines. Software vendors might be discouraged from developing NFV products, fearing competition from free open source equivalents. For server or cloud vendors, an open NFV model means vendors' efforts to educate buyers and integrate elements might pave the way for an open procurement process the vendor that drove the project might lose.
Key takeaways for increasing NFV deployments
Because the effect of open source on NFV deployments is still relatively unknown, the service-modeling approach becomes the single most important NFV development in 2016. If an open service-model architecture is created, then the design could enable the adoption of either open or proprietary software automation tools at any layer in the orchestration process the model defines. Vendors that can offer a better approach to a specific service lifecycle management problem can still offer it without compromising operators' open infrastructure goals.
Service modeling also opens the important topic of possible NFV adoption opportunities. Most operator NFV trials have focused on a single application, which is virtual CPE (VCPE) for business customers. While this can provide benefits, the majority of operators' customer and infrastructure costs are in other areas. The ability to generate service models for any service means operators can visualize the work needed to support services beyond vCPE. That support could drive the kind of broad deployment of cloud-hosted virtual functions needed to make NFV what operators have always hoped it would be.
A new threat to NFV that started in 2016 and will continue is big operators, like Comcast, AT&T and Verizon, have acquired or plan to acquire content companies -- NBCUniversal, Time Warner, AOL and Yahoo, respectively -- in the hopes of climbing the value chain created by the internet and currently dominated by over-the-top players. Acquisition plans could easily divert senior management's focus away from network transformation. Whether this happens will depend on if NFV can exploit its progress in 2016 to deliver broad benefits in the years to come.
NFV and SDN driving network changes
NFV advances and brings vCPE with it
Open source could bring life to NFV