Previous blogs have provided insights into use cases that will be covered by 5G in the longer term. In particular we covered the very diverse requirements associated with enhanced mobile broadband (eMBB), ultra‐reliable low‐latency communications (URLLC) and massive machine‐type communications (mMTC) use cases. This blog discusses why legacy VNFs (Virtual Network Functions) will need to either move over to being purely container-based (CNFs) or to run alongside CNFs using approaches like Kubevirt or Kata containers.
Virtual Network Functions (VNFs)
Typically running on top of COTS hardware (that provides the compute infrastructure), VNFs are software implementations of network function equipment bundled into virtual machines. VNFs are the foundation of NFV. VNFs replace specialized hardware devices with software that runs on inexpensive hardware to replace particular network and network security functions. Routers, firewalls, the domain name system (DNS), load balancing, caching, and network address translation are some of the tools used for these activities by businesses and network service providers. VNFs operate in containers or virtual machines (VMs).
NFV (Network Functions Virtualization) virtualizes network services and software to lower costs, obtain complete control over network operations, and benefit from increased agility and flexibility. Both NFV and CNF virtualize network functions in order to provide a flexible compute architecture. To easily grow and adapt whenever and wherever the user needs to deploy network capabilities, both make use of an underpinning physical server. The primary distinction is in how those network operations are decoupled from the physical server infrastructure that underlies them:
- Network Function Virtualization (NFV) makes use of a hypervisor to provide a single layer of abstraction that allows networking and network security functions to run as specialized appliances (such as routers, firewalls, etc.) in the form of virtual machines that can be quickly deployed on standard hardware.
- Each distinct network and network security function is condensed by CNF into a microservice, packaged in its own container, and delivered on a cloud platform’s standardized hardware resources. CNF capabilities utilize open-source orchestration technologies, such as Kubernetes, across numerous microservices, containers, and clouds, similar to how apps run as cloud services.
VNFs and NFVs are also differentiated by the fact that VNFs are provided by external vendors or open-source communities to service providers who are transitioning their infrastructure to NFVs. There may be several VNFs that combine to form a single service for NFV.1 This adds complexity to the overall NFV purpose of agility where VNFs from different vendors need to deploy in NFV infrastructure having a different operational model. VNFs developed by different vendors have different methodologies for complete deployment in existing NFV environments. Onboarding VNFs remains a challenge due to the lack of standard processes for complete management from development to deployment and monitoring.
Traditional VNFs have fundamental constraints, such as the need for a significant amount of hardware to provide high availability.
- VNFs are created, tested, and configured to work with a certain NFV hardware infrastructure.
- To enable automated scaling and setup to meet the unexpected rise in demand for usage, manual installation, configuration, and deployment on NFVi API are required.
- not allowing for multiple tenancies. VNFs are difficult to repurpose through infrastructure sharing.
The Role of Open Source
Vendors could solve this problem by creating cloud-native VNFs, and this represents a breakthrough in software development by giving VNFs all the cloud-native properties. Containerized functions, microservices-based, dynamically managed, and specifically created for orchestration are features we may anticipate from cloud-native VNFs. Self-management capabilities and scalability may be the main factors that set cloud-native VNFs apart from conventional VNFs.
- Cloud-native VNFs have APIs which enable
- Automated installation and configuration
- automated scaling when dynamic requirements from network
- self-healing or fault-tolerant
- automated monitoring and analysis of VNFs for errors, capacity management and performance
- automated upgrading and updating VNFs for applying new releases and patches
- Standard and simplified management which enables less power consumption. Reduction of un-necessary allocated resources.
- Reusability and sharing of processes within VNFs can be achieved
The Final Word
While NFV is critical in the development of 5G networks, numerous problems including automated deployment and VNF onboarding—are being addressed by NFV solution vendors in siloed. Although creating VNFs and deploying them into an NFV infrastructure may seem simple – scaling, configuring, or updating VNFs poses a number of issues. The need for manual intervention in any VNF-related action increases the amount of time required for service providers to deploy or update new services. Excellent automation at every stage of NFV development is required to deliver on the agility promise made by NFV in 5G. Although it is still extremely early, creating cloud-native VNFs has to be the solution.