Telcos (Telecommunication companies) deploy networks that have high availability, are scalable, and resilient covering entire countries. Components like routers, firewalls, and DHCP servers (called Network Functions) are the building blocks of such large network deployments.
Traditionally, network functions were deployed on proprietary hardware with application-specific integrated circuits and installed on the telco’s premise (baremetal deployment). Such network functions are called Platform Network Functions (PNFs).
PNF deployments present the following challenges:
- Hardware for network functions could not be moved easily and redeployed.
- The deployment of PNFs required knowledge of proprietary hardware.
- Services deployed on top of PNFs are tightly coupled with the hardware. Customization, scaling, and configuration of services could require change/upgrade of hardware components.
- Access to PNFs is limited to the private cloud setup by the telco.
Virtualized Network Functions (VNFs)
The concept of Network Function Virtualization (NFV) was introduced in 2012 by a group of leading telcos. It proposed the transition of network functions from proprietary hardware to virtual machines. Individual network functions could be provisioned as a Virtual Machine on top of a hypervisor (Virtualized Deployment), such network functions are called Virtualized Network Functions (VNF).
Benefits of VNFs over PNFs
- VNFs could be deployed on any generic hardware as long as they are supported by the hypervisor. This eliminates the need for proprietary hardware for deployment.
- VNFs could be provisioned and moved easily.
- The scalability of the network is improved.
- Overall reduction in power and cooling requirements.
Other than VNFs the NFV architecture comprises MANO (Management, Automation, and Network Orchestration) and NFVi (Network Function Virtualization infrastructure).
MANO is a framework for the management and orchestration of all the resources and their lifecycle in NFV architecture. This includes the compute, storage, and network resources. NFVi refers to the infrastructure that provides the resources to VNFs an example could be OpenStack.
Software Defined Network (SDN) could be created on top of VNFs to further ease the management and configurability of the network.
Example of a VNF: Infoblox
Infoblox provides cloud networking solutions through products that provide a unified network view, global load balancing, reporting, analytics, etc.
The NFV provided by Infoblox has the following features:
- DNS, DHCP, and IP Address Management (IPAM) services.
- DNS Cache Acceleration Services (vDCA) improves the performance of DNS resolution across the network.
- Advanced DNS Protection (vADP) for networks deployed on OpenStack.
- Integration with other Infoblox products like Infoblox IPAM and Infoblox vDiscovery.
Cloud-Native Network Functions (CNFs)
Now, network functions are transitioning from virtual machines to containers (Containerized Deployment). This will provide further benefits over PNFs like
- Improved scalability and efficient usage of resources.
- Ability to use a mix of private, public, and hybrid cloud as containers could be deployed and migrated easily on any cloud environment.
- Edge devices could also be included in the network to improve its reach and latency to the end users.
Although CNIs could be used to create and configure network interfaces between containers, for telco’s use case a network function container could require network interfaces that could interact with the specialized hardware directly. In such cases, an operator could be defined with custom resources that could procure the hardware directly to the workloads (containers) as a network interface. CNFs themselves could also be packaged as Kubernetes operators.
Example of a CNF: Nokia Cloud Mobility Manager
Nokia’s Cloud Mobility Manager is a control plane network function for packet networks following the 3GPP (3rd Generation Partnership Project) standard.
It is designed to be deployed in a cloud-native environment as VNF (in OpenStack KVM or VMware vCloud environments) or as CNF (in OpenShift). It provides the following benefits
- Performance and scalability depending on the workloads
- Reliability and resiliency with fault monitoring, recovery, and overload control protection
- Multi-generation access (2G/3G/4G/5G)
Transition from VNFs to CNFs
The journey from VNFs to CNFs for telcos is not easy due to the following challenges:
- Virtualization of a workload is relatively easier compared to its containerization.
- A container isolates the process running inside it using namespaces. Some of the network function’s workloads might not run as expected inside an isolated namespace.
- Containers share the kernel with their host and traditionally the deployment of network functions requires kernel hacks.
- The architecture of telco networks is complex. Migrating it to a container-based architecture would not be easy.
In addition to this telcos work in a highly regulated environment where they are expected to have:
- Service Level Agreements (SLAs) for the availability of the network. Usually, this is 99.999% (~5.26 minutes in a year).
- Maintain the backward compatibility of the network with up to 50 years of legacy requirements.
- Tight regulation from governments and authorities.
To ease this transition we have CNF Test Suite and CNF Testbed
CNF Test Suite
The CNF Test Suite is defined by the Telecom User Group (TUG) and Cloud Native Network Function Working Group (CNF WG) for telcos to test their network functions deployed in a cloud-native environment for cloud-native principles:
- Configuration: The configuration for CNF should be defined in a declarative manner in ConfigMaps, Operators, or any other resource.
- Compatibility, Installability & Upgradability: CNFs should work with Certified Kubernetes Products. CNFs should be distributed & deployed as Containers, Operators, or Helm Charts.
- Microservice: CNFs should be built as microservices.
- State: The state of CNFs should be stored in a custom resource or a database like
etcd. - Reliability, Resilience & Availability: Failures are inevitable in a non-carrier grade cloud environment. So a CNF should be reliable, resilient, and available during such failures.
- Observability & Diagnostics: CNFs should provide endpoints and data to establish the observability stack (metrics, tracing, and logging).
- Security: The containers associated with CNFs should be isolated from their host and other containers. They should also be verified against common CVE and other vulnerabilities.
CNF Testbed
CNF Testbed provides reference code and test suites for benchmarking the performance and resiliency between network functions deployed as VNFs and CNFs.
It provisions the infrastructure for a Kubernetes and OpenStack cluster. After that, it deploys similar workloads on both environments to benchmark their performance using testing tools such as NFVbench.
Thank you for taking the time to read this blog post! If you found this content valuable and would like to stay updated with my latest posts consider subscribing to my RSS Feed.
Resources
What is telco cloud?
What is NFV?
What is NFV MANO?
What are Virtual Network Functions (VNFs)?
What is Network Functions Virtualization (NFV)? | VMware Glossary
About virtual network functions over VPC
Infoblox Network Function Virtualization
VNF and CNF, what’s the difference?
Nokia Cloud Mobility Manager
Lessons Learnt Developing and Deploying a Cloud Native Network Function - Paul Graham
cncf/cnf-testsuite
Testing cloud native best practices with the CNF Test Suite
cncf/cnf-testbed
Cloud Native Network Function (CNF) Testbed - Taylor Carpenter & Denver Williams
K8s Best Practices for Telco Apps - Taylor Carpenter & Bill Mulligan
Building CNF applications with OpenShift Pipelines
Keynote: E2E 5G Cloud Native Network - Heather Kirksey, Azhar Sayeed & Fu Qiao
Understanding edge computing for telecommunications