The Four Stages of NFV – Virtualization to Cloud

AvidThink has closely tracked the NFV movement from its inception to the present day. We've seen successes and pitfalls as CSPs worldwide ride this bandwagon. At its core, the NFV mandate involves liberating network functions from proprietary physical hardware, and first virtualizing, then rearchitecting and finally distributing and scaling these NFs across the different infrastructure. Concurrent with these efforts, CSPs need to revamp the supporting infrastructure, whether it be operations support systems (OSS) to continue to effectively provision, manage and monitor or business support system (BSS) to monetize these services.

Stage One — Virtualization: PNF to VNF

The early years of NFV saw the migration of physical network functions (PNFs), usually in proprietary appliance forms, to virtualized software instances. Vendors provided ports of their physical appliances into virtual network functions (VNFs) virtual machine (VM) packages. VNF managers (VNFMs) were closely tied to a vendor's specific VNF, and CSPs and vendors alike worked hard on NFV orchestration (NFV-O) systems and how they would tie into CSP OSS. At this stage, the challenges involved figuring out how to virtualize and package software that had previously run on proprietary hardware.

CSPs realized that telco workloads were more I/O-intensive than general enterprise applications. CSPs and equipment vendors started developing both software (DPDK and VPP) and hardware techniques (SR-IOV), as well as best practices (NUMA alignment, CPU pinning) to allow virtualized software instances to match PNF performance.

During this virtualization phase, NF placement involved matching available and suitable NFVI to the needs of the VNFs. This placement capability was enabled through a combination of improved orchestration with updated inventory systems.

Stage Two — Cloudification and Containerization: Architectural Accommodation for CNFs

Before CSPs had completely figured out NFV, along came Linux containers. With it, CSPs were introduced to cloud-native network functions (CNFs), often built using born-in-the-cloud technologies and leveraging microservice architectures. Cloud-native architectures bring significant benefits to cloud-based applications in terms of scale, portability and robustness — attributes that CSPs seek today. CNFs and microservice architectures are of particular importance because 3GPP's 5G core (5GC) service-based architecture (SBA) is built on these cloud-native frameworks, and today's implementations for 5G core stacks from leading vendors are CNF-based.

Now CSPs have to devise a multi-pronged approach to manage PNFs (which continue to exist in carrier networks), VM-based VNFs, and a container-based strategy for CNFs. At this stage, which is where most CSPs are at in 2020, NF placement involves more than merely matching VNFs with NFVI. NF placement systems also need to understand where container orchestration systems have placed relevant NFs, so these NFs can be chained together to form a network service.