NFV MANO: What's Wrong & How to Fix It
|出版日期||內容資訊||英文 63 Pages
本報告提供NFV MANO (網路功能虛擬化的管理和譜) 相關調查分析、必要性和實行的影響、OpenStack、主要供應商等相關的系統性資訊。
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:
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.
Range of NFV Orchestrator Functions in Commercial Implementations
Source: Heavy Reading
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.
NFV Virtualization/Virtualization Management Components by Vendor
Source: Heavy Reading
‘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.
*All charts and figures in this report are original to Heavy Reading, unless otherwise noted.