From Virtual Network Function (VNF) to Cloud-Native Network Function (CNF)
Posted on March 7, 2023 — 3 Minutes Read
Connecting and powering the digital world is a physical infrastructure of subsea cables, wavelengths that carry the bits and bytes within, and the various network switching and routing functions that, in light of the increasing adoption of Software Defined Network (SDN), are gradually migrated from physical network functions (PNF) on purpose-built hardware equipment, to virtual network functions (VNF) on top of virtual machines (VM) on generic hardware, in what is proposed by the European Telecommunications Standards Institute (ETSI), a Network Functions Virtualisation (NFV) architecture. This highly agile and scalable architecture allows for what is known as a telco cloud, that is increasingly adopted by the telecommunications carriers around the world, to decouple the product development rhythm from the lifecycle of the underlying hardware equipment, in order to rapidly respond to the changing customer needs and network demand with software-defined services. With VM being an abstraction of the underlying physical machine, by design there is little friction migrating from PNF to VNF, despite having to forgo the hardware acceleration and offloading from Application-Specific Integrated Circuit (ASIC), that are only available on purpose-built hardware. Bound by the confines of the virtual appliances and their corresponding VMs also, the VNFs in a NFV architecture need to be designed with and deployed in High Availability (HA) to ensure service availability, should any of these VNFs or VMs undergo maintenance or experience outage.
The need to further break free of the boundaries of the virtual appliances results in the evolution from VNF to Cloud-Native Network Functions (CNF), that are based on disaggregated container-based services in a microservice architecture. These containerised services are lightweight and standalone applications, that are provisioned and scaled on demand, and work in tandem to provide the corresponding network functions. With the help of a central orchestration platform, the most prominent of which being Kubernetes, should any of these containerised services experience outage, the service will self-heal by restarting or replacing the failed containers; or should more capacity be needed due to a surge in demand, the service will deploy additional instances to handle the increased requests. Together with ability for rolling update that allows for continuous integration/continuous delivery (CI/CD) with zero downtime, CNF is a perfect fit for the cloud emerging as the new network.
It is not without challenge however for a network function to evolve from VNF to CNF, and the biggest among them is to refactor a field-proven, yet age-old monolithic application, with a complex codebase that has grown as large as its technical debt, that a tiny change will break things in the most unexpected way, into disaggregated containers. This is most prominent in the network security space, and it is for this reason that the tried and trusted appliance-based network security vendors often acquire products that have started with a CNF foundation, and integrate them into their portfolio for a plug and play CNF offering, instead of evolving their home-grown appliance-based solutions. Palo Alto Networks did so with RedLock and Fortinet with OPAQ. Both have renamed and integrated the acquired CNFs into their existing product portfolios, respectively the Prisma suite and FortiSASE. With the other security products in the portfolio appliance-based still, the degrees of integration and the overall user experience are however of question, especially in competition with other security vendors, Zscaler for example, that are fully cloud-native. Paradoxically, it would seem that for those with a head-start in the network security space, their years of research and development are as much as an advantage as they are a burden in their journey from VNF to CNF.