Do you know the acronym MANO? It stands for Management And Orchestration. (Yes, the N in “and” also gets some spotlight, otherwise it would probably sound odd to the Chinese.)
The word comes from the Network Functions Virtualization (NFV) standards, written by ETSI (the European Telecommunications Standards Institute). Their picture of how the world, specifically the telco world, will one day be virtualized looks like this.
The lower-left box called NFVI, or NFV Infrastructure is in simple terms the physical stuff we run our telco functions on. Servers, hard drives, cables, routers and switches, for instance. The top-left box contains the VNFs or Virtualized Network Functions. This is where the actual software acting as telco “nodes” resides. If you’re into virtualization, a VNF comprises one or more virtual machines (VM), and it’s in these VMs the telco node software is running.
However, something, somewhere, needs to be in control of this. Which VMs are part of a certain VNF? How are they connected? Which VMs should run on which physical servers, using which physical storage and connect using which physical cables, switches and routers?
Well, that’s where MANO enters the stage. You can see it in the rightmost part of the architecture picture above. And it looks good, doesn’t it? A single brain over there on the right, that handles all the icky decisions. Probably configured to begin with by humans, but after that by and large spending a lot of its days working in the shadows, with automated functions, not bothering us more than necessary.
This is the point where I have to give you some bad news: it’s not that simple. The MANO is in fact split into three parts: the NFV Orchestrator (NFVO), VNF Manager (VNFM) and Virtualized Infrastructure Manager (VIM). You can see them in this, slightly more detailed version of the ETSI NFV architecture.
There are a few other additions in this picture as well, but let’s not focus on them now. I want to use these two architecture pictures unmodified, so that you can see ETSIs own image of this instead of a Powerpoint artist’s representation. So squint a little at the rest of the picture if you need to, and zoom in on the NFVO, VNFM and VIM for the rest of this article.
There is a good reason for the separation, if you were wondering. The VIM, at the bottom, is the one talking to the actual physical infrastructure, and although you can have several VIMs, distributed in a large network, you would logically only need one. The orchestrator, at the top, is also drawn as a single box, because you only want one top brain making all higher-layer decisions. (Imagine having two different brains controlling your body; life would be difficult.)
The one in the middle, the VNF Manager, however, is thought of to be delivered together with the VNF, and knows exactly what that specific VNF needs and how you would scale it in and out if you would need to. So you would perhaps buy a virtual PGW (this would be one VNF), and get the VNF Manager that goes together with it. And then you’d buy a virtual MME, and get another VNF Manager for this VNF.
It’s possible to create general VNF Managers also, which would be necessary if you bought a VNF that doesn’t come with a VNF Manager. Perhaps this sounds odd, but isn’t that unlikely, perhaps buying from smaller VNF providers or for VNFs of a more “IT world” nature that doesn’t need super special management.
So the VNF Managers can come from the VNF vendors. And the VIM can be a rather lower-layer, uninformed-of-higher-things, system. Normal Openstack would fit right into the VIM box, for instance.
But where does the VNFO come from? The orchestrator? It needs to be able to talk to and control both the VNF Managers and the VIM. And the VNFMs, we just realized, may come from a number of different providers. If I buy a VNF from vendor A and another VNF from vendor B, will an orchestrator from either of these vendors be able to talk to both VNFs? It should, right? Given strict and clear standards of these interfaces, and you can see them named in the ETSI architecture above, it shouldn’t be a problem.
So: are we there yet? Well, we’re getting close, at least. The standards are there as of this year, but here’s the thing: even though a standard is finished, ready, frozen, you may still be able to interpret it in different ways. And if you do, interoperability goes out the window. Standards need to… mature a bit, before they become a blueprint you can use to build something.
So what is happening in real life today? We ask our students this all the time, and get an abundance of answers. Some say “MANO doesn’t exist today”, while others say “We require our VNF Managers to be able to operate without an orchestrator” (leading to manual labor replacing the tasks an orchestrator would perform). So far, there is no clear picture emerging of how operators of the world solve the NFV Orchestrator conundrum. What we don’t want is solution silos, with multiple orchestrators for different parts of the network.
There are ways forward, though. There is no clear picture of the end result, but there is very clear work being done. VNF vendors do offer orchestrators, but I wouldn’t bet my savings on them being able to manage all other vendors’ VNFs, at least not yet. There are also open source orchestrators, and from our viewpoint this is the area of most interest for many of our customers.
Currently we see two main open source NFV Orchestrator contenders.
ONAP (Open Network Automation Platform), which stems from the Linux Foundation project OPEN-O (Open Orchestrator) joining forces with the AT&T platform ECOMP (Enhanced Control, Orchestration, Management and Policy). It’s currently on it’s third release of code (named Casablanca).
There is also OSM (Open Source MANO), hosted by ETSI themselves. OSM is on it’s fifth release, shockingly named “Release FIVE”.
Both ONAP and OSM follow the ETSI architecture closely, which is good. They are currently dividing the world slightly as the adoption of ONAP is greater in North America and Asia, while OSM is slightly ahead in Europe. Having said that, some vendors and operators are members of both projects, effectively trying to hedge their bets.
Perhaps these will both be viable MANO options, with good enough standards helping them be interoperable with each other? I think if you check back in a year, this topic will be much clearer, as things are moving forward quickly. At the very least, I’m sure there will be something interesting to say about the world of NFV MANO.
And by then maybe, just maybe, we won’t have to ask the question in the title, but actually be there.