Open Source MANO – InApps Technology 2022

Defined in ETSI ISG NFV architecture, MANO (Management and Network Orchestration) is a layer — a combination of multiple functional entities — that manages and orchestrates the cloud infrastructure, resources and services. It is comprised of, mainly, three different entities — NFV Orchestrator, VNF Manager and Virtual Infrastructure Manager (VIM). The figure below highlights the MANO part of the ETSI NFV architecture.

NFV Orchestrator is responsible for managing the functions such as network service life-cycle management and the overall resource management. Service management or orchestration deals with the creation and end-to-end management of the services — made possible by composing different virtual network functions (VNFs). Resource management helps in ensuring that the NFV-infrastructure resources are abstracted cleanly (independent of VIM) to support the services that access these resources.

The VNF Manager oversees the lifecycle (typically involves provisioning, scaling, terminating) management of instances of virtual network function (VNF). It is typically assumed that each VNF will be associated with a VNFM that will manage that particular VNF’s lifecycle. A VNFM may manage multiple instances of the same type of VNF or different types of VNFs.

The Virtualized Infrastructure Manager (VIM), controls and manages the NFVI compute, storage, and network resources. This is the most critical component of NFV-MANO, and it is not surprising that it has received the most attention from the industry.

In summary, when MANO is seen as a single entity, the typical functionalities of include (a) Infrastructure automation and providing consistent, accurate and global view of the resources, (b) Network integration, (c) VNF lifecycle management and its placement in in NFVI, (d) service management, (e) Performance monitoring, analysis and governance (auditing, compliance) support.

The VIM-component has received tremendous focus and various open source solutions such as OpenStack and has been used to realize the virtualized infrastructure management functionality of MANO.

As seen from the above figure, for MANO to function well, it must be integrated with a set of interfaces, preferably open, in the existing systems. According to ETSI, the MANO function is responsible for deploying and connecting hosted elements or virtual network functions.

The telecom industry agrees that to realize various benefits such as enabling greater flexibility, agility and operational functionality; one has to address MANO correctly.

As mentioned by many experts, NFV MANO is one part that is left open, rather widely, to vendor interpretation and extensions. For example, Open Networking Foundation board member Axel Clauberg, of Deutsche Telekom, has noted there is a “zoo of orchestrators” out there – referring to different vendors’ interpretation of what is still a weakly defined component of the NFV reference architecture: the NFV Management and Orchestration (MANO) stack.

Also, Clauberg adds, every vendor seems to market their solution as “open,” but when looked under the proper microscope, it’s difficult to understand what “open” truly means. One should be skeptical of “open” APIs that are still proprietary.

1.1  The OpenStack Dilemma

A popular question that popped up some time back, and probably still exists, is: Should OpenStack be enhanced to cover all aspects of MANO or not? Though some experts suggest that OpenStack is sufficient to fulfill MANO requirements, others argue that OpenStack is an element of the cloud VIM and should be a tool in NFV MANO.

Overall, a majority of the industry experts are against the idea of having only OpenStack for MANO, mainly citing the reason of the presence of legacy equipment or solutions drawn out of legacy equipment. OpenStack lacks specific mechanisms to support many of the services and service components now deployed using legacy network equipment. Also, as many legacy elements have their management and orchestration tools, implementing MANO features, then OpenStack does not need to evolve beyond its mission to manage the infrastructure of the cloud and only the cloud.

On the other hand, since nearly all NFV deployments originate in a cloud, OpenStack, which is extremely popular in managing such virtualized-infrastructure, could be enhanced to support all the NFV requirements. That would make OpenStack even more powerful, and perhaps foster the growth of NFV deployments.

Also, 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. In summary, though the trend is to develop additional orchestrators and managers to work with OpenStack, things may change if such orchestrators/managers do not remain truly ‘open’.

1.2  OASIS TOSCA and its support by MANO solutions

An OASIS standard, TOSCA (Topology and Orchestration Specification for Cloud Applications) aims to standardize how to describe software application and everything that is needed to run that application in cloud environments. TOSCA is designed to facilitate the ‘portability’ and ‘lifecycle management’ of cloud services. TOSCA supports many cloud orchestration tools such as OpenStack Heat, Cloudify, SeaClouds, Alien4Cloud, etc.

1.3  Implementation Challenge – The Current State.

A well-researched study by Heavy Reading quotes that, in practice, a majority of implementers do not stick to ETSI NFV ISG’s description of three functional layers of orchestration in the MANO stack, by not implementing it separately. Also, Heavy Reading also highlighted the confusion caused by splitting the responsibility for resource management between VIM and the NFVO.  Thus, as of today, it may not be wrong to guess that to overcome any vendor lock-in, considering different VIMs (open source and commercial) and VNF-M/NFVO vendors, the operators may be better off to either build some elements on their own (like Telefonica and AT&T) or to initiate open projects to address the challenges.

NFV MANO is typically responsible managing workloads that run on cloud infrastructure. In this section, we will discuss open source MANO solutions that are available, as of today. Before we discuss open source implementations, I would like to provide few commercial MANO solutions, as enlisted below, for those readers who may be interested:

1. Alcatel-Lucent’s CloudBand Management System
2. Ericsson’s Cloud Manager
3. Nokia’s Cloud Application Manager
4. Oracle Communications’ recently announced Application Orchestrator
5. HP’s NFV Director, which spans both NFVO and VNFM realms
6. Wind River’s Carrier Grade Communications Server (extended architecture)

We will classify the open source MANO solutions into two categories: (a) Integration Projects, those who provide complete MANO solution, (b) Subset Projects, those who realize some parts of MANO.

2.1  Integration Projects – Complete MANO Solution

2.1.1  OpenMANO

OpenMANO, a project released by Telefonica, comprises of VIM (OpenVIM), VNF manager and an Orchestrator – as depicted in the figure below. The figure also highlights that OpenMANO can also work with OpenStack as VIM in its architecture. OpenVIM is a reference implementation of an NFV VIM. It is very similar to OpenStack, interfaces with the compute nodes in the NFV Infrastructure and an OpenFlow controller to provide computing and networking capabilities and to deploy virtual machines. It offers a northbound interface, based on REST. OpenVIM is EPA-aware including the feature support such as CPU and NUMA pinning, PCI passthrough, etc.

OpenMANO is the reference implementation of an NFV-O (Network Functions Virtualisation Orchestrator). It interfaces with an NFV VIM through its API and offers a northbound interface, based on REST (OpenMANO API), where NFV services are offered including the creation and deletion of VNF templates, VNF instances, network service templates and network service instances. Also, the NFV orchestrator includes VNF and NS descriptors and is enhanced with platform aware fields, whereas, the VNFM is quite generic and is DSL enabled.

As of today, OpenMANO is a very basic implementation and not suitable for commercial deployment. The source code of OpenMANO can be found here.

2.1.2  RIFT.ware

RIFT.io introduced RIFT.ware to the world at the Intel Developer Forum in August and claimed the release RIFT.ware 4.0, a complete solution for NFV management and orchestration, to the open source community by the end of 2015. However, that claim is not completely true – according to the website, RIFT.ware is available for a limited time to qualifying network application and solution builders through the Early Access Program (EAP).

2.1.3  Open Source MANO

OSM (Open Source MANO) is a project, hosted by ETSI, to develop an open source NFV MANO software stack, which is aligned to its proposed architecture. The project was first demonstrated as an operator use-case at the Mobile World Congress 2016. Interestingly, OSM makes use of both the above projects – OpenMANO and RIFT.io – along with OpenStack and Ubuntu JuJu (described below). Considering the reuse of these projects, it is not surprising that OSM is supported by telcos such as Telefónica, British Telecom, Telekom Austria Group, Korea Telecom, and Telenor, and vendors such as Intel, Mirantis, RIFT.io, Brocade, Dell, RADware, etc.

2.1.4  Open O

Under Linux Foundation, China Mobile is driving this initiative to develop an Open Orchestrator (Open O) for NFV global management and automatic deployment It focus on the VNFM(VNF Manager) and Orchestrator components of ETSI NFV ISG architecture. The project aims to be compatible with open source projects such as OPNFV, OpenStack, ODL, etc. The project is still in very nascent stage, and not much information is available, and I sincerely hope it grows big!

2.2  MANO in Products

2.2.1  The Cloudify Orchestrator

Cloudify is an on open source, cloud orchestration software (rather, framework). As Cloudify allows one to model applications and services and automate their entire life cycle, it has been, rather successfully, explored to use it as part of the MANO solution. Cloudify claims to facilitate deployment of “application/services in any data center environment, monitoring all aspects of the deployed application” – such as detecting issues and failure, manually or automatically fix them. Like many other MANO solutions, Cloudify too integrates well with OpenStack, though it is not bounded to OpenStack (or any specific VIM solutions).

2.2.2  Ubuntu Juju

Canonical’s Juju is the open source generic VNF manager. Rather, it is more of a service modeling system, where services, inter-relationships, and scale can be modeled. This service-orientation makes Juju particularly well suited to the role of VNFM. Using the models provided by Juju, higher-level orchestrators can make the necessary business decisions. Juju models service as consisting of a group of units, and the unit’s count defining the scalability of the service whereas the number of units combined with their relationship to heartbeat defines the availability of the service.

Also, the units may be located in physical machine, virtual machine or containers. Juju, to meet the requirement of Ve-VNFM reference point of being agnostic to the VNF services, uses a standard key-value format for information passed to services. Finally, Juju is particularly good at service composition – the combination of multiple services into a single functional system, which makes it a good candidate for VNFM.

2.2.3  OpenStack Tacker

Tacker is OpenStack project focusing on building an Open NFV Orchestrator and a general purpose VNF Manager to deploy and operate Virtual Network Functions (VNFs) in an ‘OpenStack-managed virtual infrastructure.’ It claims to adhere to ETSI MANO Architectural Framework, providing a full functional stack to Orchestrate VNFs end-to-end. The VNFM part of Tacker can manage basic life-cycle of VNF, including stop/start, monitoring, configuration and auto healing of VNFs. Whereas, the NFVO component can perform end-to-end Network Service deployment, VNF placement control, service-function chaining of VNFs, resource allocation of management through VIM, and orchestrate VNFs across Multiple VIMs

2.2.4  NTT’s Gohan

Gohan is an open-source initiative by NTT to come up with a “service development engine for SDN/NFV Orchestration.” It supports both defining and configuration of resources (service definition) using JSON Schema and policies.  Using this JSON schema, Gohan achieves what they term as “schema-based service deployment” and includes REST-based API server, database backend, command line interface, and web user-interface. A strong use-case of NTT’s Gohan can be found here.

2.2.5  OpenStack-based Projects of OPNFV

The Open Platform for NFV (OPNFV) is a collaborative project, involving service providers such as AT&T, China Mobile, NTT DOCOMO, Telecom Italia and Vodafone as well as IT vendors such as Brocade, Cisco, Dell, Ericsson, HP, Huawei, IBM, Intel, Juniper Networks, NEC, Nokia Networks, and Red Hat. OPNFV’s initial focus is on virtualized infrastructure and corresponding manager.

As an initial step, OPNFV aims to assemble a minimal set of base infrastructure to enable real-world deployments. OPNFV includes various subprojects around OpenStack – Movie, Predictor, Doctor, Copper, Multisite, Promise, etc. – that together can be a standard VIM component of the ETSI NFV ISG architecture.

Cisco, HPE, IBM, Intel and Red Hat are sponsors of InApps Technology.

Feature art via Pixabay.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Mirantis.