A Beginner’s Guide to NFV MANO-Management & Orchestration

A beginner of NFV journey faces two obstacles when trying to understanding NFV Management & Orchestration (NFV MANO):

First, he knows already that a traditional network needs just one management system i.e. an EMS (or an NMS) or at most supported by an OSS. The NFV network, on the other hand, needs multiple managers i.e. a VIM Manager, a VNF Manager and an Orchestrator.

And, if they are not enough, there is also the traditional EMS and OSS/BSS. That is, five different management systems. This is enough to confuse a NFV newbie.

Second, there is a dearth of information that describes NFV MANO model in a simple way. For example, a lot of stuff on Google mainly describes vendors’ way of MANO’s implementations.

And if there are standard reference documents that define MANO’s architecture, for example that from ETSI, they not very easy to follow, at least as a beginner.

Yet, we cannot ignore how important it is, to understand ETSI’s model on MANO. For one, ETSI is the pioneer and the only standards body that has done considerable work on defining the architecture and frame work of NFV.

So it is worthwhile, understanding MANO by understanding the ETSI MANO model.

This blog is a humble attempt to present the ETSI MANO model in as simple way as possible.

But before we proceed, let’s ask!

Why it is important for you to know about NFV MANO or ETSI MANO , in the first place?

Because, ETSI MANO acts as the heart and brain of NFV architecture and understanding it will clarify the complete NFV picture to you.

Secondly, this will help you, understanding and benchmarking any vendor’s NFV solution with reference to the ETSI MANO model.

Or probably, you have an upcoming RFP and you want to know what you ought to include for the MANO part.

Whatever your aim is, I hope that you will gain something out of this guide.

What is MANO in NFV?

MANO stands for Management and Orchestration. MANO is a key NFV architectural framework that includes all the essential management modules. It coordinates network resources in NFV framework

MANO is the grey color block in the software architecture diagram below that includes three Managers:

• Virtualized Infrastructure Manager (VIM).
• VNF Manager (VNFM).
• NFV Orchestrator (VNFO).

And a group of repositories (block 4, more on that below).

In addition to the four blocks inside the MANO, there are two blocks outside i.e. the traditional Element Management (EM) and OSS/BSS. While the latter two blocks are not directly part of the MANO, they do exchange information with MANO ,so a learner needs to position them correctly against the MANO blocks.

Following is a description of each of these six blocks starting with Virtualized Infrastructure Manager (VIM)

1. Virtualized Infrastructure Manager (VIM):

VIM manages Network Functions Virtualization Infrastructure (NFVI) resources in “one domain”. (NFVI is the NFV Infrastructure that includes physical (server, storage etc.), virtual resources (Virtual Machines) and software resources (hypervisor) in an NFV environment).

Note the word “one domain” here. So there may be multiple VIMs in an NFV architecture, each managing its respective NFV Infrastructure (NFVI) domain. Keep this concept of “multiple VIMs” in mind as we will re-visit it again during Orchestrator section.

So, what are the typical tasks, VIM delivers?

It does the following:

• Manages life cycle of virtual resources in an NFVI domain. That is, it creates, maintains and tears down virtual machines (VMs) from physical resources in an NFVI domain.
• Keeps inventory of virtual machines (VMs) associated with physical resources.
• Performance and fault management of hardware, software and virtual resources.
• Keeps north bound APIs and thus exposes physical and virtual resources to other management systems.

VIM and NFVI are the current focus of OPNFV Organization. The goal of OPNFV is to provide NFVI, VIM and open APIs to other NFV elements which together form the basic architecture for NFV.

2. Virtual Network Function Manager (VNFM)

VNFM is to VNFs, what VIM is to NFVI.

That is, VNFM manages Virtualized Network Functions ( VNFs). (Just for review: VNF is the virtualized network element like Router VNF, Switch VNF etc.).

Specifically, VNFM does the following:

• VNFM manages life cycle of VNFs. That is it creates, maintains and terminates VNF instances. ( Which are installed on the Virtual Machines (VMs) which the VIM creates and manages)
• It is responsible for the FCAPs of VNFs (i.e. Fault, Configuration, Accounting, Performance and Security Management of VNFs).
• It scales up/scales down VNFs which results in scaling up and scaling down of CPU usage.

There may be multiple VNFMs managing separate VNFs or there may be one VNFM managing multiple VNFs.

Note: VNF is different than virtual machine. Virtual machine is an underlay on which VNF runs as overlay.

3. NFV Orchestrator (NFVO)

If you have gone through sections 1 and 2 above, you will appreciate now, why NFV Orchestrator (NFVO) is needed.

As we saw in section 1 above, there may be multiple VIMs managing respective NFVI domains. This creates challenge 1.

Challenge 1:

Who manages/coordinates the resources from different VIMs, when there are multiple VIMs in same or different PoPs (Point of Presence)?

Again, as noted in 2 above, there may be multiple VNFMs managing their respective VNFs. This creates challenge 2.

Challenge 2:

Who manages/coordinates the creation of an end to end service that involves VNFs from different VNFMs domains?

These challenges are overcome by the following two functions of NFVO.

Resource Orchestration:

NFVO coordinates, authorizes, releases and engages NFVI resources among different PoPs or within one PoP. This does so by engaging with the VIMs directly through their north bound APIs instead of engaging with the NFVI resources, directly.

This directly overcomes challenge no 1, i.e. resource allocation from different VIMs.

Service Orchestration:

Service Orchestration overcomes the challenge no 2, i.e. creation of end to end service among different VNFs (that may be managed by different VNFMs).

Service Orchestration does this in the following way:

• Service Orchestration creates end to end service between different VNFs. It achieves this by coordinating with the respective VNFMs so it does not need to talk to VNFs directly. Example would be creating a service between the base station VNF’s of one vendor and core node VNF’s of another vendor.
• Service Orchestration can instantiate VNFMs, where applicable.
• It does the topology management of the network services instances (also called VNF Forwarding Graphs).

You may appreciate now that NFVO is like a glue in NFV that binds together different functions and creates an end to end service/ resource coordination in an otherwise dispersed NFV environment.

4. Repositories:

It is very important to understand the repositories (like files/lists) that hold different information in NFV MANO. There are four types of repositories

VNF Catalog:

A VNF Catalog is a repository of all usable VNFDs (VNF Descriptor).A VNF Descriptor (VNFD) is a deployment template which describes a VNF in terms of its deployment and operational behavior requirements. It is primarily used by VNFM in the process of VNF instantiation and lifecycle management of a VNF instance. The information provided in the VNFD is also used by the NFVO to manage and orchestrate Network Services and virtualized resources on NFVI.

Network Services (NS) Catalog:

This is the catalog (list) of the usable Network services. A deployment template for a network service in terms of VNFs and description of their connectivity through virtual links is stored in NS Catalog for future use.

NFV Instances:

NFV Instances list holds all details about Network Services instances and related VNF Instances.

NFVI Resources:

It is a repository of NFVI resources utilized for the purpose of establishing NFV services.

The following two management systems are not part of NFV MANO but are described because they exchange information with NFVO MANO functional Blocks.

5. Element Management (EM):

EM is not part of the MANO, however it has important role to play.

Element Management is responsible for the FCAPS (Fault, Configuration, Accounting, Performance and Security management) for the functional part of the VNF. If you recall, VNFM also does the FCAPS of the VNF but only for the virtual part.

To clarify with an example: Generally MANO is only responsible for the delta of the virtual and physical world. Taking VNFM as an example, it does the life cycle management of VNF and its FCAPS. In terms of fault management it means, if there is any issue with the spinning up of a VNF, it will be reported by the VNFM but if the fault is related to a function ( for example, some signaling issue in mobile core) it will be highlighted by the EM.

VNFM exposes its interface to the EM in case an operator wishes to use single GUI for all kind of FCAPS ( virtual + functional)

6. OSS/BSS:

OSS/BSS include collection of systems/applications that a service provider uses to operate its business.

NFV is supposed to work in coordination with OSS/BSS.

In principle it would be possible to extend the functionalities of existing OSS/BSS to manage VNFs and NFVI directly, but that may be a proprietary implementation of a vendor ( or at least the interfaces between EM and VNFs are not yet defined by ETSI as of now) . As NFV is an open platform, so managing NFV entities through open interfaces (As that in MANO) makes more sense.

The existing OSS/BBS, however, can value add the NFV MANO by offering additional functions if they are not supported by a certain implementation of NFV MANO. This is done through an open reference point (Or-Ma-NFVO) between NFV MANO and existing OSS/BSS.

7. Reference Points:

Last but not the least; it is worth mentioning about the reference points.

MANO has multiple reference points that are shown as interconnection points between the functional blocks as shown i.e. Or-Vi, NF-Vi, Or-Vnfm etc.

Why MANO calls them reference points and not interfaces?

MANO does not call them interfaces because “interface” relates to allowing two way communication between entities. The reference point is an architectural concept that defines and exposes an external view of a functional block. And since MANO talks about functional blocks so it uses the word “reference point” instead.

That’s all about NFV MANO.

Let me know your views. If you are an end user, what do you think about multiple management systems in NFV? Do they make sense to you? How do you compare them to your traditional EMS/ OSS?

If you are vendor tell us, which piece you are implementing in NFV MANO and what are your pain points regarding implementation ( if any?).Would love your thoughts, please comment.