VNF and CNF, what’s the difference?

Virtual network functions (VNFs) are software applications that deliver network functions such as directory services, routers, firewalls, load balancers, and more.  They are deployed as virtual machines (VMs) and have often been the next step for telecommunications providers in their digital transformation from the physical network functions (PNFs) of legacy network appliances on proprietary hardware. 

As key components in network functions virtualization (NFV) architecture, VNFs are built on top of NFV infrastructure (NFVI), including a virtual infrastructure manager (VIM) like Red Hat® OpenStack® to allocate resources like compute, storage, and networking efficiently among the VNFs. The framework for managing NFVI and provisioning new VNFs occurs in the management, automation, and network orchestration (MANO) elements defined by NFV. 

Digital service providers that adopt a cloud-native approach—using both centralized and distributed locations for applications—can benefit from increased flexibility, scalability, reliability, and portability. Moving beyond virtualization to a fully cloud-native design helps push to a new level the efficiency and agility needed to rapidly deploy innovative, differentiated offers that markets and customers demand.

An important distinguishing feature of the cloud-native approach is that it uses containers rather than VMs. Containers allow users to package software (applications, functions, or microservices, for example) with all of the files necessary to run it—while sharing access to the operating system and other server resources. This approach makes it easy to move the contained component among environments (development, test, production, etc.)—and even among clouds—while retaining full functionality.

As an evolution from VNFs, cloud-native network functions (CNFs) are designed and implemented to run inside containers. This containerization of network architecture components makes it possible to run a variety of services on the same cluster and more easily on-board already decomposed applications, while dynamically directing network traffic to the correct pods.

This figure shows the evolution of network functions from the traditional vertically integrated approach, to VNFs managed by a common VM orchestration platform, to CNFs managed by a common container orchestration platform.

The adoption of CNFs can resolve some of the fundamental limitations of VNFs, by moving many of these functions into containers. Containerization of network components makes it possible to manage how and where the functions run across clusters in the environment. 

However, CNFs are more than just the containerization of network functions. To get the full benefit of cloud-native principles beyond container packaging requires further rearchitecting of network function software, like decomposing it into microservices, allowing multiple versions during updates, and using available platform services like generic load-balancers or datastores. 

Additionally, as adoption of cloud-native environments increases, CNFs must co-exist with legacy VNFs during the transition. Digital service providers must fully automate the development, deployment, maintenance, and operation of the network to effectively handle escalating demand, accelerate deployments, and reduce complexity. Standardized methodologies for configuration and deployment, tools matured in open source communities, and rigorous testing and certification are critical for providers now more than ever.

An open, consistent foundation gives telecommunications providers confidence that the services they deliver will run reliably, regardless of location or footprint. Building that foundation on NFV (with VNFs) and especially cloud-native architectures (with CNFs) results in improved flexibility and agility. Automation plays a critical role in keeping the ecosystem operating efficiently and more easily at scale and allows digital service providers to more rapidly change and add services and features to better respond to customer needs and demands.