A Cheat Sheet for Understanding “NFV Architecture”

Short on time?

Need a quick refresher on NFV 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 architecture. Follow the block numbers and definitions below.

NFA Architecture

 

1. VNF (Virtual 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 VNF 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, Perfomance 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 signalling), while VNFM will do the management for the virtual part ( for example issues related to bringing up an VNF itself)

4. NFVI (Network Function Virtualization Infrastructure):

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

5. VIM (Virtualized Infrastructure Manager):

This is the management system for NFVI.  It is responsible for controlling and managing the NFVI compute, network 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.

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

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 !

For more  details on NFV including use cases and its relation to SDN, I invite you to download the NFV mind map at the link in the header section. I have created the NFV mind map to make the concepts easier to follow so you can use it as reference.

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

113 thoughts on “A Cheat Sheet for Understanding “NFV Architecture””

  1. Pingback: The Ultimate Guide to the Role of SDN in NFV – TelcoCloud Bridge

  2. Thank you so much Faisal. You made it simple.

    Secondly, Can you please explain what is SDN? How is it related to NFV?

    Thanks,
    Pradeep.

  3. Hello Mr. Faisal Khan,
    It was a great brief introduction to NFV Architecture, which helps me to understand the concept easily.
    Thank you so much.

  4. Hi Faisal,
    thanks a lot for the explanation. I have 2 questions:
    1. can you give more details on ve-vnfm reference point? I need to understand the real usage of it in telecom world!
    2. do we realy need this interface? why?
    thank you

  5. Excellent contribution to the people who is joining NFV world! Very clear to understand. Thank you so much Faisal!

  6. Pingback: Network Functions Virtualization (NFV) – Tri-Hai Nguyen

  7. Thanks a lot Faisal,

    have a very fundamental question , sorry may sound too basic.

    As i understand NFV can run on a VM, questions are:
    1. What should be the specifications of a VM
    2. what should be the underlying OS, does it matter ?

    -Rao

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

    Thank you for your effort.

  9. Najeeb Sadaat

    Bunch of thanks Mr.Khan. Your explanations are really comprehensible and easy to understand. Appreciate your efforts.

  10. Greetings Faisal Sb,

    Thanks its Remarkable. Though I am a telecom engineer with Legacy background but easily grasped your NFV explanation in my first reading . I have shared your valuable research work in my circle (ETISALAT ) .

    Regards,

  11. Hello,

    Great article. ONe question, if a running VNF fails or abruptly shuts down, then who (VNFM, EM or orchestrator) is responsible for replacing it with a new one?

    Thanks,
    Sunil

    1. Thanks Sunil,

      There can many reasons for failure. However just understand that VNF runs on a VM. In general if just a VM fails, then VIM should bring up a new VM, if VNF application fails, then VNFM should bring it up. Orchestrator can do it also but only through involving the VNFM.

  12. well explained and presented, thank you for taking time to throw more light on NFV..

    I am written my thesis on NFV, can you please provide me other links to get materials for research.

  13. A well presented overview! I’m a little curious though why you insist that an VNF cannot be implemented by a physical resource? After all – physical routers have provided virtual routing functionality for many years. It seems to me that the router is just providing the virtualisation layer, although the implementation under that will be proprietary, although can likely still be mapped to the NFVI model.

    1. Sure Ian, it is totally possible to run virtual router functionality over the physical router. its just that it is not what the spirit of NFV is all about ( that is use commodity server of switch instead of commercial stuff)

  14. Great article. Rightly named as cheat-sheet. Keep going 🙂

    BTW, I have a question on reference points. Os-Ma, Se-Ma, Ve-Vnfm, NF-Vi are reference points as per your diagram. So are these standard interfaces i.e documented in RFCs / specifications?

    I’m trying to relate these with Gx / Gy interfaces in LTE world. Would it relate?

    1. Thanks Viswanath,

      Regarding your point. Unfortunately the reference points are standard but the low level details are not yet defined by ETSI. That is why we see that many vendors do it differently though using open APIs.

  15. Hi faisal,
    Very easy to understand.
    I am a newbie to this technology.
    Plz give me some link to understand it.
    This is something my company is deploying this days.
    Please refer some books or links to refer.

  16. Hi Faisal,

    Your articles and diagrams have been a Godsend in helping me ramp up my domain knowledge with NFV. Please keep up the great work!

    p.s. I did notice that one small correction is needed on the interface label between Orchestration and VNF Manager. Shouldn’t it be “Or-Vnfm” vs. “Or-Vi”?

  17. Great article, easy explained. Thanks.

    Could a SDN Controller also somehow integrated into a NFV Architecture and if yes where? For example a SDN-WAN solution with an implicit Controller and then to use the Service Chaining with VNFs only for Services (i.e. FW). Would this be possible or doesn’t it fit into the architecture?

    1. Hello Sim,

      Thanks for reaching out. SDN controller can definetly fit into an NFV architecture. If you looking closely to the architecture there is a virtualization layer and a virtual network above it. This virtual network is the one that can be SDN based. Lets take your example. You have different VNFs , for example a virtual router and Firewall. For the traffic to flow from on to another ( service chain), SDN controller can play a good role. This will bring a lot of flexibility as now VNFs can be located in cloud at different locations and then chained through virtual network layer.

      1. A good comparison of NFV MANO and SDN controller is found in Verizons’s SDN-NFV Reference Architecture v1.0 doc. It goes as , “NFV MANO knows whether a network function is virtualized without knowing what it does. WAN SDN Control knows what a network function does, without knowing whether it is virtualized”.

        Coming back to the question of integrating SDN Controller/s and NFV MANO, while the “orchestartor” in ETSI NFV MANO does the orchestration/coordination among different VNFs (and through a proper integration with respective EMSs, PNFs too) at function/service(e2e) level, the SDN controller does the traffic flow control/management in the data plane level (Virtual/physical) using, for example OF between the SDN controller and the data plane of the PNF/VNF.

  18. Pingback: A Beginner's Guide to Docker Container in NFV - Telecom Lighthouse

  19. Just came across this article. Going to follow this blog from now on..
    Thanks for your time Faisal. You made it very simple. Seen your replies in the board and excellent attitude. Looking to learn a lot from you.

  20. Nidhish ABRAHAM

    Finally ! I found someone who is able to explain complex things in a simple way so that everyone can understand. As someone mentioned you should go ahead with writing many good technical books !

    1. Thanks Ahmed, This is a topic in itself. May be we can make it a topic for blog post in future. Check out the relation between SDN and NFV in one of my blogs. And let me know if you need more info.

  21. Appreciate your lucid presentation of concepts! Keep up the good work.
    I have few queries and would request you to address them.
    1) You have said that EMS and VNF-manager are very similar, the only difference being VNF-manager operates through “open interfaces”. Would you further elaborate on this. You could also point me to some useful links that attempts to explain this.
    2) Secondly, What i am trying hard to understand is why do we have so many managers and orchestrators, when our only aim is to manage the VNF(like routers, firewalls etc.) How do you view this?
    I would try to give you an analogy.
    At our organisation, we use Redhat Cloudforms to manage Different cloud and infrastructure providers. Let us assume that we have Amazon Cloud(AWS), Openstack and a Vcenter environment to manage. We can easily do this using cloud forms. Now when we create Virtual machines on any of these providers and host our applications on it, Cloudforms itself can manage and generate statistics of the application metrics, plus the VM metrics(CPU, storage,memory etc.) and also the health of the underlying physical hosts on which the VMs are being hosted.
    Similarly, what prohibits using such a single umbrella solution like Cloudforms to be used that can manage the VNF elements, hosts on which these VNFs are being hosted and even different environments. Has it something to do with the ETSI reference? Are all these elements needed as separate entities? Can not they exist as a single solution.
    Looking forward to a reply from your side.

    1. Thanks Guarv!

      First point: EMS is normally used in telco operators today to manage physical infrastructure. In theory, this EMS can be modified to manage the VNFs also through proprietary interfaces. However if you want to manage through open interfaces, then you would need VNFM. That is the difference between the two.

      If I can summarize your second point, you want to say why there are so many managers in NFV. First I agree with you that one manager could do everything. But would we really want to have one manager that does everything ? This would retard the innovation. Think of it in a same way as OSI model. The benefits of the layers is that it enables the development of each layer separately. VNFM can manage VNF but not the the virtual infrastructure. This would enable small players that develop VNFs to not worry about the virtual infrastructure management. These VNF players can bring their own VNFM or a third party can manage if there are open interfaces available.

  22. Thanks Faisal for simplifying this material .
    I would like to understand what is the difference between EMS and VNFM?
    it seems like the same thing

    1. Dear Tomer S,

      EMS is not part of the NFV MANO. EMS is the existing management system which a customer may have. This would need to be integrated with the NFV management system ( VNFM is part of NFV MANO) as initially the MANO will not be able to provide all FCAPS functionality, that is MANO would like to get assistance of the EMS to provide some functionality that it cannot provide. Please do read my other blog ” Beginners guide to NFV Management and Orchestration” to understand more on the building blocks of NFV Management system.

  23. Excellent. It is easy to understand the concepts. Thank You. Great if you can provide an article with APIs used in interface/reference points .

    1. Hi Chandra,

      Unfortunately there are no reference APIs defined by ETSI at the moment. The only thing ETSI clarified is that it would be open and standard APIs. It has been left to standard bodies to defined the APIs. It is still a work in progress.

  24. Alexey Shalaginov

    Clear and comprehensive explanation.
    Didn’t quite understand, wnhat may be “from same or different vendors” – VNF, or physical base station or EPC, in an Example to 6. NFV Orchestrator.

    1. Thanks Alexey,

      Orchestrator can create an end to end service. This, end to end service may include components from different vendors ( or it can be one vendor), for example in mobile case, call is generated from base station/eNode B and terminated on EPC. Orchestrator would be responsible for creation of such an end to end service between base station and EPC.

  25. Excellent !!!! clear, concise, and as usual fantastic Explanation.

    Faisal, i have gone through few article you wrote and i liked all, the way you explain i really Appreciate.

    as my company(AT&T) is implementation SDN, i am finding your blogs very much helpful to Align myself with my future skill set.

    will be be happy to see some practical implementation, with example of small but end 2 end SDN in service provider.

    Once Again good Job !!!!

  26. Rajesh Bhosale

    Faisal…excellent knowledge sharing work on this new, complicated & evolutionary topic. Please keep it up…..highly appreciate for your efforts for simplifying such technologies.

  27. Excellent blog with clear and concise stuff excluding all the marketing junk :-), Can you give examples of VIM, as in my understanding , Openstack, CloudStack,Vmware’s vDirectors can be good candidates for VIM. Can you also shed some light on the differences between 1. Service Orchestration, 2. NFV Orchestration, 3. Cloud Orchestration 4. Network Orchestration with clear examples and analogies ? Thanks in advance.

    1. Thanks Shahzad. Yes Openstack, Cloudstack are cloud management platforms for IT application. However a better example would be to have a look at Opnfv.org that is carrier grade purpose built platform for NFV applications.The initial scope of OPNFV will be on building NFV Infrastructure (NFVI), Virtualized Infrastructure Management (VIM), and including application programmable interfaces (APIs) to other NFV elements.

      For the concepts of Orchestration and what is included, I invite you to have a look at my blog which clarifies the concept of Orchestration:

      http://telcocloudbridge.com/a-beginners-guide-to-nfv-management-orchestration-mano/

      We can then discuss it further if you need more clarification.

  28. sohail muhammad

    any one who want to start studying what actually is NFV this is the blog to start …. thanks for sharing interesting and useful information regarding NFV .

  29. Good work Faisal…It gives headstart right way who ever wants to start the NFV journey right away…. Keep the good work on!!!

  30. It’s always be a pleasure to enjoy your fruitful outcome. Thanks for bring us a shortcut straight to the point.

  31. Dear Mr.Faisal Khan,
    I am following your blog keenly. Very good stuff and explanations. Even most consultants won’t give this much info. Thanks for sharing. I am really enjoying reading your blog. My best wishes for your continued writing the nuances of Telecom technologies.

    With best regards,

    janakiraman

Leave a Comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.