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-ETSI MANO
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)

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.

Subscribe
Notify of
guest
137 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
william stallings
6 years ago

Excellent summary! Keep up the good work.

Faisal Khan
Faisal Khan
6 years ago

Thanks William! for taking time to read it!

Faisal

Absar Khan
Absar Khan
6 months ago
Reply to  Faisal Khan

Crisp, clear and ‘sincere’ as always
(two thumbs up by W Stallings!)

javed
javed
6 years ago

Very well summarized, thanks Faisal.

Faisal Khan
Faisal Khan
6 years ago
Reply to  javed

Thanks Javed!

chethan
chethan
6 years ago

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.

Faisal Khan
Faisal Khan
6 years ago
Reply to  chethan

Thanks Chethan! Programming is not my domain :). To the best of my knowledge, it can be any language, as long as long as it can communicate through open interfaces defined by MANO structure. Please refer to the following document to have more pointers.

http://www.etsi.org/deliver/etsi_gs/NFV-SWA/001_099/001/01.01.01_60/gs_NFV-SWA001v010101p.pdf

chethan
chethan
6 years ago
Reply to  Faisal Khan

Thanks for your valuable information Faisal.

Chuong Pham
Chuong Pham
6 years ago

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.

Faisal Khan
Faisal Khan
6 years ago
Reply to  Chuong Pham

Thanks Chuong for visiting and encouraging comments!

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

Chuong Pham
Chuong Pham
6 years ago
Reply to  Faisal Khan

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.

Faisal Khan
Faisal Khan
6 years ago
Reply to  Chuong Pham

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

Kannan KVS
Kannan KVS
6 years ago

That’s an excellent summary.

Faisal Khan
Faisal Khan
6 years ago
Reply to  Kannan KVS

Thanks Kannan, for stopping by and appreciating the blog!

Kunal Modasiya
Kunal Modasiya
6 years ago

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 ?

Faisal Khan
Faisal Khan
6 years ago
Reply to  Kunal Modasiya

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.

Puneet
Puneet
5 years ago
Reply to  Faisal Khan

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.

Regards,
Puneet

Faisal Khan
Faisal Khan
5 years ago
Reply to  Puneet

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

Vishal Shah
Vishal Shah
5 years ago

Nice Summary and excellent way to represent NFV architecture.

Faisal Khan
Faisal Khan
5 years ago
Reply to  Vishal Shah

Thanks Vishal Shah for stopping by and commenting !

Basil Fernandaz
Basil Fernandaz
5 years ago

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?

Faisal Khan
Faisal Khan
5 years ago

Hi Basil,

Thanks, Any module in the MANO should have open APIs connecting with other module.

Faisal

Hassan
Hassan
5 years ago

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

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

Faisal Khan
Faisal Khan
5 years ago
Reply to  Hassan

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

Rajesh Bhosale
Rajesh Bhosale
5 years ago

Excellent & very useful Faisal!!!

Joao
Joao
5 years ago

Thank you very much!!! This is a excellent work and help me to do my work!

Pras
Pras
5 years ago

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?

Thanks
MP

Faisal Khan
Faisal Khan
5 years ago
Reply to  Pras

Hi Pras,

Thanks, As informed earlier. Did you check the C-RAN solution ?

Jie
Jie
5 years ago

It’s a great summary!!! Thanks for your effort to help a learner.

Marjory Sy
Marjory Sy
5 years ago

thanks for this very informative read 🙂

Faisal Khan
Faisal Khan
5 years ago
Reply to  Marjory Sy

Thanks Marjory Sy for visiting the blog and glad that you liked it !

Mohammad Badruzzaman
Mohammad Badruzzaman
5 years ago

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.

Faisal Khan
Faisal Khan
5 years ago

Thanks Mohammad for the encouraging comments and that you liked the article.

Gaurav Sahi
Gaurav Sahi
5 years ago

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

Faisal Khan
Faisal Khan
5 years ago
Reply to  Gaurav Sahi

Dear Gaurav, thanks for your kind words and glad that it helped you.

Brian Callanan
Brian Callanan
5 years ago

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.

Faisal Khan
Faisal Khan
5 years ago
Reply to  Brian Callanan

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.

Thiam Teck
Thiam Teck
4 years ago
Reply to  Brian Callanan

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.

Faisal Khan
Faisal Khan
4 years ago
Reply to  Thiam Teck

Hi Thiam,

thanks for reaching out. Lets discuss it offline. Ping me.

Mia Barl
Mia Barl
4 years ago
Reply to  Faisal Khan

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

Brian Callanan
Brian Callanan
4 years ago
Reply to  Mia Barl

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.

Hosam Al Ali
5 years ago

Very good, thanks Faisal

Faisal Khan
Faisal Khan
5 years ago
Reply to  Hosam Al Ali

Thanks Hosam AL Ali !

joseph payne
5 years ago

Great information in helping to understand NFV MANO, thank you for educating me.

Faisal Khan
Faisal Khan
5 years ago
Reply to  joseph payne

Joseph ! Great that it helped you.

Mamoutou
Mamoutou
5 years ago

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??

Faisal Khan
Faisal Khan
5 years ago
Reply to  Mamoutou

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.

Viswanath KSP
5 years ago

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!

Faisal Khan
Faisal Khan
5 years ago
Reply to  Viswanath KSP

Thanks Viswanth for visiting and commenting!

Amin
Amin
5 years ago

Really good summary & easy to understand explanation

Faisal Khan
Faisal Khan
5 years ago
Reply to  Amin

Thanks Amin that it helped it.

Aernoud van de Graaff
Aernoud van de Graaff
5 years ago

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…

Faisal Khan
Faisal Khan
5 years ago

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.

Karthikeyan P
Karthikeyan P
5 years ago

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.

Thanks
Karthikeyan

Faisal Khan
Faisal Khan
5 years ago
Reply to  Karthikeyan P

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.

Eduardo Ligeiro
5 years ago

That is clear, and perfect for the newbie onboarding on this new NFV era. I will recommend it to my coleagues and customers

Faisal Khan
Faisal Khan
5 years ago

Thanks Eduardo that you liked it and for recommendation.

Sandhya
Sandhya
5 years ago

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.

Faisal Khan
Faisal Khan
5 years ago
Reply to  Sandhya

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.

ShamR
ShamR
5 years ago

Hi,

How is PNF, VNFc, VDU models are linked to VNF.

Thanks

Faisal Khan
Faisal Khan
5 years ago
Reply to  ShamR

Sorry ShamR, the question is not clear to me, if you would elaborate

Manuel
Manuel
5 years ago

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

Thanks..

Manuel
Manuel
5 years ago
Reply to  Manuel

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

thanks

Faisal Khan
Faisal Khan
5 years ago
Reply to  Manuel
Faisal Khan
Faisal Khan
5 years ago
Reply to  Manuel

Thanks Manuel, a good starting point to understand interfaces and reference point is ETSI document “ETSI GS NFV-MAN 001
V1.1.1 ”

http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf

KK
KK
5 years ago

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?

Faisal Khan
Faisal Khan
5 years ago
Reply to  KK

@ KK thanks, usually VNFDs should come from MANO vendor….

Ramzi Bendeddouche
Ramzi Bendeddouche
4 years ago
Reply to  Faisal Khan

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.

Faisal Khan
Faisal Khan
4 years ago

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.

Vishakha
Vishakha
5 years ago

Can existing Network Inventory cots Product support SDN/NFV inventory ?

Faisal Khan
Faisal Khan
4 years ago
Reply to  Vishakha

Hi Vishakha, I believe I replied to you through email

Guruprasad Jayanna
Guruprasad Jayanna
2 years ago
Reply to  Faisal Khan

Hi Faisal, Could you send me the answer/details too. Thanks.

Neelakantan
Neelakantan
5 years ago

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? 🙂

Faisal Khan
Faisal Khan
5 years ago
Reply to  Neelakantan

Hello Neelakantan,

Thanks for stopping to read the blog. I dont have brief on Tail-f

Fatma
Fatma
4 years ago

Thank you so much for making me finally understand MANO!

Faisal Khan
Faisal Khan
4 years ago
Reply to  Fatma

Thanks Fatma, keep coming back !

Atul
Atul
4 years ago

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!
Thanks//Atul

Faisal Khan
Faisal Khan
4 years ago
Reply to  Atul

Thanks Atul, keep coming back.

Faisal

Sheeraz
Sheeraz
4 years ago

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…

Ajay
Ajay
4 years ago

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?

Faisal Khan
Faisal Khan
4 years ago
Reply to  Ajay

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)

Ajay
Ajay
4 years ago
Reply to  Faisal Khan

Thanks Faisal. Makes sense.

Brian Callanan
Brian Callanan
4 years ago
Reply to  Faisal Khan

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.

Jixiangyu
Jixiangyu
4 years ago

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

Faisal Khan
Faisal Khan
4 years ago
Reply to  Jixiangyu

Thank you jixiangyu

vijaya baskar
vijaya baskar
4 years ago

Excellent summary.Thanks.

Faisal Khan
Faisal Khan
4 years ago
Reply to  vijaya baskar

Thanks Vijaya Baskar, Keep on coming

Rohit
Rohit
4 years ago
Reply to  Faisal Khan

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.

Faisal Khan
Faisal Khan
4 years ago
Reply to  Rohit

Thanks Rohit,

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

Amjad
Amjad
4 years ago

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?

Faisal Khan
Faisal Khan
4 years ago
Reply to  Amjad

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.

arvind
arvind
4 years ago

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?

Faisal Khan
Faisal Khan
4 years ago
Reply to  arvind

Hello Arvind,
Thanks,.
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

HARIKA
HARIKA
4 years ago

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,
HARIKA.

Faisal Khan
Faisal Khan
4 years ago
Reply to  HARIKA

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.

HARIKA
HARIKA
4 years ago
Reply to  Faisal Khan

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.

Thanks,
HARIKA.

Faisal Khan
Faisal Khan
4 years ago
Reply to  HARIKA

HELLO Harika,

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

HARIKA
HARIKA
4 years ago
Reply to  Faisal Khan

OK,Anyhow thank you very much.

jp
jp
4 years ago

What protocols are used in these interfaces/”reference points” for the communciation?

Faisal Khan
Faisal Khan
4 years ago
Reply to  jp

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

Sandeep Kumar
Sandeep Kumar
4 years ago

a very informative read Faisal

Faisal Khan
Faisal Khan
4 years ago
Reply to  Sandeep Kumar

Great !

thanks Sandeep that you liked it

Sumit Kumar Karan
Sumit Kumar Karan
4 years ago

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.

Thanks
Sumit Karan
(karan.sumit@gmail.com)

Faisal Khan
Faisal Khan
4 years ago

Thanks Sumit, Stay tuned !

Manpreet Singh
Manpreet Singh
3 years ago
Reply to  Faisal Khan

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 msn322@gmail.com.
Regards,
Manpreet

Sayef Hijazin
Sayef Hijazin
4 years ago

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

Thank you for your effort.

Faisal Khan
Faisal Khan
4 years ago
Reply to  Sayef Hijazin

Dear Sayed,

Glad that it was of benefit to you.

Rohith
Rohith
4 years ago

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 ?

Faisal Khan
Faisal Khan
4 years ago
Reply to  Rohith

Hi Rohith,

Yes they can talk. ve-vnfm is very much a standardized interface

Ryan
Ryan
4 years ago

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?

Faisal Khan
Faisal Khan
4 years ago
Reply to  Ryan

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

FIRAT KUL
FIRAT KUL
4 years ago

Very useful summary

Manu
Manu
3 years ago

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 ?

Faisal Khan
Faisal Khan
3 years ago
Reply to  Manu

Thanks Manu, they can run on same HW

rupee
rupee
3 years ago

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

Faisal Khan
Faisal Khan
3 years ago
Reply to  rupee

Hello Rupee,

Sorry but your question is not clear

askar
askar
3 years ago

very well written. answered a lot of my questions. Thanks a lot.

Faisal Khan
Faisal Khan
3 years ago
Reply to  askar

Thanks Askar

137
0
Would love your thoughts, please comment.x
()
x