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/NFVIFA009, 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 OrVnfm 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 plugin 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 NFVO, 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:
Tacker

ETSI OSM Open Baton Open-o

TENOR

Community Governance

Apache 2.0 license

Mainly but
also Boost
license*

Release

multiple

Rel 0

1st version

Not yet

1st
incomplete

NFVO

NFVO split: NSO/RO

Generic VNFM

Specific VNFM support

OpenStack

Multiple OpenStack

Other VIM

TOSCA

Yang

Dashboard

Portal (?)

Service Orchestrator

*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.universelfproject.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.