OpenSource MANO

Marie-Paule Odini, HPE

 

This article provides an overview of ETSI NFV MANO and the opensource landscape in this area.

MANO stands for “Management and Orchestration” and it is the functional block that has been defined by ETSI NFV as part of the NFV Architectural Framework. OSM stands for opensource MANO.

Fig 1 – ETSI NFV Architectural Framework

The NFV MANO covers the orchestration and lifecycle management of physical and/or software resources that support the infrastructure virtualisation, and the lifecycle management of VNFs. NFV Management and Orchestration focuses on all virtualisation-specific management tasks necessary in the NFV framework. It is composed of three building blocks:

• The VIM, Virtualized Infrastructure Manager, manages the NFVI (Network Function Virtualized Infrastructure). This is typically where you find elements like OpenStack.
• The VNMF(s), VNF Manager(s) which manages the lifecycle management of the VNF (e.g. instantiation, update, query, scaling, termination). They may be multiple VNF Manager in charge of one or multiple VNF, or a set of generic VNF Manager that can be configured to manage multiple VNF, or a single generic VNF Manager that would be configured to manage the lifecycle of all the VNF. ETSI NFV is open to those different options defined in GS/NFV-IFA009, MANO architectural options report.
• The NFVO, NFV Orchestrator that is in charge of the orchestration and management of NFV infrastructure and software resources, and realizing network services on NFVI.

But besides these functional blocks, ETSI NFV has defined open interfaces between those blocks, typically:

- Nf-Vi: between the VIM and the NFVI
- Or-Vi: between the NFVO and the VIM => ETSI GS NFV-IFA 005
- Vi-Vnfm: between the VNFM and the VIM => ETSI GS NFV-IFA 006
- Or-Vnfm: between the VNF Manager(s) and the NFVO => ETSI GS NFV-IFA 007
- Ve-Vnfm: between the [VNF-EM] network functions and the VNFM(s) => ETSI GS NFV-IFA 008
- Os-Ma: between NFVO and OSS/BSS => ETSI GS NFV-IFA 0013/0012
- Some of these interfaces are being specified in different specifications that are being issued by ETSI NFV as part of Release 2 and are made publicly available on the ETSI NFV portal. Work in progress is actually also publicly available in the ETSI NFV open area portal.

Fig 2 – ETSI NFV Release 2 Interface & Architecture (IFA)

In parallel to ETSI NFV Specifications, a few opensource projects have been initiated. Opensource projects have different flavors, they may be governed by a single entity or by an opensource community, they may use different licenses, and they make some implementation choices in terms of architecture, language, etc. The focus in this article is to cover Opensource NFV-MANO projects (blue box in Figure 2).

The following table provides a list of MANO opensource projects.

Note that this table may not be exhaustive as a few labs or companies may have released some code on github or other platforms that is not listed here. Some projects are also collaborating and are being covered under this umbrella project: e.g. Riftware and Juju are covered as part of ETSI OSM. Also the objective of this article is not to compare these different initiatives, nor to be exhaustive, but to illustrate the ETSI NFV MANO with some live implementations and illustrate some choices made by some of these different projects.

Also before diving into this topic, it is important to understand that these projects started in parallel to ETSI NFV release 2 specifications, so most of them, if not all, have based their work on ETSI NFV phase 1 released specifications--meaning functional architecture, reference points high level definition and general concepts. They also have different operational modes, typically among the 3 categories described below, knowing that ETSI OSM seems to evolve to model #1 with a more open community governance, while Open-o may pick some existing components like ETSI OSM did and start with a model #2 also before opening up to the model #1.

Fig 3 – Opensource project models

 

OpenStack Tacker

OpenStack Tacker has been around for a few years now. It started as a spinoff from Neutron called ServiceVM and was renamed Tacker and promoted in Vancouver OpenStack Summit in 2015. Initially defined by a handful of people including HP, it was pretty quiet until OPNFV and couple other projects started to look into this code as a tool to exercise the infrastructure for other projects they were working on, i.e. SFC in OPNFV, and map to ETSI NFV VNFM functions.

Tacker is managed under the OpenStack umbrella so it follows the OpenStack community project guidelines and governance model. Step by Step Tacker has moved from being an independent project in OpenStack, to the big tent and now part of the Mitaka release.

Fig 4 – Tacker project evolution in OpenStack

Tacker is working very closely with OASIS TOSCA and provided some requirements for CSD03 version of OASIS TOSCA Simple Profile for NFV which is currently used to define Network Service Descriptors (NSD), VNF Descriptors (VNFD) and VNF Forwarding Graph Descriptors (VNFFGD) using TOSCA templates. These templates are then parsed and translated into Heat Templates and transmitted to a driver that interfaces OpenStack Heat and Keystone.

Fig 5 – TOSCA mapping to ETSI NFV descriptors

Tacker provides an integrated building block for NFVO-VNFM, so does not expose the internal Or-Vnfm interface, but supports external VNFM. As part of Tacker embedded VNFM, following capabilities are supported:

• VNF Catalog with a repository of VNF descriptors (VNFDs) in a database
• VNF Instantiation and Termination using Heat using TOSCA to Heat translation in Tacker
• VNF Configuration injection during instantiation, update and restart using the Loadable VNF specific management-driver
• Loadable per-VNF Health Monitoring
• Self healing according to VNFD policy

 

Fig 5. OpenStack Tacker Architecture

While in Liberty, Tacker was only able to support placement of VNF is a single OpenStack instance, with Mitaka Tacker will support multi-site and having multiple instances of OpenStack VIM, even with different versions.

ETSI OSG OSM

ETSI has created a new type of entity called OSG, OpenSource Group, to allow opensource projects to occur as part of ETSI. The first OSG project happens to be for NFV-MANO, it is called “OSM: OpenSource MANO” and was kicked off in April 2016. It is pretty recent but aggregates some components that have been around a bit longer, typically Telefonica project OpenMANO, Rift.io riftware software and Canonical Juju charms software. All these projects were already available on GitHub as opensource projects. While ETSI has been focusing on standard specification so far, this new initiative is a new model built around a set of opensource development tools such as GitHub, Jenkins, hosted by ETSI and an opensource governance model. While it starts with a set of predefined software it is now open to new contributions to enhance and expand the current project.

The mapping to ETSI NFV Architecture is also very clearly articulated, again at the functional block and reference points level.

Fig 6 – ETSI OSM mapping to ETSI NFV architectural framework

Similar to Tacker, ETSI OSM provides an integrated building block that combines NFVO+ Generic VNFM, supports external specific VNFM, and supports integration with OpenStack VIM, but also other VIM thanks to an open adaptor approach. Integration points exist between the NFV Orchestration function and the VIM, as well as between VNFM functions and VIM, but they do not map currently the ETSI NFV specifications. Similarly integration points exist with Operation Support System/Business Support Systems (OSS/BSS) and specific VNFM as well as [VNF-EM] but not mapping current IFA related specs.

ETSI OSM leverages OpenMANO for Resource Orchestration, and Juju for VNF configuration and management, but OSM also introduces a component for Service Orchestration, provided by Rift.io Riftware which is beyond the ETSI NFV current scope.

Fig 7 - ETSI OSM architecture

ETSI OSM objective is to define an information model aligned with ETSI NFV release 2 Information model. A roadmap is being discussed which basically would issue a Release 0 based on the three independent existing modules (OpenMANO, Riftware, JuJu) with an integrated data model for Network Service and VNF, on git+gerit+jenkins, with documentation, and then follow up releases every 6 months.

Open Baton

Open Baton is an opensource project led by Fraunhofer Focus and TU Berlin. It is now being used by a few European projects and is available under GitHub and apache 2.0 license. Open Baton is also based on ETSI NFV phase 1 reference architectural framework and MANO specifications. It is not aligned yet with the IFA interface specifications. It provides an NFVO building block, a Generic VNFM, a component for EMS, a dashboard, supports multiple OpenStack VIM and provides a plug-in mechanism for other VIM. It also supports specific VNFM.

Fig 8 – Open Baton architecture

Implemented in java with the spring.io framework, it supports VNF Package defined with json to include the VNF descriptors, scripts and metadata, and a link to the image. It supports TOSCA templates that are combined with scripts and metadata into a CSAR (Cloud Service Archive) packages. The NFVO reads these packages and process the data, and returns a json translation of the NSD. The NFVO is using RabbitMQ to talk AMQP protocol to call the VNFM. The Generic EMS will be invoked to configure the new instance. Then the NFVO uses Zabbix to monitor the VNF.

Lifecycle operations supported are: instantiate, configure, start, stop, terminate.

Fig 9 – Open Baton typical call flow

 

Open-o

Open-o is a community project launched by Linux Foundation with a kick off in June 2016. It is a very recent initiative and somewhat surprising to see in parallel to OpenStack Tacker also hosted by Linux Foundation, but there are other topics like SDN controller where Linux Foundation is hosting multiple projects , ie OpenDaylight and ONOS. Anyway, open-o is defining a blueprint and has signed up 15 members, including a number of existing opensource players like Gigaspaces with Cloudify. The current blueprint is a draft proposal that will be discussed, reviewed, potentially updated by the members before approval. Open-o is also calling for code contributions so different players and new players may come to the table, including individual contributors, with code.

Fig 10 – open-o current architecture/blueprint proposal

It is interesting to observe that open-o plans to include elements defined by ETSI NFV such as NFV-O, and integration with EMS, VNFM and VIM, including OpenStack. But open-o, like OSM, is introducing a ‘Service Orchestrator’ component on top of the NFVO resource orchestration function.

In terms of data structure, open-o is proposing to use a GUI for modeling, having a common Information and Data model, perform model conflict detection, both static and dynamic, and use both TOSCA and Yang.

Open-o is also planning to collaborate strongly with other opensource projects, like OpenStack, OPNFV and openCORD in particular as shown in the below diagram

Fig 11 – open-o collaboration with other Linux Foundation projects

Also it is interesting to note that open-o is explicitly referencing an SDN Orchestrator (SDNO) in its architecture, put side by side with NFVO and in Fig 9 above OPEN CORD and ONOS SDN controller. While this is somewhat confusing, it is indeed very interesting to see one of these MANO opensource projects expanding on SDN Controller / SDN orchestration versus NFV Orchestration. Hopefully this will help ETSI NFV progress beyond current EVE005, as well as provide the industry with some clarification of these integration and deployment models.

More to come on open-o in the coming months.

T-NOVA TENOR

T-NOVA is a European project under FP7 program that is now being completed and is releasing some of its work under opensource. This includes a MarketPlace component, an Orchestrator called TENOR, a VIM monitor, and VNF (Virtual Network Function) & NS (Network Service) descriptors.

If we focus on the Orchestration block, as shown in Fig 10, we notice that this block includes both the ETSI NFV Orchestrator (NFVO) split in two functions: Network Service Orchestrator (NSO) and Resource Orchestrator (RO), the embedded VNFM and the metadata & instance repositories. It also provides interfaces similar to ETSI NFV interfaces such as Ve-Vnfm, Vi-Vnfm and Or-Vi. However it does not expose the interface between its NFVO and NFVM, nor provides an open Or-Vnfm to support external VNFM. However it introduces some new interfaces southbound like Or-Tm to the WAN infrastructure – while ETSI NFV is a bit vague but assumes this is Or-Vi. T-Nova is also defining some more explicit interfaces northbound towards the OSS, the portal, dashboard etc, as well as to the Network Function Store.

Fig 12 – T-Nova Orchestrator Architecture

As T-Nova publishes some results on its portal, we will be able to better understand what has been defined by this project. In the meantime, opensource code is also released under GitHub. This includes TENOR, the T-Nova Orchestrator, with some assumptions. For instance the Network Services are limited to 1 VNF, the VDU limited to 1 VNFC. T-Nova descriptors Json schema are translated to Heat templates. Other opensource components include descriptors, a VIM monitor, a marketplace that includes some tools to define network services, a Network Function Store, a rating/billing framework, a dashboard. Some of these elements map high level the ETSI NFV MANO, while others are not in the ETSI NFV scope today, for instance rating/billing or open NF Store.

Summary

In summary, those different opensource projects have different structure, being either driven by a specific group or under an opensource community governance being OpenStack, Linux Foundation or ETSI. They also use different licensing model even though Apache 2.0 is the most common license. And they have slightly different scope, however they all refer to ETSI NFV reference architecture in terms of building blocks, some reference points and high level lifecycle management operations and focus primarily on NFVO and VNFM. A few of them have introduced some additional elements which are today out of scope of ETSI NFV.

Overall these are interesting experiments that provide some closed loop validation of the ETSI NFV specification and should contribute some inputs to either tune the existing specs or expand into some missing areas. It is still very early stage on the MANO opensource space though as we can see with the maturity stage of these different projects.

The table below provides some highlights of the main common elements and differentiators:

 

*Boost license is used in TENOR for some Jsoncon libraries

 

---

 

Marie-Paule Odini holds a master's degree in electrical engineering from Utah State University. Her experience in telecom experience including voice and data. After managing the HP worldwide VoIP program, HP wireless LAN program and HP Service Delivery program, she is now HP CMS CTO for EMEA and also a Distinguished Technologist, NFV, SDN at Hewlett-Packard. Since joining HP in 1987, Odini has held positions in technical consulting, sales development and marketing within different HP organizations in France and the U.S. All of her roles have focused on networking or the service provider business, either in solutions for the network infrastructure or for the operation.

 

Editor:

Laurent Ciavaglia is currently senior research manager at Nokia Bell Labs where he coordinates a team specialized in autonomic and distributed systems management, inventing future network management solutions based on artificial intelligence.

In recent years, Laurent led the European research project UNIVERSELF (www.univerself-project.eu) developing a unified management framework for autonomic network functions. , has worked on the design, specification and evaluation of carrier-grade networks including several European research projects dealing with network control and management.

As part of his activities in standardization, Laurent participates in several working groups of the IETF OPS area and is co-chair of the Network Management Research Group (NRMG) of the IRTF, member of the Internet Research Steering Group (IRSG). Previously, Laurent was also vice-chair of the ETSI Industry Specification Group on Autonomics for Future Internet (AFI), working on the definition of standards for self-managing networks.

Laurent has co-authored more than 80 publications and holds 35 patents in the field of communication systems. Laurent also acts as member of the technical committee of several IEEE, ACM and IFIP conferences and workshops, and as reviewers of referenced international journals, and magazines.