virtual network functions (VNFs)

What are virtual network functions (VNFs)?

Virtual network functions (VNFs) are virtualized tasks formerly carried out by proprietary, dedicated hardware.

VNFs move individual network and network security functions out of dedicated hardware devices and into software that runs on commodity hardware. These tasks, used by both network service providers and enterprises, include routers, firewalls, domain name system (DNS), load balancing, caching and network address translation. VNFs run within virtual machines (VMs) or containers.

VNFs can be linked together like building blocks in a process known as service chaining. Although the concept is not new, service chaining -- and the service provisioning/deprovisioning processes -- are simplified and enable tremendous scalability using VNFs.

Benefits of VNFs

Traditionally, new services and network functions are installed on proprietary hardware and manually configured on a device-by-device basis. Network engineers enable and configure the required functions within dedicated appliances. With service chaining, for example, engineers would need to manually cable together each dedicated appliance to link certain functions so they perform a desired sequence.

VNFs virtualize those functions in software, so new functions can be deployed as VMs or containers more quickly and efficiently. This virtualization infrastructure eliminates the need for expensive purpose-built hardware.

VNFs can help increase network scalability and agility, while also enabling better use of network resources. Other VNF benefits include the following:

• an overall reduction in power consumption;
• a decrease in the amount of physical data center space required as VNFs replace physical hardware;
• lower power and cooling requirements; and
• a long-term reduction of both operating expenditures and capital expenditures.

Challenges of VNFs

As is the case with all technology, VNFs also have some challenges to overcome. One issue that has plagued network functions virtualization (NFV) and VNFs for years is a lack of standardization from major vendors in the industry.

Fortunately, the European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) for NFV has been working on fixing this problem by releasing various specifications and guidelines for vendors to use. If NFV/VNF vendors adhere to these standards moving forward, telecom service providers and enterprises will experience issues when implementing nonstandards-based NFV architectures and VNF deployment templates.

Looking beyond standardization concerns, other VNF challenges include the following:

• Network teams need to overcome a deployment and management learning curve when building and operating VNFs in virtualized hypervisor or container environments.
• Network teams could lose monitoring and management visibility when using traditional network monitoring tools.
• VNFs' layered software approach could blur security visibility and traceability, which might introduce new cybersecurity challenges.
• Lastly, VNFs require a significant upfront infrastructure investment to replace physical network functions (PNFs) with virtualized functions.

PNFs vs. VNFs

Service providers and enterprises have traditionally relied on purpose-built hardware and software as the foundation for their network infrastructure. Known as physical network functions, or PNFs, these components typically use proprietary appliance hardware with application-specific integrated circuits for optimal performance.

Examples of PNF appliances include routers, switches, firewalls, load balancers, and DNS and Dynamic Host Configuration Protocol servers.

VNFs enable these same networking services to operate -- but decouple them from proprietary hardware. Instead, the network functions are facilitated on commodity hardware using a software layer to mimic network-specific hardware processing.

In many cases, service providers, telecom operators and enterprises are starting to introduce the use of VNFs by replacing aging PNF hardware with virtualized alternatives.

VNFs, NFV and CNFs

Historically speaking, service providers were the first to see the potential for virtualized functions that could simplify provisioning and ease service customization for their customers. In 2012, a group of service providers -- AT&T, BT, Deutsche Telekom, Orange, Telecom Italia, Telefónica and Verizon -- presented the concept of NFV at the SDN and OpenFlow World Congress. ETSI took charge of NFV development and standardization, and in 2013, the organization created the ISG for NFV to maintain NFV guidelines and specifications.

Although the acronyms NFV and VNF are sometimes used interchangeably, the two terms mean different things. Individual VNFs are a primary component of an overall NFV architecture. NFV also includes NFV management and orchestration (MANO) and NFV infrastructure.

NFV MANO acts as the framework for managing and orchestrating VNFs. NFV infrastructure includes compute, storage and networking components -- both software and hardware. This infrastructure provides the foundation for virtualized functions. All these NFV elements must then communicate with existing operations and billing systems.

A more recent advancement within this technology genre is what's known as cloud-native network functions (CNFs). CNFs were developed to address the problem that VNFs have when delivering nimble and scalable network services in a distributed, multi-cloud or edge computing architecture.

Traditionally, VNFs have been deployed using VMs. While far more efficient than PNFs, VMs require a separate server operating system (OS) to run for each network function. This architecture tends to consume more central processing unit/memory resources than necessary, limiting a provider's or enterprise's ability to distribute services horizontally for improved performance purposes.

CNFs differ from VNFs because they were designed to operate within cloud or edge containers, as opposed to VMs. The key difference between VMs and containers is multiple network functions can operate independently in separate containers that are controlled and managed by a single server OS. Thus, CNFs require even fewer resources to operate, making it less expensive to place functions across multiple clouds and in edge compute environments.