The Shifting Sands of the Network Function Orchestrator Landscape

Fun facts

Here are some fun facts.

Archimedes is known to have said, “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world. ” This statement, while technically sound, is known to shock most people when they hear it for the first time.

Ants are known to carry up to twenty times their own body weight. Again, a perfectly valid statement with a thoroughly rational explanation, yet known for its shock value.

Wait a minute, aren’t we talking about network function orchestrators? Why then am I unleashing shock-n-awe on you? 

There is a reason – the monumental transformation afoot in the network function orchestrator space has ample parallels with the abovementioned statements. 

Drawing the parallels

To draw those parallels out, let us quickly identify the shock value proposition of these statements. It is very simple – a seemingly modest or underwhelming entity punching way above its weight to deliver unreal results. The entities are the lever and the ant, respectively in the first and second facts. In the case of network function orchestrators, that entity is the container technology.

So what are the containers doing to network function orchestrators?

The answer is very simple – containers are running away with the orchestrator market. They are the undisputed winners in the race with VMs, and it is a matter of time before this victory is certified by the seal of greater market share.

And the undisputed architect of this victory is the orchestrator driving the containers – Kubernetes (k8s).

Their victory, though impressive, is not the only reason for the drama surrounding the container technology. Nor is the relative novelty of the container technology when compared with the far older and mature VM technology. After all, newer entrants are known to displace the established players till these entrants become the establishment themselves. In any case, in a battle of competing technologies, someone has to win. 

So why am I invoking Archimedes and the ants with their respective stupendous hypotheses and facts? 

Is the container the classical underdog – in size (literally) due to the low footprint? But compactness is a virtue in virtualization, not a sin.

 Is it an underdog in security matters? Well, the jury is out on that count. 

So no, containers technology is not an underdog in any sense. By all accounts, it is a more sorted method of virtualizing network functions as it facilitates service-based architecture (SBA) featuring a tapestry of microservices.

We are still searching for the parallel, aren’t we?

Well, the implications of deploying the k8s orchestrator go well beyond the orchestration layer – no, not just upwards in the application domain (which we all know and take for granted); but also downwards in the infrastructure domain. Now that is a twist, isn’t it? Typically, the orchestrator draws from the infrastructure. How do you make an orchestrator manage the infrastructure? The infrastructure in a sense, is the father; and the orchestrator is the child. Are we now taking – “the child is the father of the man” very literally?

Enter Project Nephio.

The child-father interplay

It is easy to brand Nephio as yet another open-source project from the never-ending stream of offerings traceable to the Linux Foundation. It is also convenient to categorize it as the Linux Foundation’s shot at redemption given the enormous controversy surrounding the effectiveness of its flagship ONAP initiative. We will save these discussions for later. Let us now focus on the sheer audacity of what Nephio is trying to convey. The Nephio mission states, “Nephio enables faster onboarding of network functions to production including provisioning of underlying cloud infrastructure with a true cloud native approach and reduces costs of adoption of cloud and network infrastructure.”

So far we were thinking that it is the underlying cloud infrastructure that sets the operational limits for the orchestrator and the network function logic. Nephio is trying to do something else. More light on its approach can be thus gauged by the following statement, “ provide Kubernetes-enabled reconciliation to ensure the network stays up through failures, scaling events, and changes to the distributed cloud.”.

I will not get into the specifics of how Nephio aims at achieving its objective. Its methodology is clearly spelt on its resource pages.

What is clear is that Nephio has catapulted k8s to the infrastructural fulcrum of the network function, with a far wider mandate than its original role envisaged as the leading orchestrator for CNFs. 

The lightweight K8s now balances the entire framework of the virtualized network function – from the infrastructure to the application layers. This is not too different from the Ant balancing loading weighing twenty times itself, or the audacious hypothesis of Archimedes.

Dispassionate analysis

Am I getting too starry eyed about Nephio? Let us now look at Nephio more dispassionately.

K8s, when released to the world by Google, was looked upon as a tool that pooled computing power from several machines into a large computer. It always had an existence beyond its now predominant identity as the orchestrator of container applications. Nephio seems to have tapped into the original identity of k8s to orchestrate underlying infrastructure.

By emphasizing on the infrastructure orchestrating ability of k8s, the Linux Foundation has also tried to provide elegant application orchestration opportunities for ONAP. More about ONAP later.

What next for the ‘conventional’ MANOs?

One thing is clear, all conventional MANOs – open-source or proprietary, have taken the pains to accommodate containers and cloud-native network functions into their fold. 

So is it game over for VMs and its myriad of orchestrators?

The answer is complicated. You see, these orchestrators are not static entities; their architectures are fluid and the entity organizations driving these orchestrators are remarkably agile.

What is ONAP doing?

By and large, the telco trend has to select specific modules of ONAP and include them in their network function orchestration. Now, this may not be necessarily a bad thing, as module-wise implementation was one of the many ideas that drove the ONAP initiative. ONAP backers stress that ONAP is not merely an orchestrator in the strictest sense. ONAP is also making its mark in other domains – network slicing in Kamara, ORAN SMO  and its numerous partial incarnations in telcos around the world.

And OSM?

OSM considers interconnectivity and interoperability as its calling card. OSM works at a higher abstraction layer and does the job of translating interoperability instructions into the lower layer by itself. OSM information model is public knowledge. All OSM distributions are compatible with OSM information model. And the value proposition of OSM as a more focused orchestrator remains undiminished.

Both OSM and ONAP support CNFs. The same is true for most proprietary MANOs.

Inferences

All MANOs will include network service orchestration in their ambit.

VM-based VNFs will continue to find acceptability on account of strong legacy among telcos and enterprises alike.

And K8s is here to stay. Notwithstanding the apprehension in some quarters about its ability to manage networking and storage resources efficiently; K8s scores on account of its sheer flexibility and most importantly – acceptability. It will rewrite the rules of the game by managing the orchestrating the cloud infrastructure – validating Archimedes and the humble ant.