However, we have made observations. You might call them birds-eye-perspective observations, meta observations or just plain that-was-kinda-interesting observations.
Before we start: it’s difficult reading the ETSI specifications that define NFV. I mean, it’s generally not super-fun to read any technical specifications, be it 3GPP, IETF, ETSI or any other. To be fair, the NFV specifications don’t claim to be 100{ab0bbb36d35f56bd2c9e68629e6e8f1a44a0c9776dc977281f4aeafa2fb487ad} complete. Still, the level of incompleteness is often difficult to grasp and not finding a particular piece of information can mean both that it doesn’t exist and that I’m not good at finding stuff.
Interfaces and Reference Points
Let’s start on a positive note. I’ve been doing technical training within telecommunications for 20 years now, and the distinction between interfaces and reference points has always been a bit nebulous and vague. I feel they have often been used interchangeably, and sometimes when I’ve read one document using one term, and then matching that with another using the other term, I’ve been left wondering if they mean the same thing. They both seem to have meant “a line between two boxes with acronyms in”.
Enter: ETSI! The lines-between-boxes are there, and well defined as reference points. These reference points can then be used for a number of interfaces, which boils down to a group of HTTP commands that together build a logical family. The reference points in NFV MANO hold between 5 and 10 interfaces each. So, finally I know which words to use, even though sometimes muscle memory makes me incorrectly call the lines themselves interfaces. Good, ETSI!
Old Standards Still Live
The papers defining ETSI, just like other standards, come in different versions. Versions can be called “releases”, “stages” or just plain “versions”. ETSI papers use all of them, albeit not in a consistent manner such that all documents have all descriptors. Some have stages, most don’t. Most have releases, some don’t (and almost no documents exist in several releases). All of them have versions, so that’s good.
Here’s the rub. Some families of standards in NFV are just discontinued, while new paper production ensue in other families. Typically, the discontinued families contain older releases, and new production is done in new releases. But since the new documents are in completely new families, they are not new versions of already existing, older documents. Essentially, old documents aren’t formally retired, but instead just lie around, still officially “active”, while new documents are being created. Those new documents may not conform totally with the old ones, and in worst case even contradict them.
This is the case with MANO. The last version of the original MANO specification “MAN-001” is in release 1 and was published December 2014. That’s a long time ago, but it’s still not officially taken off the playing field. It contains a lot of good high-level discussion on the purpose of MANO, the three main components therein, and instructive pictures. Those are all good things. Unfortunately it also contains more hard core technical stuff, like data models and exact names of data elements. Those are just not correct anymore. In some cases, you can find later standards explicitly saying how a concept of MAN-001 has been deprecated, but in most cases, you’re just left wondering how the standards are supposed to fit together.
I think the pragmatic view is to consider later information to be more reliable than older, and that is how we have constructed our MANO course. But I find it quite often difficult to discern whether there are inconsistencies, or if it’s just me having an off day and being a bit stupid.
What Is a Catalog – Really?
In the first architecture drawings of NFV there was an external reference point from MANO to a place where “Service, VNF and Infrastructure Descriptions” could be stored. It looked like this:
This function was then moved into MANO itself, and the reference point has never been heard from since then…
Nowadays the infrastructure is often drawn like this:
The single box has been broken up into a number of something-elses. (It’s not super well-defined what that shape means, but an informed guess is some form of data base.) So it looks more standardized now. But note that those lines don’t have names on them; they are not well-known NFV reference points. Going into the development work on MANO training I still thought these things were at least described in some way, maybe even described as just… things that exist. But it turns out they’re not.
Even though they appear in text and in a number of (informative) flow charts, these storage places for onboarded and instantiated NFV elements are just not defined in the NFV papers. More surprising, the mechanisms (reference points/interfaces) with which to reach them, aren’t either.
As with quite a few other mysterious cliffhangers in the NFV papers, it’s difficult to establish whether the information doesn’t exist, or if I just can’t find it. But in the case of the catalogs there exists text that explicitly says things like “the repository may be maintained by the NFVO or another external entity” (this was for the VNF catalog, specifically). So right now, these repositories seem to need to be implementation-specific.
“NFV Compliant” Open Source MANO
There are quite a few actual pieces of software we can put in the MANO box. Some are paid-for (notably VMware), and others are open source. In fact, there is a thriving flora (or is it fauna?) of open source MANO products on the market, these days. Many of them sport banners on their web pages boasting of “NFV compliance” and “Aligned with ETSI NFV”.
Being vendor-independent, at Apis we support all forms of standardization. It makes it easier for the consumers of these services not to put all eggs in one basket and, let’s face it, it’s what we make our living from: enabling you to not have to read those boring and difficult standards.
However, “compliance” and “alignment” can mean a lot of different things, it turns out. What if part of your product is super-compliant, but others aren’t at all? What if you align perfectly with an NFV standard, but that standard happens to be MAN-001, published last in 2014, and other standards have since made it mostly irrelevant?
Our studies have found that currently, no open source MANO products are conforming with standards to such a degree that we can easily take half of it and plug in another half from another MANO product. Most actual standards-compliance today is in the pre-onboarding phase. You could say it’s the design phase, rather than runtime phase. This means the actual files and documents provisioned to the MANO so that it can do its job. In NFV MANO terms, this means VNF descriptors and packages, Network Service descriptors, TOSCA structures with YAML and YANG files, zipped into CSAR archives.
But after these standardized things have gone into the MANO, it becomes sort of a black box and does its job (often quite well, I’m sure) but without caring so much about what ETSI happens to have written in a paper called NFV.
To Be or Not to Be an NFV Instance?
Instantiating things in NFV sounds easy. It comes down to starting virtual machines, containers or virtual networks, and then perhaps connecting them together, which is then the same thing as instantiating a network service. This is all part of what’s called LCM, or LifeCycle Management. It begins with onboarding, which is essentially loading files into MANO for later use, and the next step is instantiation. Instantiated objects are typically created from a descriptor and the runtime information of the instance that was created is called an “info” object. So a VNF descriptor can be instantiated into a number of “VNF Info” objects.
I was confused for a long time by the fact that a “VNF Info” object has a flag to signal whether it is instantiated or not. This is like saying “We have now created an instance, and part of the information in it states whether we have created an instance or not”. Can a VNF be both instantiated and not instantiated at the same time?
In a way, the answer I have found is: yes. It can. It’s a bit technical and comes down to how instantiation is done, by first creating an empty “space” to fill with the instance, and then filling it. So after that space has been created, but before it has been filled, you can argue for the VNF both existing and not existing. It’s all very metaphysical.
Can You Separate Mothers from Children? Should You?
NFV MANO offers a very complex data model, with the top object being the Network Service. It contains other elements, that in turn contain other elements, and so on. But if that was a strict model, nothing could exist without its mother element, and since they all lead back to the network service, nothing could exist without that.
For some elements, it does indeed make sense that they have to exist in the context of a network service, such as Network Service Connection Points (also called Service Access Points). But other things really seem like they should be allowed a life outside the constraints of its demanding parent. VNFs, for instance. Why can’t you have just a separate VNF?
As it turns out, you can. But for other elements it’s quite tricky to find out if they can exist “on their own” or need to be included in a larger family of things. There’s something called “Profiles” used for some instantiation scenarios including network services and something called VNF Forwarding Graphs. But can profiles exist without them? Even if the standards don’t suggest a use for it, is it “legal”?
And a Couple of Questions to the Universe
Or maybe to ETSI. Questions keep popping up when reading standards, and sometimes it feels like they’re popping up quicker than you can push them down with answers. We feel we have managed to answer most of our questions, but a few remain mysterious. Here are two of them.
Why Are Some Flavours Difficult to Change?
There’s something called “Deployment Flavours”. In simple terms, it’s different ways to build a thing, but still using the same blueprint. Perhaps you’re building a car, but you can build it with or without flashy hub caps, with or without SatNav and with or without an extra cup holder under the steering wheel. Once you’ve chosen a deployment flavor, you can choose an “Instantiation Level”. This is scaling the things already in the construction up or down. So perhaps for a car that would be deciding engine power, paint thickness or the size of the wheels.
VNFs have both deployment flavours and instantiation levels, and so do Network Services. It’s possible to change the deployment flavour of a VNF in runtime, which is cool, but doing the same for a Network Service is not allowed. Why? A Network Service is essentially a number of VNFs strung together, so why can’t you do that?
Why do VNFFGs not have Deployment Flavours and Instantiation Levels?
VNFFGs are VNF Forwarding Graphs, ways to force traffic a certain way through a network, and basically override normal IP routing.
VNFFGs are also an integral (albeit optional) part of a Network Service. So what happens if you scale that Network Service to include more VNFs? Will they be included in the VNFFG? As the VNFFG itself remains static, it remains a mystery to us how the VNFFG will behave in a Network Service scaling scenario.
If you have the answer to these questions, get in touch with us. We may just give you a discount on training as a finder’s fee!
Summary
NFV MANO is interesting. It’s complex. It’s also not really finished.
It’s absolutely finished enough to allow us starting to learn how it works. The foundation is not expected to change. But it’s also unfinished enough to keep some of its secrets hidden from view for yet some time. And perhaps those final wrinkles won’t be straightened out by ETSI but by you, working in the Telco community, creating de facto ways of solving the remaining puzzles.
One thing is certain: we live in interesting times.
Learn more!
If you want to learn more about NFV MANO, go check out our Cloud, SDN, NFV training catalogue. Here you will find multiple courses focused on NFV MANO: NFV MANO in an hour, NFV MANO in half a day, NFV MANO in-depth.
