Don’t Miss the “Cloud Native Infographic” !

Everything is cloud Native from 5G core to RAN, transport and orchestration. Either you know about it or Nothing about Cloud. In this “FREE” one page infographic poster, I have made it a QUICK and EASY reference for Cloud Native main concepts which are otherwise very complex to understand. Plus get notified when important blogs are published.

Cloud Native Infographic

Don’t Miss the “Cloud Native Infographic” !

Everything is cloud Native from 5G core to RAN, transport and orchestration. Either you know about it or Nothing about Cloud. In this “FREE” one page infographic poster, I have made it a QUICK and EASY reference for Cloud Native main concepts which are otherwise very complex to understand. Plus get notified when important blogs are published.

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).
NFV MANO Architecture

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)


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.

137 thoughts on “A Beginner’s Guide to NFV MANO-Management & Orchestration”

  1. Best info Faisal Thankyou . I need info regarding how to develop VNF. Do i need to use some development kit or something to develop and what is the prog language to use.Pls can i get information related to this stuffs.

    Thanks in advance Faisal.

  2. Thanks for a good summary. It has taken me great efforts to come to a reasonable understanding of the specifications created by ETSI and your summary has confirmed my understanding (and I don’t think I am “that new” to NFV/SDN!). Please keep up the good works! With regards to your question, from an Operator’s point of view, I think having multiple VIMs and VNFs is an advantage. This would allow for very high scalability, future proofing and rapid evolution.

    1. Thanks Chuong for visiting and encouraging comments!

      Actually, owing to diversity of vendors,it is not unusual to have multiple of VNFs and VIMs.

      1. Hi Faisal,
        Yes, I agreed that due to the diversity of vendors, it is not unusual to have multiple VNFMs and VIMs. However, do you think that even if an Operator uses a single vendors for VNFs, multiple VNFMs and VIMs are still used for a range of situations and purposes? I believe the ETSI specifications allow for this situation to occur. A VNFM can control a single VNF (in this case, if there are multiple VNFs then there will be multiple VNFMs), or a group of VNFs. A VIM controls an Infrastructure Domain and there can be multiple Infrastructure Domains within a single Operator’s network.

        1. @ Chuong, it would be perfectly normal to have multiple VNFMs and multiple VIMs from one vendor even in a single service provider domain. This can be because of various reasons. Like usually big vendors have different VNFs developed by different teams with their respective VNFMs or a provider would like to keep some geographical diversity and do distributed resource management using VIMs in multiple locations.

  3. Excellent blog. Very simple language and I keep telling my friends that if you can NOT understand NFV by reading this blog, then you will never understand 🙂

    I have a few questions below.

    1) Service Orchestrator is suppose to do both VNF and PNF(Physical Network Function) together. In actual network deployment, as a part of Service chaining (end-to-end), operator would have to create service on Physical network, then on Virtual NE. Operator certainly wants a 1 interface/software which can do both.
    2) How does OSS/BSS interacts with Service Orchestrator and why do they need to interact at first place ?

    1. Thanks Kunal that you liked this piece.
      1. Service Orchestrator is NOT suppose to do both VNF and PNF as per MANO model. MANO model is for the virtual environment, that is the VNF. However if a commercial service orchestrator supports managing physical PNFs, that can be said as enhancement to the MANO model. Having said so, the current initiative by MEF regarding LSO includes exactly that as one of the features, that is service orchestration across both PNF and VNF.

      2. The OSS/BSS in principle, does not need to interact for VNF service orchestration. However it may need to, if it is providing some features which a service orchestration does not provide or an operator prefers to use its existing OSS to do service provisioning. Take an example, an Operator has an OSS in place already. He introduces NFV in his network with its own Service orchestrator; However he still prefers to use his OSS for service provisioning because he is already used to the interface/GUI of his OSS. In that case, MANO model provides a standard way for an OSS to interact with the VNF orchestration.

      1. Hi Faisal,
        Good summary!
        Why there isn’t an interface defined between OSS/BSS and VNFM? Will there be any scenarios where OSS and VNFM needs to talk to each other? Say, for example, an operator may like to have a VNF scaled up based on a threshold alarm that was received by OSS. So, OSS calls VNFM to trigger scaling of VNF.


        1. @ Puneet thanks !

          VNFM has limited scope of managing a VNF. Orchestrator has a much bigger scope of managing cross domain resources and services. As such it is enough for the OSS to have interface with Orchestrator. In case it needs to talk to VNFM, it can always do so through the orchestrator. In the example you gave, it would be enough for the OSS to call directly the orchestrator to perform this function. The orchestrator in turn has direct access to both VNFM and VIM to scale the resources.

  4. Great information in simple terms..
    Thanks for sharing.
    One Quick Question, Could you also mention what are all the module are configurable/programmable via API?

  5. I guess this is a typo in “Service Orchestration can instantiate VNFMs, where applicable”.

    it should be ” Service Orchestration can instantiate VNFs, where applicable.

    1. Thank you very much Hassan! for your kind comment.

      The statement is correct. “Service orchestration can instantiate VNFMs”. However Service Orchestration can can also instantiate VNFs but for that it needs coordination from VNFM. Therefore VNFM is very much involved in instantiating the VNFs and that is why the I put the statement like that.

      Reference : ETSI GS NFV-MAN 001

  6. Hi,
    Is there any information available on what is missing in today’s NFV/OPNFV for RAN (Radio Access Network) applications, say base station. In other words, if we have to put LTE base station/eNodeB in NFV/OPNFV framework then what are the challenges?


  7. Mohammad Badruzzaman

    Thanks Faisal.

    I am a new come in the NFV area and this is the second article I am reading about NFV. But it was very well explained that I believe I understand all of it.

    Nicely done. Hope to learn more from you.

  8. Very well articulated and at the same time very simple language to explain the concepts.
    Enjoyed reading and keep up the good work.

  9. Decent article for the layman. Where I have a different opinion is the support of the VNFM. I’m a developer working for Overture Networks on the Orchestrator(Mano Layer) Platform. I’ve seen quite a few vnfs. Only one of them ever had their own supported VNFM and that was Nokia’s vEPC. We integrated it into our Orchestrator as a java interface/adapter model. Standard kind of OO Design stuff. Their VNFM supports a Restful JSON interfaces that has create/destroy/scale type of apis.

    I’m aware of at least one other VNFM that has a VIM layer in it. Unless we get a customer request to integrate with it, its a non-trivial task. to do so means about 1-2 months of effort. Same adapter model as the Nokia’s integration.

    What I’ve seen more of is a hybrid model where the VNFM has no VIM layer but manages the service chain of the VNFs its responsible for as a controller of sorts. Not quite an ems mind you, but one that would support HA deployments of their vnf. Only the more complex VNFs have this kind of need. The simple router based service chain will not have a VNFM.

    An orchestrator should support its ‘own’ internal VNFM implementation. I’m am of course impartial to our implementation, however, I believe a service chain once orchestrated should pass traffic out-of-the-gate. I’ve coined the phrase ‘breathing-life’ which is considered the setup of the vnf to pass traffic.

    Not every vnf supports cloud-init, nor is every vnf built as a cloud application. Many times, its the software that’s been ripped out of a box and a pretty bow is place on it saying its virtual. When you get past the bow you find its a clunky pile of hot mess.

    So, can Heat Templates work… NO. You need more tools in the bag of tricks so properly orchestrate this kind of VNF. I thinks that the differentiation IMHO between MANO products on the market today. Ones that provide the bag of tricks and the ones that don’t.

    While I agree that the ETSI model is a good start there are many shortcomings there as well. And there are also vendors that don’t follow it. So, what do you do then? Well, you come out with a solution that has agnostic features to support the 80-20 rule. Then try to increase that to 90-10… So, where are we… In the process of the target or 95-5. Yes we also tie virtual-to-physical as well… If you’re going to do NFV you better be able to do that if ever you want to pass traffic.

    1. Thanks Brian Callanan for your insights! I don’t think there is anything wrong with MANO. Just that some vendors have combined the functionality of the multiple blocks instead of the dis-aggregated model which MANO presents. It really boils down to what the customer needs and where he is comfortable with. I agree with you, some customers many not need VNFM but I have also seen some customers that do. Where MANO is suffering is the lack of standard APIs on many interfaces, which would mean many so-called open interfaces but -than so many eco-systems of the OPEN MANO systems. This is putting stress on both vendors and customers.

    2. Thanks Faisal for the great summary. And also the insight from Brian Callanan.

      I am actually having similar questions with one of previous commenter regarding how to develop VNF, because I don’t wish what I deliver to be another headache for people like Brian. 😛

      If I just want to focus on develop the VNF itself, without develop my own VNF Manager or bundle with an open source VNF Manager. How shall I ensure it will work well with most of the MANO ?

      For example, if the application is developed as a cloud application, does it means it will be need only minimal effort to be deploy as VNF instance that can scale properly just like how it scale in most of the cloud environment?

      Thank you.

        1. Hi Brian, you are discussing this offline – is there a way I can also get the info?? I am highly iterested

          1. Recently, I participated in the plugtest event ETSI held in Madrid back in February ’17. There were 14 VIM providers and 2-3 dozen vnf providers.

            When NFV started 4 yrs ago VNF providers (few and far between) were basically doing a direct port from their appliance to a Software only VNF QCow. The VNFs weren’t cloud ready and hardly supported simple things like SSH and a Linux CLI.

            Many had cryptic menu’ing systems (some still do) and getting a license to make them work was like pulling teeth.

            What I saw at the event was a move by the various vnf providers to support CloudInit (rely’s on Openstack Metadata Service – sits on top of EC2 standard). Not all VNFs but more than I expected. I think the reason(s) for this, could be, due to configuring a VNF/VM with a heat template and shipping a simple document with the VNF that has the heat template.

            Heat templates must be maintained of course and that doesn’t scale. However, it allows the vnf vendor to get out of the role of hand holding the customer and lab POCs.

            So, if you’re trying to make a NFV ready VNF make sure the vnf/VM linux based os type supports the cloudinit client and provide any configuration needs as metadata key/value pairs. And possibly any needed user data scripts.

            A production environment must scale the solution and heat templates (IMO) is not the way. Heat template (again IMO) is a poor mans orchestrator. Many orchestrators use heat, however, more complex service chains that require additional assistance during service orchestration push the limits of Heat. But alas, that wasn’t your question.

            An truly agnostic orchestration platform provides a set of tools in the tool bag to handle the variety of VNF Provider configuration needs. Although cloudinit is gaining support other techniques are required. On-boarding a VNF shouldn’t be that difficult but it rely’s on having tools at your disposal.

            The Open Source projects that cover MANO solutions (IMO) are well behind in this area. I’ve reviewed the code and studied the architectures. True I work for a commercially available MANO solution but I’ve done my homework on this initiatives too.

  10. Thank you very much, all the concepts are well explained.
    I’m a biginner in the NFV area and thanks to your blog I learnt a lot, but there is just a point I’d like to clarify because I wonder if I well understood this specific part, In fact that is about the location of VNFs before their instantiation, I think they are stored in the Infrastructure domains and a VNFM can instantiate a specific VNF on a VM(that already has the software image of that VNF) by using the corresponding VNFD, but I’m not really sure of that, can I have your point of view??

    1. Thanks Mamoutou,

      You are correct, however VM does not necessarily need to have a VNF image already on it. VNF can be called and instantiated on a VM on the fly.

  11. Wonderful explanation. I am a newbie to SDN/NFV and my mentor had asked me to explore on MANO. As you had rightly pointed, there are multitude of information available in internet, however the explanations are not structured for a newbie like me to consume.

    You just connected the dots and now it all makes perfect sense.

    Keep up the good work!

  12. Aernoud van de Graaff

    Thank you. A nice high level and simple overview. Coming from the IT side where clouds are getting to be ‘normal’ I can understand the NFVI and VNFs (applications). But I had a hard time exactly understanding the function of the MANO in this all. This have become much clearer.

    What I am still trying to understand is what you would miss out (what goes wrong) if you do not have a MANO. What I see at this point is that resources are handed out manually and fixed. Even if the NFVI layer is capable of smart resource distribution, giving sufficient capacity to the VNFs, this function is rarely used (be I have only been involved in just a few implementations). Also at this point where most operators only deployed just a few VNFs they probably still have an overview of what is happening (something that will disappear once you implement more and more VNFs).

    So except for scaling, what else are you missing out on when you do not use a VNF or what (business) benefits do you get when you do use a MANO…

    1. Thanks Aernoud, for your time and thoughtful comments

      MANO gives a complete framework and a target architecture. The initial implementation from vendors would not be a complete framework but some pieces where they can roll out VNF and NFVI quickly. Also I have seen vendors combining blocks to make the implementation simpler for them. The focus is more on the product roll out and first to market rather than sticking to MANO. The full implementation of MANO with its given blocks will definitely help a customer in the long run who wants to rip and replace one part of the MANO with another vendor’s product.

  13. Hi Faisal,

    Thanks for the detailed Explanation about the NFV Concepts, I have a query here:
    As you said:
    Element Management System is responsible for the FCAPS of VNF. If you recall, VNFM does the same job. But EM can do it through proprietary interface with the VNF in contrast to VNFM. However EM needs to make sure that it exchanges information with VNFM through open reference point (Ve-Vnfm-em).
    In what way we can Exchange information with the VNFM when we are trying to establish/Integrate a Performance and fault Management system for Monitoring the VNF’s. Say, either we can try establishing a connectivity using SNMP/TCP protocol or directly we can read the Log file of VNF’s for collecting Fault/Perf data.
    Also when we are trying to establish any reference point between MANO and OSS/BSS, what could be that reference point, How basically we can Integrate them.


    1. Hi Karthikeyan,

      You asked valid questions but the exact details of these reference points are not defined by ETSI. That is a big issue today which has led the vendors implementing them in their own way, although with so called “open interfaces”. ETSI has left it to the other SDO bodies to define the low level details of these interfaces.

  14. Brilliant explanation Faisal !
    Simple yet a vivid way of explaining concepts!

    I would like to know, the distinct differnce between VNF and VNF instance, if any.

    1. Hi Sandhya, Thanks.

      VNF is virtual network function. The action of creating and bringing up a VNF is called VNF instance. For example you may buy a single router VNF and if you have multiple license, you can create multiple VNF instances at one time. And you you can also kill any instance at any time. VNF instance is therefore more related to the life cycle of a VNF.

  15. Thanks for the explenation.

    I have a question about refference points.

    I Quote:

    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.”

    What is your source? I have search many info about the architecture on ETSI and many other whitepapers from vendors.. They all talk about interfaces..


    1. focus of the question.. why not two way communication for Mano? is this not possible between functional blocks?


  16. Thanks, Faisal for your simple explanation on MANO, which makes us easier to understand this.

    However, I have a doubt here that, is the VNFDs come from the VNFs vendor? Or from MANO vendor? Or developed by operator itself?

    Do you have a real sample of VNFD?

      1. Ramzi Bendeddouche

        Hi Faisal, I am sorry but I disagree with you here, as the VNF vendor is in the best place to know what their application needs in terms of compute and storage resources. the MANO vendor translate these parameters and apply them through the VNFM engine.

        1. Hello Ramzi, Thanks for commenting. May be there is a misunderstanding as the article does not say that MANO will decide this one your own. Of course it has to be the VNF vendor that specifies its requirements.

  17. Nice Summary and thanks for your efforts put across in sharing your knowledge to wider forum in simple and easy language to understand. Much Appreciated!

    Do you have any such brief about Tail-F? 🙂

  18. Faisal,
    You blog is really great. I started working on NFV 3 month ago only but never get so much clarity about the NFV blocks until now. Awesome work Man! Specially people like me who don’t want to go into deep down to understand everything. Specially your Mind Map is superb!

  19. Excellent job done bro…:) would be great..if you have some idea on type of services required in virtualization…like 1) implementation of VNF from NFVI/MANO perspective,
    2) implementation of VNF from VNF vendor perspective
    PLANNING, 3rd line support, and managed services for the above two lines…what unit of measure can be used…

  20. Thanks Faisal, Very well articulated

    As a beginner, had a couple of doubts.

    Typically, in Pre-NFV ‘Physical network’, OSS applications such as Network Performance Monitoring applications such as Network Event/ alarm monitoring applications receive events / stats directly from physical network elements or EMS.

    In case of NFV and MANO context, will these events, alarms /stats still be passed to OSS directly from VNFs? Or would those be routed via VNFM?

    Also when you say, VNFM is responsible for the FCAPs of VNFs (i.e. Fault, Configuration, Accounting, Performance and Security Management of VNFs). Are we saying VNFM will overlap OSS functionalities? obviously it wont be able to make alarm correlation when alarms are received from multiple VNFs. So is MANO suggesting to split the performance and fault management functionality across OSS and VNFMs? or the functionality of VNFM is to receive the alarms and forward to OSS/BSS?

    Also Does the orchestrator has any role to play in Network assurance space?

    1. Hello Ajay,

      Very good question !

      One thing to be clear is that the NFV MANO is responsible for the delta of the physical and virtual world. VNFM does FCAPS on the VNF level. and can expose the information to the EM also.However to be clear the Functional part of the VNF ( for example if you have a a mobile EPC where a fault is directly related to the functional issue of the core but not related to virtulization, will be dealt directly by the EM) so in that case there is no overlap. The MANO does the FCAPS for the virtual part only and the EM does it for the functional part. Still the VNFM expose the FCAPS for the virtual part to the EM. OSS function is the same in the virtual or physical world. It has access to the MANO through the orchestrator and through EM , these two expose their FCAPS information to the OSS thus enabling OSS do the FCAPS through single pane of glass ( single GUI or window without the operator do his work multiple interfaces like EM or orchestrator or VNFM)

      1. ETSI is trying to issue some standardization of VNFM interfaces to provide FCAPS to EMs. However, I don’t think they are there yet. I would call this a hybrid or an adapter interface to provide this functionality.

        In many cases this EM is virtualized. So, there are certainly additional considerations beyond the normal approach. Only by peeling the onion do these considerations become understood.

  21. Hi,Faisal,thanks for your contributions to the NFV domain.
    I’m every excited to see that you simplify the complicated technology.

      1. Faisal can you help understand on the implementation of this architecture in real world with an example. To say today operators use oss/bss for customer order delivery. Will the front end system become Service orchestrator or the existing OSS/BSS will be used and then OSS integrates with orchestrator to deliver services.

        1. Thanks Rohit,

          OSS/BSS does not change. Orchestrator can get integrated with OSS, thus your front end remains same.

  22. Thanks Faisal for this informative blog. This is very useful to understand MANO in simple terms. I have a query regarding integration of the NFVO with traditional OSS/BSS. Do you see any major challenges when operator goes for integrating NFVO with existing OSS/BSS for fulfillment of VNFs, which might call for new function like orchestrator of orchestrator on top of traditional OSS/BSS & NFVO?

    1. Hell Amjad,

      Thanks for reaching out. Yes their will be challenges as the interfaces are not defined. By definition , I mean what protocols would be used for such integration. Bear in mind that ETSI is defining architecture and high level information elements that will be exchanged between the blocks. What it does not tell you is to use a particular protocol like YANG, REST, OPENSTACK etc….This is left to other standard bodies.

  23. Thanks Faisal for the wonderful article !!!

    Your valuable comment is needed for the following queries:
    1. what is VNFC?
    2. I could not understand “MANO is responsible for delta of physical and virtual world”.
    3. what would be the challenges on FCAPS with the hybrid network (OSS BSS/ NFV)?
    4. Will there be a situation where OSS will be phased out completely? How NFV deal with the situatin?
    5. In your article, there is no role of SDN. Can we achieve the virtualization without SDN?

    1. Hello Arvind,
      1. VNF may be composed of multiple VNFCs, whereas each of them reside in a different virtual machine. For example a a router VNF may be composed of sub VNFs called VNFCs.
      2. Means will not replace the NMS or OSS of today. it will just provide the delta functionality which is limited to managing the virtualization part.
      3. FCAPS for the functional part will stay with the current OSS. The FCAPs for the virtual part of the VNF will be managed by the MANO.
      4. OSS and MANO functionality are complimentary and one will not replace the other.
      5. Yes you can

  24. Hello,

    I am an undergraduate working on SDN & NFV . You summarized NFV Architecture very well.I have a doubt ,I was given a task to look into ” MANO EFFICIENCY EVALUATION and measures to improve them”.I have one doubt does the term MANO always means NFV-MANO or it also means management and orchestration techniques used in traditional networks.And also can you please help me on which aspects should i need to look into to evaluate MANO’s efficiency.

    Thanks in advance,

    1. Thanks Harikha for asking important question.

      It is only and only NFV focused and not for traditional network. However it has interface to the OSS and thus OSS can talk to both NFV and non NFV domain. Your second question is not clear.

      1. I have to work on “MANO EFFICIENCY EVALUATION AND MEASURES TO IMPROVE THEM”.How do I start working on it?When I search online I am finding plenty of papers on diiferent orchestration mechanisms on non-NFV domain.Can you suggest me some resources like some research papers to start with.


        1. HELLO Harika,

          No idea. Try either ETSI website or IEEE if someone has done relevant research on the topic.

    1. Hi Jp, Currently these protocols are not completely standardized.The other standard bodies like OPNFV are working on providing standards here. Already there is a lot of work done on the interface between VIM and the NFVI

  25. Sumit Kumar Karan

    Dear Sir,
    I am working in Telecom OSS/BSS since last 12 years, well versed with traditional OSS solution setup for a service provider but now we have NFV, SDN are the new one which are getting introduced in Service Provider’s N/w. do you have any write up for beginner to understand SDN basics and then go ahead as always i see about SDN and it starts with “Separation Between Control plan and Data plan” ..but difficult to understand this clearly, I am expecting something similar to what you have come with NFV.

    Sumit Karan

      1. Hi Faisal,

        I would like to comment on this Where VNF is divides in Control Plane & User Plane.
        Split Architecture functionality of VNF’s.
        Please post me on

  26. Very useful explanation,,, You really made it much easier to understand the diff between all these elements.

    Thank you for your effort.

  27. Excellent explanation!!!!

    I have a doubt regarding the ve-vnfm intreface between VNFM and VNF’s.

    Is it possible that a VNF of one vendor can talk to VNFM of another vendor . Does it use REST ?

    Inshort: Would the ve-vnfm interface be standardized or is it proprietary ?

  28. I am a very newbie to the world of telcom. but this is the best NFV information I could understand by my first attempt to read through it. It is simple clear and effective. Many thanks for the effort to write it up.

    I have a question regarding the difference between VIM and EM. To me they both manage physical resources. Does VIM is only related to the physical resources for those VNF, like the server machine?

    1. Thanks Ryan,

      VIM mange the virtual resources ( as the name also sound), EM does not manage resources, it only manages the functional related part of VNF. For example how to configure a VPN in router, what alarms are reported when a VPN down etc….

  29. Hi Faisal,

    Much appreciate your effort to sum up this in best way.
    We are using VNF -Life Cycle Management tool to bring up Virtual Nodes (as VNF Instances).
    Does the NFVO & VNFM needs to be a separate hardware or can this run as a service on same hardware ?

  30. Hello Faisal ,
    It’s rupee here , can you please explain how we can communicate with VNF manager of MANO through rest API .

  31. Excellent summarization Faisal. Well done !!! It shows a very insightful and clear understanding of the concepts and terminology.

  32. Hi Faisal, thanks for sharing your knowledge.

    It is my understanding that in the NFV architecture, the telecom network functions (e.g. MME, PGW, CSCF, HSS, etc) are the “things” being virtualized. In other words, an NFVO will use a VNFM to instantiate, for example, an MME as a VNF.

    However, complex network functions such as an MME are likely to be made up of more than one monolithic piece of software, and instead have several internal components that each needs to run on separate virtual machines. So, what does ETSI call each of the VMs which make up a VNF? Is that what I see being referred to as a VNFC in some places? And finally, is the VNFM for such a VNF the only entity that should really know (or be required to know) how many of these VNFCs and what type of VNFCs are needed to be instantiated in order to create a functioning VNF?

    1. Hello JC, thanks for sharing your thoughts.

      >>>>It is my understanding that in the NFV architecture, the telecom network functions (e.g. MME, PGW, CSCF, HSS, etc) are the “things” being virtualized. In other words, an NFVO will use a VNFM to instantiate, for example, an MME as a VNF.


      >>>>>However, complex network functions such as an MME are likely to be made up of more than one monolithic piece of software, and instead have several internal components that each needs to run on separate virtual machines. So, what does ETSI call each of the VMs which make up a VNF? Is that what I see being referred to as a VNFC in some places?


      >>>>>And finally, is the VNFM for such a VNF the only entity that should really know (or be required to know) how many of these VNFCs and what type of VNFCs are needed to be instantiated in order to create a functioning VNF?


  33. Dear Sir,
    People are getting confuse about EMS and VNF/M and their responsibilities.
    VNF can contain any network elements like JC said.
    1. EMS dose the (e.g. MME, PGW, CSCF, HSS, etc) FCAPS as it was plus newly some information about VNF from may be PM and FM point of view./?
    2. NFVM dose only life Cycle Management (LCM) . And they are : installing VNF/MME, de/coupling VM, increasing CPU of VNF/MME, tearing down VNF/MME, etc… May be we should talk more about LCM of VNFM. as well as FCAPS of responsibility of NFVM. What is virtual part of VNF.

    Can you please comment on these issues?


  34. Thanks Faisal,

    This info is very useful for beginners, I have a query related to FCAPS in ETSI MANO

    All ETSI MANO interfaces are based on REST, and SOAP is not in the standards.

    Do we support SOAP

  35. Hello Faisal Khan, As a beginner reader of NFV, This artical is very helpful. If you could guide me more about reference point. How phyically they looks like and work on what standards if we compare with with interfaces or ports in IP/transmission world.

    1. Thanks Tariq, consider reference point as group of interfaces, it is not single interface; that is why it is not called interface

  36. Abhay Narayan Katare

    Simple and easy explanations , Thanks Faisal for this.
    One naive question. Could you just tell me is there any difference between ETSI NFV and ETSI MANO, is this really different things which combines to a complete solutions. ( I mean under MANO- Orchastrator, VNFM, VIM lies and NFVI, VNFs are part of ETSI NFV ? )

  37. Very useful article. Summarizes what would otherwise have meant going through multiple documents and interpreting abstract concepts. Thanks Faisal!!!

  38. @Faisal Khan:Sir, excellent piece written in fact for everybody to have initial understanding of NFV MANO architecture. Most interesting point for me was the mapping between abstract knowledge & existing network architecture to ultimately eradicate any ambiguities regrading NFV. I am again thankful to you and will like to communicate further on this with you.

Leave a Comment

Your email address will not be published. Required fields are marked *