Heavy Reading
Length: 63 Pages
Price: $3,995
19 NFV MANO Solution Vendors Profiled
Click here for the full list of companies covered.
63 pages of analysis covering the current shortcomings in how NFV MANO has been defined, and the issues that are affecting vendor implementations
A detailed overview of the progress the OpenStack initiative is making in supporting NFV and what this means for the NFV MANO VIM layer
In-depth profiles of 19 leading suppliers that are engaging with NFV MANO, including the strategies behind their NFV MANO stacks or component products
Key perspectives on NFV MANO from two network operator founder members of the ETSI NFV ISG
Caroline Chappell
Principal Analyst, Cloud & NFV, Heavy Reading
Caroline leads Heavy Reading's research into customer experience management and service provider cloud infrastructure adoption... MORE
To view reports you will need Adobe's Acrobat Reader. If you do not have it, it can be obtained for free at the Adobe web site.

Length: 63 Pages
Price: $3,995
NFV MANO: What's Wrong & How to Fix It

In 2014, Axel Clauberg of Deutsche Telekom a key network functions virtualization (NFV) "mover and shaker" coined the term "zoo of orchestrators" to describe different vendors' interpretations of what is still a weakly defined component of the NFV reference architecture: the NFV Management and Orchestration (MANO) stack.

NFV MANO is the largest source of operator confusion and the biggest barrier to NFV adoption today. Yet it is also critical to the NFV venture: The NFV MANO architecture is responsible for orchestrating and managing the cloud infrastructure on which virtualized network functions (VNFs) execute; the VNFs themselves, as they run in a cloud execution environment; and because we are talking about the network, where network functions don't exist in isolation from one another the services that are composed from multiple, chained VNFs, as they execute across the cloud.

At its simplest, NFV MANO consists of a cloud management system (CMS) and a service orchestration engine that knows how to deploy services composed of VNFs and how to assure those services throughout their lifetime in a dynamic cloud environment. But life is not so simple: first, because a CMS is no better defined than the MANO stack, so different candidate CMSs have different sets of capabilities; and second, because it turns out that a CMS needs significant extension to support NFV. An NFV MANO vendor's implementation is contingent on a number of factors at this early stage in the market, including the kind of VNFs it needs to orchestrate and manage and, perhaps more critically, its CMS assumptions, starting point and partnerships.

OpenStack is the clear favorite of all possible candidates for the CMS or to use NFV MANO terminology, the Virtualized Infrastructure Manager (VIM). OpenStack is immature today and needs significant proprietary extensions to support NFV. This means that each NFV MANO vendor is wrapping OpenStack with its own, non-standardized implementation of these extensions, often displacing them into higher levels of the MANO stack to avoid accusations of "forking" open source code.

Moves are afoot through the Open Platform for NFV (OPNFV) Project and the OpenStack sub-team for NFV to fast-track the development of open source versions of NFV extensions, but at present, vendor support for OpenStack is no guarantee of interoperability between NFV MANO implementations and other components of the NFV reference architecture: VNFs and NFV infrastructure (NFVI) cloud platforms.

In its second, "implementation" phase, the European Telecommunications Standards Institute (ETSI) NFV Industry Specification Group (ISG) intends to focus on creating clearer, prescriptive definitions of the functionality that operators want to see at each level of the MANO stack. Since operators may wish to plug in different vendors at different MANO levels, they don't want to pay twice for the same functionality, or have to sort out conflicting capabilities if they want to offer advanced NFV services, such as NFVI as a service (NFVIaaS) or VNF(s) as a service (VNFaaS).

NFV MANO: What's Wrong & How to Fix It looks at the need for clarification around NFV MANO and new proposals and initiatives that could influence its implementation. It discusses the way in which OpenStack is influencing interpretations of NFV MANO and analyzes the approaches that different vendors are taking to fulfilling one or more layers of the NFV MANO stack.


The report profiles 19 NFV MANO solution vendors, which we classify into three categories:
  • NFV reference architecture vendors the world's largest network equipment vendors and IT players, selling solutions for every aspect of the NFV reference architecture
  • NFV MANO vendors a small, select band of vendors that focus on the NFV MANO stack only and intend to remain neutral regarding VNFs and NFVI hardware and software
  • CMS vendors these vendors sell a VIM capability, and are forging partnerships with larger network equipment providers, in a bid to become a strategic component of their NFV reference architecture implementations
Clauberg's "zoo of orchestrators" has arisen as early implementers of NFV MANO have built extensions to IT CMS in ways that are often highly specific to different VNF use cases and/or NFVIs. In the absence of strong definitions for each of the functional layers of the NFV MANO stack, they have idiosyncratically implemented MANO functionality, especially the additions to the IT CMS needed to support NFV. Most of this additional functionality ends up in implementations of the NFV Orchestrator, as shown in the excerpt below.

The NFV reference architecture vendors are just as confused as the rest of the market about what should go into each layer of the NFV MANO stack, and agree that there is an urgent need for a prescriptive taxonomy. As a result, their NFV MANO implementations remain works in progress. The excerpt below summarizes vendor virtualization and MANO stack partner/product strategies.

Report Scope & Structure

NFV MANO: What's Wrong & How to Fix It is structured as follows:

Section I is an introduction to the report, including the key findings of our research.

Section II assesses the current shortcomings in the way NFV MANO has been defined and the implications for its implementation.

Section III analyzes the issues that are affecting the implementation of NFV MANO.

Section IV looks at the progress the OpenStack initiative is making in supporting NFV and what this means for the NFV MANO VIM layer.

Section V discusses vendor strategies behind their NFV MANO stacks or component products.

Section VI profiles 19 leading suppliers that are engaging with NFV MANO.

Section VII provides two network operator perspectives on NFV MANO.

Section VIII summarizes the conclusions of our research.

NFV MANO: What's Wrong & How to Fix It is published in PDF format.