Network functions virtualization (NFV) has moved from being merely a hot topic to an area of intense focus for service providers. How can they take virtualization from the lab and use it to build new revenue-producing services? An important part of that answer is NFV orchestration.

There are a lot of conflicting views on what orchestration should do and what its scope should be. At times it seems we can’t even agree on what orchestration is, and how it compares to SDN. Multiple organizations have jumped into the water to provide guidance:

• The ETSI NFV ISG has done yeoman’s work in defining the whole notion of “management and orchestration” or MANO. The ETSI NFV reference architecture is ubiquitous, but it is very high level. It does little to specify the next level of detail.
• The MEF has embarked on its Lifecycle Service Orchestration (LSO) project with a focus on Carrier Ethernet services in an effort to define some of the relevant control interfaces and data models. However, this effort is limited in scope to Carrier Ethernet.
• The OpenMANO group is attacking the problem of a common information model with an emphasis on avoiding layer violations.
• The TM Forum has long been involved in telecom management including data models and frameworks. Can it lead the way with the new technologies of NFV and SDN?

These questions and conflicts will not be resolved in the near term. In the meantime, what’s an operator to do? Choose wisely and hedge your bets.

In a time of uncertainty, it’s best to pick solutions that have maximum openness and flexibility, and which address the key requirements. For NFV that means having the following characteristics:

• Actionable intelligence based on collection, analysis and correlation of big data from service, virtual and physical layers as well as IT, cloud and network systems
• Spanning of the physical and virtual, using standard NFVI and multi-vendor control
• Open platform with support from a strong group of vendors
• Carrier class system built for deployability
• Lifecycle management of services, including onboarding of virtual network functions (VNFs), and assignment, management, scaling and reclamation of virtual resources

All of the above are important, but I want to highlight two of them.

Open Platform

Openness equates to choice: the ability to independently select components from different suppliers, including open source, and combine them to create an innovative solution. By sticking with an open platform, you maximize the likelihood that the solution will stand the test of time in market.

How can you know if a platform is open? For an orchestrator, one good measure is the types of interfaces it includes. For example, does it have a well-defined northbound interface to ease integration with existing OSS/BSS systems? Can it support an external VNF manager in addition to its own built-in capabilities?

VNFs are the heart of NFV and innovation depends on supporting a wide and evolving range of VNFs. Another good measure is onboarded VNFs. How many VNFs have already been onboarded? How long does it take to onboard a new VNF? Can operators do the onboarding themselves? The answers to these questions will qualify the openness of the orchestrator. 

Carrier Class

Service providers have very demanding customers and this is reflected in their own demand for solutions that are “carrier class”. The following are ways that this demand applies to orchestrators.

First is scalability. Any orchestrator claiming to be carrier class must use modern web software design to work with tools such as distributed databases and load balancers – just like other web-scale applications.

Next is multi-tenancy, or the ability to support different levels of access and to provide command and control of limited subsets of resources. For example, an orchestrator should allow a service provider to expose a subset of NFV infrastructure to end users as a microcloud, or to other service providers as wholesale NFV Infrastructure as a Service – all while preventing different customers from seeing or altering each other’s resources.

Moving Forward Is Risky … So Is Standing Still

Innovative operators are starting to move forward with NFV, even with the nascent state of standards and the accompanying risk of a young technology. However, they realize that risk can be mitigated by a wise choice of architecture and components. They also realize that doing nothing carries far more risk.

I’ll speak on the topic of NFV progress at TM Forum Live, where my session is titled, “Real-World NFV Progress Report”. I’ll share details on service providers that are making real progress deploying NFV, as well as the questions for which we all need better answers.