Welcome back to Apis TechTips! A series of excerpts from real Apis Training courses packed with knowledge and insights.
This episode covers the most important concepts used in NFV and comes from the course NFV MANO in an Hour.
If you found this Apis TechTip interesting, you’ll want to check out our full course NFV MANO in an Hour. The course uses as a starting point the main ETSI NFV architecture with its building blocks, and then focuses its attention on the Management and Orchestration (or MANO) functions.
The course covers the following topics:
- ETSI NFV
- MANO Functions
- The NFV Network Service
- Network Service Instantiation
- On-Boarding
- Scaling
Read more about NFV MANO here: https://apistraining.com/portfolio/nfv-mano-in-an-hour/
This TechTip is also part of a whole eBook of tips, all focusing on Cloud technology. We call it an eBook+ since all chapters are both text and video. If you want to read the text, you can do that, and if you want to watch a teacher tell the story, you can choose that.
All the video chapters are excerpts taken directly from our recorded lessons, so if one of them piques your interest, you can easily go to the course and dive deeper into that particular subject.
This particular eBook+ is called “Cloud Chronicles: A Journey into a Virtualized and Software-Defined World“, and you only need to CLICK HERE to request it for immediate download.
Below you can find the transcribed text for this particular TechTip.
NFV in a Nutshell
The purpose of NFV is to be able to virtualize network functions that were previously not virtualized. To do this, we create VNFs, virtualized network functions. Previously we had NFs, network functions, which means physical things. You buy them, you unpack them from a box, you can drop them on your toes, and then you pick them up, and you put them in a rack somewhere in a data center, and you configure it and put cables in it and so on.
Virtualized network functions are based completely on standard virtualization. So a VNF is the virtual version of a previously non-virtualized network function. This all runs in the NFVI, NFV Infrastructure, because that’s where we have the real hardware resources. The real hardware resources come in this holy trinity of cloud computing resources, which is usually divided into compute, storage, and network.
And then we have the technology to virtualize these things. Sometimes you will see a big box that just says” virtualization” or” virtualization layer” or something like that. I think that’s a little bit fooling the audience because the technology to virtualize a server is very different from the technology used to virtualize a hard drive or a switch or a router, or a cable. That’s why we like to separate these three kinds of resources and their virtualization methods.
We then want to manage these things from somewhere so we have the good old OSS/BSS. That’s the operations and business support systems.
From here, we will want to be able to create VNFs running as virtual machines or containers in the NFVI. But how do we do this?
Well, we can manage them with normal OSS/BSS surveillance and maintenance. If you can’t do that directly to the VNF, there’s something called an Element Manager or EM that can sit as a sort of translation function. But note here that the EM, the element manager, is not a mandatory function to have. You can live without any EMs at all.
What you can’t live without is the MANO on the right side of the picture. That’s the Management and Orchestration of the NFV architecture. MANO has become a word, so you pretty much never say “Let’s look into the management and orchestration.” Instead, you say “Look in the MANO.” Or you can say “We’re going to have a MANO meeting this afternoon to discuss what MANO software we’re going to use. There are some MANO providers here to sell their stuff to us, and we’ll have a little MANO chat after that to discuss which MANO to choose.” So MANO really has become a word unto its own.
Inside MANO, there are no fewer than three different functions. Starting from the bottom. We have the VIM, which is the Virtual Infrastructure Manager, which is the only one that talks to the NFVI. So it’s the one that actually sends commands to start and stop virtual machines, to mount storage to those virtual machines, and to create virtual networks with virtual switches and things like that. That’s the VIM, the lowermost part of the MANO.
If we take one step up, we come to the VNF Manager, which is a pretty good name, actually. It does what it says on the tin. It manages VNFs. What does buying a VNF mean? Previously, when you bought a network function, you bought something physical. You put it in the back of your car, and you rode it over to the data center and installed it. Now, with VNFs, you essentially buy software. You can download the software or buy a disk with that software.
That’s what the VNF actually consists of. But the idea is that you also get a VNF manager with that VNF because a VNF manager knows its VNF very well. It knows how to handle it, how to start it, how to stop it, how to scale it to make it bigger or smaller, and how to repair it if it starts acting up.
You can have a generic VNF manager that can send basic commands like start and stop. But if you want to have more specific handling of your VNF, that may require more specific knowledge. If you’re going to make it bigger, perhaps you need to start increasing this particular little function up in one corner before you then increase this little function down there in that other corner.
These are things that wouldn’t be known by a generic VNF manager, but they could be known by a specific VNF manager. And we can have several VNF managers, as it says in the image, to cover our different VNFs.
And finally, on top, sits the boss, the NFVO or NFV orchestrator. The NFV orchestrator is the only one that talks to the OSS/BSS, and it does orchestration, which is a word that means higher level management, with largely automatic management.
It handles large complex systems and not so much the details in those systems. So whereas the VIM at the bottom knows about virtual machines and containers, it does not know how they form VNFs. The VNF manager knows which virtual machines and containers comprise a particular VNF, but it does not know how those VNFs come together to build a larger network service.
The orchestrator knows about network services; it knows how VNFs can be connected together. So we have mentioned a few terms and objects that we can play around with, VNFs and Network Services. Those terms are very important. Before we move on to talk about which other objects we can play around with in the NFV playground, let’s just note here that the lines between the boxes have names, and those can be useful if you want to find out from a standard what goes on between two different functions in the NFV architecture.
I’ve been in the telecommunication training business for two decades now, and it has always been a little bit vague and mysterious how to tell interfaces from reference points. To me, those two things have always been fairly similar and largely interchangeable, sometimes almost completely synonymous. And the standards that I have read have really not made a great distinction between the two. ETSI, who created NFV, really do distinguish between them in the NFV papers.
The lines in the image are reference points. The names that are on these lines are names of reference points. And those reference points can then offer a number of interfaces. And just to give you an idea, all these reference points offer somewhere between five and fifteen interfaces. None of them have just one, and none of them have a thousand.
Those interfaces are essentially just groups of commands that fit together. Maybe up by the OSS/BSS, there is the group of commands that onboard things. Maybe then there’s another group of commands that manages those onboarded things. Those would be two different interfaces. So these reference points host one or more interfaces with which we can play around with NFV things in the wavy NFV playground box in the middle of the picture.
We have things like PNFs or physical network functions. We will always need that for legacy reasons. PNFs are just the good old network functions, the ones that you unpack from a cardboard box and can then drop on your toe, but they won’t go away. So we still need to keep them in our infrastructure.
VNF is the new virtual version of a PNF, so that’s a virtualized network function. And then, we have network services which combine PNFs and VNFs. In order to have those connections, physical network functions have Connection Points (CP), VNFs have connection points and network services have connection points, although they’re not called connection points – they’re called Service Access Points (SAP). But SAPs are, for all intents and purposes, exactly the same as connection points. When it comes to their data models, they are pretty much identical.
And finally, we can connect these connection points with Virtual Links (VL) inside VNFs and virtual links inside network services.
