The “Big O” in the NFVO... and the MANO

 Let us address some existential issues.

What is NFVO, or VNFO for that matter, after all? Is it the same as MANO?

In the strictest of senses, MANO has a different connotation – a more inclusive one. MANO in its purest sense combines the NFVO, the VNFM and the VIM. Thus, the NFVO orchestrates the VNFs, the VNFM manages the VNFs while the VIM interfaces with the NFVI.

Thus technically, NFVO is a subset of MANO. Agreed.

So which market is Insight Research covering? Is it NFVO, or is it the larger MANO? Well, it is the large (not larger) MANO.

Let me present an equation for you to paraphrase our inclusions:

NFVO (as quantified in our report) = MANO (As per ETSI) - VIM

Then why are we calling it NFVO, and why not MANO? The reasons are very simple – better recall and better sense.

Explaining better recall is easy. The term NFVO connects the orchestration of NFs in a way MANO never can. This is as clear as it gets.

But MANO is not orchestration alone. It includes ‘management’ as well. This management aspect brings to the fore, the role played NFVM and VIM.

Let’s deal with VNFM first. The entire rationale of the NFV movement is to orchestrate network functions. At the very basic level, only when the orchestration happens does the question of managing VNFs arises. Well, that’s too simplistic. Let’s go deeper. Really, what does ‘managing’ VNFs mean? Instantiation, termination, scaling, optimization – right? Can’t these be done by the orchestrator? They can and they are. There is also considerable ambiguity about whether the NFVM should be bundled with the VNF or present as a central entity – the S-VNFM and G-VNFM respectively. If they are bundled with the VNF, then why should they be considered a part of MANO? What makes the confusion more acute is that NFVMs in some cases are supposed to manage multiple VNFs. There is no such confusion about NFVO, which is a central entity tasked with orchestrating multiple VNFs. Coming back to the moot point, there is a considerable overlap between NFVM and NFVO functionality. There are numerous examples of NFVO and VNFM being subsumed. What should such subsumed entities be called – they are called NFVO MANO in some quarters. Too cumbersome I say. NFVO gets my vote as the identity for the entity. Gulp, VNFM!

Let’s look at VIM then.

I would argue that as far as distinctive identity goes, VIM is on a much sounder footing than VNFM. Herein lies the challenge. The market for VIM is dominated by OpenStack and VMware. The identity crisis for VIM arises from another quarter and that is from the NFVi itself. Here again, the major players include OpenStack and VMware. Why not? Ultimately, VIM (and NFVI) exists to provide the base for orchestration. To quote the words attributed to Lytton Strachey, professor at Oxford University while being egged to take up arms for his country, “I am the civilization you are fighting for.” Replace the professor with the NFVO and the students with VIM. Poor analogy, I agree. But I hope you get the point.

Let us keep VIM out of the way.

To conclude, we consider NFVO as quantified in the report to be a combination of the conventional NFVO and VNFM. At the same time, we have the data to slice the market by the “orchestration” and “management” functions at the centralized level, although it is not a part of the present report.

Why do we call this entity NFVO?

What is the single most defining function in the MANO? The big O, of course. What is it orchestrating, the VNF of course.

As my colleagues from marketing departments globally brag, “Business is nothing but marketing” – MANO is nothing but NFVO!

What do you think?