What Is a Cloud Native Network Function (CNF)? Meaning, Architecture, and Examples

CNF is a software service that fulfills network functionalities while adhering to cloud-native design principles.

Last Updated: December 7, 2022

A cloud-native network function or CNF is defined as a software service that fulfills network functionalities while adhering to cloud-native design principles without requiring any hardware or appliance to house it. This article explains the architecture and working of a cloud-native network function. It also provides examples of commonly-used CNFs.

What Is a CNF?

A cloud-native network function or CNF is a software service that fulfills network functionalities while adhering to cloud-native design principles without requiring any hardware or appliance to house it. 

CNF (cloud-native network function) is a software component of a network function that is normally performed on a physical device and constructed and delivered in a cloud-native manner. CNF is a novel technique used to construct complicated networking systems based on cloud-native computing as well as microservices principles.

CNFs have several advantages, including:

  • Reduction in costs: Cloud-native networking infrastructure is no longer required to operate on specific hardware. It may operate on commodity servers connected to each other in a private cluster. It also works on public cloud infrastructures, such as Amazon Web Services (AWS) and Google Cloud. With capabilities like auto-scaling, metered pricing, and pay-per-use models, it is possible to fully remove sub-optimized physical hardware allocations as well as expenses associated with hardware maintenance. 
  • Greater agility: With CNFs, feature improvements no longer need hardware replacements. Typically, the rollout of a new feature requires only the creation of a brand-new networking microservice as well as its deployment inside the current infrastructure. This drastically reduces the time to market and cost of new features.
  • Seamless scalability: A cloud-native solution may scale at the stage of individualized microservices (i.e., CNFs) that can go live or expire in a matter of seconds, depending on the request for their services. The use of public clouds enables nearly limitless scaling without the requirement for hardware upgrades.
  • Exceptional resilience: Cloud-native architectural principles are based on loosely linked microservices, which may significantly minimize the security and operational risk associated with large failures. Containers can be restarted nearly instantaneously, and microservice-level updates can be executed sans downtimes, allowing for automatic, rapid rollbacks if necessary.

See More: Java vs. JavaScript: 4 Key Comparisons

The evolution of CNF

Previously, application-specific integrated circuits, which were formerly necessary for network hardware appliances, were the only way to accomplish cloud-native processing capability. Due to the fact that CNFs are entirely software-led, they employ virtual interfaces rather than physical ones.

Physical network functions (PNF) are devices that physically handle packets in support of networking and/or application services. A PNF consists of closely connected, purpose-led hardware and software functions that correspond to their network station. Customer premise equipment (CPE) ports, virtual private network (VPN) ports, and firewall-powered equipment are examples of PNFs implemented in your network.

A computer network comprises interconnected PNFs where linked networks are combined into bigger networks with a diversified selection of applications and services, customer information, and heterogeneous connectivity.

A network function that operates in a virtual environment is a virtual network function (VNF). Typically, virtual network functions (VNFs) are executed on virtual machines or VMs, managed with best practices and VM orchestration software. Virtual machine-based network functions operate in an “enclosed environment” bordered by the guest OS, hypervisor, host, and network input/output system. Except for speed and size, VNFs replicate many roles and characteristics of PNFs.

Cloud-native is a new methodology for designing and operating applications in cloud-based virtual environments. It is based on numerous fundamental ideas. Applications are “carved up” into microservices, which are smaller units. Application monoliths are replaced by a constellation of linked microservices.

Containers hold and offer a runtime environment for microservices. Instead of VM overhead, they bundle up the app code and its dependencies.

Container lifecycle management, comprising scheduling, placement, start/stop/restart, and visibility, is handled by Kubernetes orchestration. In either physical or virtual hosts, Kubernetes pods carry one or even more containers.

As with other cloud-native applications, cloud-native network functions (CNF) incorporate DevOps, CI/CD pipelines, open source, and the 12-factor techniques for software-as-a-service (SaaS) application development.

See Morte: What Is TDD (Test Driven Development)? Process, Importance, and Limitations

8 key features of a Cloud Native Network Function (CNF)

A CNF, which is basically a cloud-based network service or application, has the following important characteristics:

  1. No server or OS dependencies

Cloud-native network operations have no preference for a specific operating system or computer. They function at a higher level of abstraction. The sole exception is when a microservice requires certain capabilities, such as solid-state discs (SSDs) or graphic processing units (GPUs), which may only be available on a subset of workstations.

  1. Allocation of resources based on predefined policies

The CNFs conform to the governance model specified by a set of policies. They comply with rules that assign resources to services, like central processing units (CPU), as well as storage quotas and network regulations. In an enterprise environment, for instance, the central IT department may create rules to assign resources to each department.

  1. Agile DevOps-led management

Each service in a CNF solution has a distinct life cycle that is controlled by an agile DevOps methodology. Multiple continuous integration/continuous delivery (CI/CD) workflows may collaborate to deploy and administer a cloud-native service.

  1. Separation of stateful and stateless

Persistent and resilient CNF services adhere to a certain structure that ensures greater availability and resilience. There are stateless services in addition to stateful ones. There is a relationship between storage and container utilization. Persistence must be considered increasingly in relation to the state, statelessness, and microstorage contexts.

  1. Designed for integration and APIs

CNFs employ lightweight application programming interfaces (APIs) based on protocols such as representational state transfer (REST), Google’s open-source remote procedure call (gRPC), etc. REST is utilized as the lowest common denominator to offer HTTP APIs (HTTP). gRPC is frequently employed for internal communication between services to improve performance.

  1. Containerized packaging

CNFs are lightweight containers comprising a set of autonomous and independent services. Unlike virtual computers, containers may quickly expand and contract. Since scaling units have shifted to containers, infrastructure usage has been optimized.

  1. Microservices coupling

Through the application runtime, CNF services belonging to the same application locate each other. They exist apart from other services. When effectively integrated, elastic infrastructure, as well as application architectures, may be scaled out with efficiency and superior performance.

  1. Self-service and automation

CNFs are implemented on elastic, virtual, and shared infrastructure. They may coordinate with infrastructure within the system to dynamically expand and contract according to the fluctuating demand. Moreover, it is very easy to automate. They are compatible with the notion of infrastructures as code. Managing these sophisticated network systems needs a degree of automation.

Importance of cloud-native network functions (CNFs) in 5G

The 5G Core Network standard developed by 3GPP adopts a Service Based Architecture (SBA). This cloud-native method to the centralized network eventually necessitates the dispersion of network software and hardware. This is required to address the scalability, performance, and diverse service requirements of 5G businesses and users.

A cloud-native 5G network offers the fully digitized architecture necessary for deploying new cloud services and taking full advantage of cloud-native 5G features such as vast IoT implementations, edge computing, as well as network slicing.

Ultimately, Cloud Native Network Functions would assist operators in transitioning from non-freestanding (NSA) 5G architecture, which requires a 4G core network to function, to standalone (SA) 5G. Standalone 5G combines 5G radios and a 5G core network local to the cloud.

In addition to stateless and stateful services, a single & shared data tier, abstracted infrastructure, and streaming telemetry data, a cloud-native design based on microservices provide additional advantages for 5G. However, typical IP routing-akin networking in the data center is incapable of supporting a cloud-native system with service discovery. Consequently, communications providers must understand the fundamental design concepts for cloud-native architecture development.

See More: What Is Integrated Development Environment (IDE)? Meaning, Software, Types, and Importance

CNF Architecture

A cloud native network function is a connectivity service that is designed and constructed to operate inside containers. Most cloud-native concepts (architectural as well as operational), such as K8s service lifecycle management, mobility, robustness, and observability, are inherited by CNFs. 

CNFs encapsulate the physical (PNF) and virtual (VNF) network functions (containers). In addition, virtual machine software overhead is no longer a worry. Containers are not dependent on a guest OS or hypervisor, which means that CNFs in containers may be rolled up and down as necessary. 

With reference to CNF architecture, implementation-specific design decisions are made. To simplify these possibilities to match your needs, an architectural strategy centered on the following is required:

  • Performance, adaptability, programmability, observability, and scalability objectives.
  • Conforms to cloud-native design principles.
  • Accepts “evolvability” as cloud-native technologies develop and new services develop.

With this in view, it is conceivable to envision a comprehensive CNF framework. A typical CNF architecture has a tiered design, with applications, orchestration, and administration layers on top and the software data tier at the bottom. Plugins allow them to carry out numerous tasks. The word ‘plugin’ stands for integrated and/or configurable software components that support a task or tasks performed by the CNF.

Let’s understand these CNF architecture components in detail:

1. The data plane

The data plane includes the user operations area that maximizes performance and bypasses the kernel. Consider FD.io as one such data plane. This open-source project has a huge and dynamic open-source ecosystem, more than ten years of deployed product implementations, and an abundance of features.

2. Linux kernel

A Linux kernel functions like a data plane. One may encounter a throughput ceiling and a delay in feature upgrades. Nonetheless, it is the most used data layer in virtual cloud systems. It is possible to create CNFs that utilize kernel network layering. Performance is enhanced via working on kernel additions like eBPF.

3. Control plane agent

The control plane agent makes northbound application programming interfaces (APIs) available to internal programs, processes, and plugins. In addition, they can interface with external applications, data repositories, and management plane services. Another low-level southbound API enabling programming layer functioning is also provided. Each control plane agent consists of agent plugins that allow at least one CNF function. To encourage future data plane capabilities, one may action existing plugins or design one’s own.

4. Custom plugins

The plugin aspect of the CNF framework allows you to add solution-specific features to your CNF with the use of customized apps. The IPsec virtual private network (VPN) CNF might, for instance, include a control plane. Also feasible are CNFs specialized towards network control plane functions. In addition, the formulation and construction of such a distributed CNF system may require that the control as well as data plane run in distinct pods.

5. The management plane for external components

The cloud-native environment is dynamic and ever-changing. Constantly, additional features, open-source projects, apps, architectures, and tools are created. Examining the landscape of the CNCF is sufficient to comprehend the scope of this effort. External factors, as well as initiatives supporting CNF creation, implementation, and deployments, are suitable for incorporation into ongoing and developing CNF initiatives. They are critical to any future-proof CNF architecture.

DevOps engineers must construct cloud-native network functions (CNFs) the same way they would any other cloud-native application when deploying these. Here are the steps to follow when implementing CNF architecture in a DevOps environment:

  • The first phase involves coarse-grained deployments, which are often implemented as containers. It should then be available in a CI/CD workflow utilizing stateless as well as declarative configuration.
  • The second stage is to enable an orchestrator (such as K8s) installed on homogeneous nodes that manage the service lifecycle. Next, one must guarantee that this network function is equipped with telemetry, which includes statistics, tracking, and event stream-configurable logging.
  • Service discovery is the third phase in CNF architecture implementation. This enables the network service also to be found by other customers inside the cluster or even outside of it. Moreover, to promote a declarative setup, one must emphasize the significance of policies. This relates to relevant and supported network and security rules for the service.
  • Distributed storage is the ultimate phase applicable when stateful workloads are utilized. This enables interoperability with ecosystems native to the cloud. Cloud-native communications, registers, scripts, and system software distribution are additional maturation phases of the CNF architecture.

See More: What is Root-Cause Analysis? Working, Templates, and Examples

Examples Of CNF

Examples of cloud-native network functions are infinite, as they can be adapted to meet any number of enterprise use cases. Here are a few example use cases to illustrate this further:

1. Carrier-grade network address translation (NAT) 

This sample use case illustrates a cloud-based carrier-grade NAT system that moves the NAT functionality and configuration to the cloud storage infrastructure of the internet service provider. This approach may reduce hardware and software requirements for customer premises equipment (CPE) systems. Additionally, it simplifies the administration and setup of the NAT system.

2. Virtualization of customer premise equipment (CPE)

In this example, the job of the CPE is moved to the cloud infrastructure of the CNF service provider. The only networking hardware equipment that has to be installed at the customer’s location is a basic L2 switch with no further features that are linked to the ISP’s cloud infrastructure. 

This needs practically no additional maintenance, even if CPE capability is upgraded in the future. The CPE characteristics are composed of a series of CNFs (or networking microservices). In addition to facilitating simple maintenance, scalability, and updates, this enables customer-specific feature sets.

3. CNF as a load balancer in networks

The intrinsic characteristics of cloud-native networking include scalability and resilience of services. A CNF operates as a load balancer sending data to the back-end containers of the Kubernetes (K8s) system or even as a policy-led forwarder directing traffic to a particular application pod. While Kubernetes-proxy can execute these services, a CNF may be a better match for ingress or load balancing for a number of reasons. It offers maximum performance and scalability via user space packet processing, for instance.

4. Creating network service bundles

CNFs may be organized into the service function chain (SFC) consisting of continuous network functions that support an app or network service offering. SFC provisioning may be handled by an SFC control plane that has been personalized. Depending on the configuration of the associated CNFs, you may use CNF functionalities upon the terminating cloud storage or inside machine learning training application pods.

5. Deploying network services on the cloud

Enterprises using the hybrid cloud as well as multi-cloud architectures are eager to explore CNFs as a means to install network services on public clouds that prohibit physical appliances with ease. In these cloud settings, businesses may also avoid establishing numerous virtual server network equipment, which can be quite expensive in the long run. For these enterprises, the adoption of CNFs is primarily motivated by flexibility and cost reductions.

Transitioning to CNFs

By shifting a number of tasks into containers, the introduction of CNFs may address some of their core shortcomings. This containerization for network components enables the management of how and where cluster-wide operations are executed.

CNFs extend beyond the mere containerization of network operations. This involves deconstructing this into microservices, permitting various versions throughout updates, and using platform services such as generic load balancers and data storage.

Moreover, as cloud-native environments become more prevalent, CNFs must coexist with traditional VNFs throughout the transition. To manage demand, expedite installations, and minimize complexity, service providers need to automate the design, implementation, operation, and maintenance of their networks. To achieve this, standardized configuration and deployment processes, tools developed by open-source groups, and regular testing are very important.

See More: Top 10 DevOps Automation Tools in 2021

Takeaway

We are rapidly moving toward a cloud-native world across IT infrastructure and services. This sort of architecture promotes portability and resilience and also supports agility as the application matures. The same principles apply to network functions as well. Using cloud-native network functions or CNFs, you can achieve greater flexibility in your network and reduce your hardware footprint. 

Did this article help you fully understand how cloud-native network functions work? Tell us on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window . We’d love to hear from you! 

MORE ON DEVOPS

Chiradeep BasuMallick
Chiradeep is a content marketing professional, a startup incubator, and a tech journalism specialist. He has over 11 years of experience in mainline advertising, marketing communications, corporate communications, and content marketing. He has worked with a number of global majors and Indian MNCs, and currently manages his content marketing startup based out of Kolkata, India. He writes extensively on areas such as IT, BFSI, healthcare, manufacturing, hospitality, and financial analysis & stock markets. He studied literature, has a degree in public relations and is an independent contributor for several leading publications.
Take me to Community
Do you still have questions? Head over to the Spiceworks Community to find answers.