Blog

The emerging Docker containers have potential to revolutionalize NFV.

After all, they are lightweight compared to virtual machines; they need less overhead and resources; and, they can provide application isolation running in the same operating system, they live in.

That means,  if a Virtual Network function (VNF) in NFV can run in a Docker container with complete isolation, you may not need a virtual machine.

But, is it that easy? (more…)

So you are in a sprint mode for deploying virtual CPE ( Customer Premises Equipment)?

You, as an operator, want it  FAST. As you want to cut your CAPEX/OPEX or perhaps you want to provision services faster.

But, something is holding you: (more…)

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.

Short on time?

Need a quick refresher on NFV (Network Functions Virtualization) terminology/ architecture in easy to understand language?

Then find below a summary of SEVEN key blocks in NFV architecture, which is all you need to know to get started with the NFV architectural framework. Follow the block numbers and definitions below.

But before that what is NFV? According to ETSI

“Principle of separating network functions from the hardware they run on by using virtual hardware abstraction”

In short, running network functions on commodity generic hardware such as servers using virtualization technology for the purpose of reduced costs.

Now lets have a quick overview of important blocks in NFV architecture as per ETSI

NFV Architecture

1. VNF (Virtualized Network Function):

A VNF is the basic block in NFV Architecture. It is the virtualized network element. For example when a router is virtualized, we call it Router VNF; another example is base station VNF. Even when one sub-function of a network element is virtualized, it is called VNF. For example in router case, various sub-functions of the router can be separate VNFs which together function as virtual router.

Other examples of Virtual Network Functions include firewalls, IPS, GGSN, SGSN, RNC, EPC etc.

2. EM (Element Management ):

This is the element management system for VNF. This is responsible for the functional management of VNF i.e. FCAPS ( Fault, Configuration, Accounting, Performance and Security Management). This may manage the VNFs through proprietary interfaces. There may be one EMS per VNF or an EMS can manage multiple VNFs. EMS itself can be a VNF.

3. VNF Manager:

A VNF Manager manages a VNF or multiple VNFs i.e. it does the life cycle management of VNF instances. Life cycle management means setting up/ maintaining and tearing down VNFs.

Additionally VNFM ( VNF Manager) does the FCAPS for the virtual part of the VNF.

The difference between EM and VNFM should be noted. EM does the management of functional components. While the VNFM does the management for the virtual components. An example would make it clear. In case where Mobile core is virtualized, the EM will do the management of the functional part ( for example issues related to mobile signaling), while VNFM will do the management for the virtual part ( for example issues related to bringing up an VNF itself)

4. NFVI (Network Functions Virtualization Infrastructure):

NFVI ( NFV Infrastructure) is the environment in which VNFs run. This includes Physical resources, virtual resources and virtualization layer, described below.

4.1 Compute, Memory and Networking Resources:

This is the physical part in NFVI. Virtual resources are instantiated on these physical resources. Any commodity switch or physical server/storage server is part of this category.

4.2 Virtual Compute, Virtual Memory and Virtual Networking Resources:

This is the virtual part in NFVI. The physical resources are abstracted into virtual resources that are ultimately utilized by VNFs.

4.3 Virtualization Layer:

This layer is responsible for abstracting physical resources into virtual resources. The common industry term for this layer is “Hypervisor”. This layer decouples software from hardware which enables the software to progress independently from hardware.

Suppose, there is no virtualization layer, one may think that VNFs can run on physical resources directly; However, as such by definition we CANNOT call them VNF nor it would be NFV architecture. They may appropriately be called PNFs ( Physical Network Functions).

The network can also be virtualized using Software Defined Networking (SDN) layer.

5. VIM (Virtualized Infrastructure Manager):

This is the management system for NFVI. It is responsible for controlling and managing the NFVI compute, network resources and storage resources within one operator’s infrastructure domain. It is also responsible for collection of performance measurements and events.

6. NFV Orchestrator:

Generates, maintains and tears down network services of VNF themselves. If there are multiple VNFs, orchestrator will enable creation of end to end service over multiple VNFs.

NFV Orchestrator is also responsible for global resource management of NFVI resources. For example managing the NFVI resources i.e. compute, storage and networking resources among multiple VIMs in network.

The Orchestrator performs its functions by NOT talking directly to VNFs but through VNFM and VIM.

Example:

Let’s say there are multiple VNFs which need to be chained to create an end to end service. One example of such case is a virtual Base station and a virtual EPC. They can be from same or different vendors. There will be a need to create an end to end service using both VNFs. This would demand a service orchestrator to talk to both VNFs and create an end to end service.

Note that VIM,VNFM and NFVO together are also called Management and Network Orchestration (MANO)

7. OSS/BSS(Operation Support System/Business Support System)

Last but not the least in the discussion of NFV architecture– OSS/BSS refers to OSS/BSS of an operator. OSS deals with network management, fault management, configuration management and service management. BSS deals with customer management, product management and order management etc.

In the NFV architecture, the current BSS/OSS of an operator may be integrated with the NFV Management and Orchestration using standard interfaces.

That’s it about NFV architecture !

For more details on NFV including use cases and its relation to SDN, send me an email so I can share NFV mind map with you.

Drop me a comment below and let me know what do you think about this “Cheat Sheet” for NFV Architecture.

Honestly yes!

One router may kill the other router, sooner or later. The “Virtual Router” is showing the performance and power required for carrier grade networks.

So, if you are planning to acquire routers, read on, as you will get useful information on the options you have at hand, now.

In this blog, I question whether a commodity server/ x86 machine has the power and performance to host a virtual router application and if yes what are the advantages of virtual routers compared to the hardware ones.

But, before that, why virtualize a router in the first place? (more…)