CenturionStudio.it - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Are OpenStack and NFV MANO interchangeable?

Network functions virtualization and cloud management systems appear to overlap, but whether or not the latter can manage and orchestrate a virtual network is open to debate.

At its core, network functions virtualization is a way of deploying software-hosted features on virtualized or cloud infrastructures. Many in the cloud community see an apparent overlap between NFV and cloud management systems, particularly OpenStack. And some vendors exploit this perception by describing their implementations of the ETSI Industry Specification Group's Management and Orchestration (MANO) function as "OpenStack." But are OpenStack and NFV MANO equivalent, and if not, what is OpenStack's role in NFV? The industry has not yet reached a consensus, and each side has compelling arguments.

OpenStack is a cloud management system, not a generalized network management system. It lacks specific mechanisms to support many of the services and service components now deployed using legacy network equipment. Since legacy equipment is not part of the cloud, it could be difficult to evolve OpenStack to include these capabilities. If legacy elements have their own infrastructure manager, and a higher-level management and orchestration tool implements MANO, then OpenStack does not need to evolve beyond its mission to manage the infrastructure of the cloud and only the cloud.

According to ETSI, the MANO function is responsible for deploying and connecting hosted elements or virtual network functions. Similarly, the OpenStack Nova and Neutron APIs host and connect, respectively. Orchestration features in OpenStack projects, like Heat, allow for the efficient, mass deployment of applications and data.

The first question: Together, can Heat and OpenStack meet NFV requirements? The second: Can this combination keep pace with NFV evolution, providing operators with the benefits they expect? Both questions are best answered by looking at the provisioning chain, per NFV specifications, and mapping OpenStack and Heat into that chain.

It's difficult to balance these arguments objectively, given that current NFV proof-of-concept trials don't focus on the issues the arguments raise.

NFV assumes that virtual functions are hosted on NFV Infrastructure (NVFI). The task of controlling the assignment of resources from NFVI to support services belongs to an element called the Virtual Infrastructure Manager (VIM). The NFV management and orchestration process calls on the VIM to deploy a function when necessary. Presumably, MANO service definitions can include multiple references to infrastructure, each activated through an appropriate VIM.

Once we have a clear picture of the provisioning chain, we arrive at the critical question of OpenStack and NFV: Does OpenStack perform a MANO function, or is it a part of the VIM where OpenStack clouds are the target resources? Compelling arguments exist to support each scenario.

OpenStack as a virtualized infrastructure manager

Those who view OpenStack as a VIM point out that it is just one of multiple cloud and cloud management systems. Logically, network operators should be able to use any convenient cloud management system for NFV hosting, and that requirement could easily be met if OpenStack and other CMSes were part of cloud-specific VIMs. Otherwise, you'd have OpenStack orchestrating other clouds, which is illogical.

In addition, OpenStack does not conform to NFV requirements in describing VNFs and how they have to be hosted and managed. Most of the unsupported requirements deal with how MANO would deploy functions, so they are "above" the VIM and wouldn't impact OpenStack if it is actually part of the VIM.

Finally, many believe NFV network connectivity management should be consistent with how networks are created and managed without NFV, because NFV and legacy network elements will share infrastructure for many years, perhaps forever.

Using OpenStack for NFV management and orchestration

On the other side of the debate are those who see OpenStack as a sufficient option for NFV. The current ETSI specifications do not specifically include requirements to manage or orchestrate non-NFV elements. Since nearly all NFV deployments originate in a cloud or virtualized data center that could be represented as a cloud, OpenStack could be enhanced to support all NFV requirements. That would make OpenStack more powerful, and perhaps bring NFV and the cloud closer.

Even if OpenStack needs to be enhanced, that may be easier and faster than developing an alternative MANO implementation "above" OpenStack. The Open Platform for NFV initiative that is responsible for creating an open source reference platform for NFV implementation is currently working upward from the NFVI, and may not reach the MANO level for some time. OpenStack could present a faster path to open MANO, particularly if current efforts to start an NFV initiative within OpenStack lead it to a broader MANO-like capability set.

Bottom line on OpenStack and NFV MANO

It's difficult to balance these arguments objectively, given that current NFV proof-of-concept trials don't focus on the issues the arguments raise. As previously noted, some vendors suggest that OpenStack is sufficient to fulfill MANO requirements; others say OpenStack is an element of the cloud VIM. HP's implementation of NFV, for example, explicitly includes high-level orchestration features that control both OpenStack VIMs and legacy infrastructure managers. That same model, under the project name CloudNFV, was submitted as both an NFV ISG proof-of-concept and a TM Forum Catalyst.

In surveys, operators offered mixed views when asked whether OpenStack should be used. But they also made a point that may be decisive -- current proof-of-concept efforts focused on proving that NFV technology can deploy VNFs correctly are not addressing the need to prove a business case for NFV deployment.

Of the three proposed NFV benefits (Capex savings, Opex savings and service agility), only the first could be addressed with an NFV implementation focusing only on deploying virtual functions. Opex and service agility would require end-to-end service support, extending NFV to legacy elements, and significant operations and business support systems integration not currently needed or provided in OpenStack. That suggests OpenStack should be a tool in NFV MANO, but not the center of it.

Next Steps

NFV orchestration: Encompassing the entire service-chaining process

How Neutron integrates network resources into OpenStack orchestration

Focus on important features when building NFV framework

Get the OpenStack tutorial guide and avoid the hype

This was last published in March 2015

Dig Deeper on Network automation and intent-based networking