Top 5 Requirements for Large scale NFV Adoption in carrier networks

Introduction

Network Functions Virtualisation was initially standardised by ETSI, and has been around for quite a while.

However, large scale adoption of NFV has been a challenge so far – even as network equipment vendors keep up pace with the ever changing landscape of carrier requirements.

We have seen NFV deployments sporadically – but it still needs more work to become a de-facto truth of carrier deployments.

NFV should eventually become as ubiquitous in carrier networks like “salt in our food”.

In this article, we discuss the top 10 operational requirements from a carrier perspective – which would pave the way for large scale adoption of NFV.

1. Choice of the NFVI Layer

This is one of the longest debates that I have seen in carrier organisations. For Openstack based clouds, vendors offer their own packaged versions of Openstack promising cross vendor compatibility.

Advanced carriers decide to have a carrier controlled Openstack version – such as RDO, and all the vendor partners fall in line. This of course requires internal technical capabilities to support the openstack infrastructure.

Depending upon your internal capabilities, either close a contract with an Openstack provider and ensure that vendors fall in line, or adopt an open version such as RDO and use your internal capabilities to support it.

This debate should not be allowed to linger on for too long.

For container native use cases, the choice is pretty well standardised. The latest version of Docker can be used which is free from vendor control.

2. Orchestration and VNF Management

ETSI allows VNF lifecycle Management to be governed by the VNFM ( VNF Manager) or by the NFVO (NFV Orchestrator).

Most vendors provide VNF lifecycle Management APIs from their VNFMs – which is then integrated with the NFVO using the ETSI SOL interfaces.

Other vendors who do not have VNFM capability would depend on the NFVO for the entire lifecycle management orchestration.

Hence, a control sheet should be made and a final integration architecture frozen.

Some operators also opt for a generic VNFM, which abstracts away vendor VNFMs.

This choice would be ideal if the carrier owns the NFVO or the VNFMs do not fully support the ETSI SOL interfaces.

3. MANO Support for Multi-VIMs & C-VIMs

One of the most critical requirements is for the MANO (Management and Orchestration) stack to support multiple VIMs (logical cloud instances situated in one data centre or in multiple data centres).

Telecom network functions are spread across data centres with unique policies for geographic redundancy and disaster recovery.

Moreover, with the adoption of ETSI MEC (Multi Access Edge Computing), the telecom architecture has spread beyond traditional data centres to hundreds of edge sites.

In this backdrop, the MANO infrastructure should support VNF orchestration across sites, as well as support MEC.

For MEC use cases, container native deployments are popular. Hence, the same MANO infrastructure should support VNF and CNF orchestration.

Many operators opt for Kubernetes for CNFs and MANO for VNFs. This would not scale in the long run, and would lead to a hinderance during operational process integration.

4. VNF Version Control – Often neglected

During operations, it is often the case that a new VNF release is under trial on a small scale – while the older release is live at the rest of the sites.

Even though Openstack provides Image management and versioning through Glance, it is not enough.

As an extension to MANO, VNF and CNF version control should be built-in, so that for each VNF instance across VIMs – the operator has fine grained control over which releases are undergoing trial, and which releases are live.

This capability becomes critical as we diversify across hundreds of MEC sites.

Procedures for software upgrades, rollbacks etc are extensions to this capability. A lot of time in carrier networks is wasted due to manual upgrades to software packages.

Through VNF and CNF version management, this aspect also gets enabled.

5. VNF Packaging & Configurations

This is one aspect which helps in frictionless on-boarding and operations of VNFs.

For Virtual Environments, VNF providers should package CloudInit utility in their VMs.

This python utility helps in VM configurations, automation of operational tasks, secure access, networking as well as executing any vendor-specific scripts during lifecycle management of VM packages.

The other packaging requirements are pertaining to the formats of images – which should be standard Openstack qcow/qcow2 formats.

Packaging should be automated by using Jenkins jobs.

For containers, the dockerfile should be standardised for each CNF.

Summary

Even though there are many other aspects which contribute to the successful operationalisation of NFV, these five aspects are of paramount importance.

If you liked this article, feel free to connect on LinkedIn