CNF (Cloud-native Network Function) is a software implementation of a network function, traditionally performed on a physical device (e.g. IPv4/v6 router, L2 bridge/switch, VPN gateway, firewall), but built and deployed in a cloud-native way.
The CNFs offered on this site are:
- • Various network functions packaged into Docker containers (networking microservices)
- • Ready to be deployed & orchestrated by Kubernetes in private, public or hybrid cloud infrastructures
- • Manageable via cloud-native APIs (protobuf-modeled, configurable via gRPC / K8s CRDs / key-value data stores such as ETCD)
- • Ready to be chained with other CNFs to form more complex networking functions, e.g. using Network Service Mesh
Why do you need CNFs?
CNFs are a new approach to building complex networking solutions, based on the principles of cloud-native computing and microservices. These bring many benefits, such as:
Lowered costs – cloud-native networking infrastructure does not need to run on specialized hardware anymore. It can run on commodity servers connected in a private cluster, or even in public cloud infrastructures like AWS or Google Cloud. With features like auto-scaling, metered billing, and pay-per-use models, you can completely eliminate sub-optimal physical hardware allocations and costs connected with the maintenance of physical hardware.
Agility – with CNFs, feature upgrades do not involve hardware replacement any more. Instead, rolling-out of a new feature usually takes just the implementation of a new networking microservice and its deployment into the existing infrastructure. This decreases time to market dramatically – and lowers the costs of new features again.
Elastic scalability – a cloud-native solution can scale at the level of individual microservices (CNFs), which can automatically go live and terminate in a fraction of second, based on demand for their services. The usage of public clouds allows them to scale almost without limits, with no need for hardware upgrades.
Fault-Tolerance & Resilience - cloud-native architecture patterns are based on loosely coupled microservices, which can greatly reduce the operational and security risk of massive failures. Containers can restart almost instantly, upgrades can be performed on a microservice level, without downtimes, allowing for automated fast rollbacks if needed.
How we build CNFs
Each cloud-native network function consists of three main building blocks: data plane, control plane, and management plane.
For the data plane, we often use FD.io VPP, which is a fast, scalable layer 2-4 network stack that runs in userspace. VPP benefits include high performance, proven technology, modularity, and a rich feature set. If the existing VPP features are not meeting our needs, we often extend the VPP functionality with our own plugins. If the network function that we aim to implement does not fit VPP at all (e.g. is too complex to be implemented on VPP, and/or the top performance is not crucial), we use other open-source projects and tools as well.
The management plane for our CNFs is built on the Ligato.io CNF framework, written in Golang. The API of each CNF is modeled with Google Protocol Buffers, which allows for a unified way of controlling whole CNF deployment via gRPC, Kubernetes CRDs, key-value data stores such as ETCD or Redis, or message brokers such as Apache Kafka.
The control plane usually falls either into the data plane, or the management plane components.
How we connect (wire) the CNFs
For CNFs, the standard networking interconnections between containers provided by general-purpose CNI plugins is not sufficient – the CNFs usually need to talk between each other and with external networks on different network layers, using a wide range of networking protocols. At the same time, since packet processing is the main goal of CNFs, their demand for fast, stable and low-latency throughput is much higher.
With VPP, leveraging technologies like DPDK and memory interfaces (“memifs”), we are able to deliver the packets into the CNFs at speeds of several Mpps / Gbps. To accomplish that in a Kubernetes-native way, we use open-source projects such as Network Service Mesh, Contiv-VPP CNI, SR-IOV K8s Device Plugin.
Our CNFs are CNI plugin/container wiring technology -agnostic, meaning, that the same CNFs can be used on top of Network Service Mesh, as well as other wiring technologies / CNI plugins.
Take a look at our demo with a sample CNF deployment on top of Network Service Mesh or Contiv-VPP CNI.
CNF Designer & Provisioner
Since the configuration of complex interconnections between CNFs can be a cumbersome process involving the steep learning curve of container networking technologies and APIs, we have created a graphical user interface that allows defining a complex CNF deployment with a few clicks. Independently from the selected networking technology (e.g. Network Service Mesh or Contiv-VPP CNI), its CNF provisioning backend automatically deploys the CNFs with all the necessary wiring instructions into your Kubernetes cluster based on your GUI input.
Take a look at our demo of CNF Designer.
CNF Use-Cases
Although the possibilities of CNF deployments are endless, it may be worth to give you an idea of what can be achieved with them.
Carrier-Grade NAT Solution
This example use-case shows a cloud-native carrier-grade NAT solution, which shifts the NAT function and configuration from the customer premises to the Internet service provider’s cloud infrastructure. This solution can lower the requirements on hardware and software features of CPE devices, as well as simplify the management and configuration of the NAT solution, allow for easy horizontal scaling, upgrades and failovers.
Virtual CPE (Customer Premise Equipment)
In this example use-case, the whole functionality of the customer premises equipment is moved into the service provider’s cloud infrastructure. The only networking equipment deployed at the customer premises can be just a cheap simple L2 switch with no additional features, which would be connected to the ISP’s cloud infra. That requires almost no additional maintenance, even in case of a future upgrade of CPE functionality. The CPE features are built as a chain of CNFs (networking microservices), which apart form easy management, scaling and upgrades, also allow for different feature sets per customer, deployed and modified on demand.
Take a look at our demo, which showcases a simplified version of the virtual CPE use-case based on our CNFs.
