The Linux Foundation announced at its European Open Network Summit, in Amsterdam further collaboration between the Cloud Native Computing Foundation (CNCF) and LF Networking (LFN). Such a collaboration brings the cloud and telco worlds closer, hopefully leading to migrations of Virtual Network Function (VNFs) to Cloud-native Network Functions (CNFs).
Arpit Joshipura, General Manager, networking, The Linux Foundation said: “We have seen service providers embrace open source networking in large numbers. Benefits of virtualization and VNFs, coupled with automation platforms like ONAP, are now de facto deployment models.
“As edge, IoT, 5G and AI start using these highly-automated cloud platforms, we are excited to see the best of both worlds come together – the scale and portability of cloud coupled with the agility, reliability and automation of telecom.”
The unexpected impact of 5G ripples on
As the next generation of networks evolve, especially related to 5G and the applications services they will support, there is a need to embrace characteristics inherent to ‘cloud native architectures’, including:
Compared to traditional VNFs (network functions encapsulated in a Virtual Machine (VM) running in a virtualized environment on OpenStack or VMware, for example), CNFs (network functions running on Kubernetes – whether on public, private, or in hybrid cloud environments) have major attractions. CNFs are:
- lighter weight
- faster to instantiate
- exploit container-based processes (which are inherently easier to scale, chain, heal, move and back up).
As part of this two of the fastest-growing Linux Foundation projects, ONAP (part of LF Networking) and Kubernetes (part of CNCF), are coming together. The objective is to support the next-generation of telco architecture – with operators move their VNFs into CNFs running on Kubernetes.
Dan Kohn, Executive Director of Cloud Native Computing Foundation said: “I’m thrilled to collaborate with our sister Linux Foundation organization, LF Networking, to demonstrate the capabilities of CNFs.
“These implementations will bring greater elasticity to the networking space through critical pieces of the cloud native stack – like container orchestration, service mesh architectures and microservices – and allow for a new level of self-management and scalability.”
The importance of ONAP
Early examples of both VNF and CNF enablement already exist within ONAP, which is an user driven project, via working projects from the CNCF and ONAP communities. ONAP’s inaugural release, Amsterdam, represents the second stage (2.0) of network architecture evolution. It runs in a VM – in an OpenStack, VMware, Azure or Rackspace environment.
ONAP’s upcoming release, Casablanca, will introduce the next phase of network architecture evolution (3.0). This will:
- run on Kubernetes
- work on any public, private, or hybrid cloud.
ONAP currently supports VNFs on either VMs (running on OpenStack or VMware) or containers (running on Kubernetes via KubeVirt or Virtlet).
Specific projects addressing the migration roadmap to cloud native include:
- LFN ONAP Multi-VIM: this aims to enable ONAP to deploy and run on multiple infrastructure environments, for example: OpenStack and its different distributions; public and private clouds; microservices containers, etc.
- LFN ONAP OOM: this enables ONAP modules to run on Kubernetes, contributing to availability, resilience and scalability for ONAP deployments (it also sets the stage for a full implementation of a microservices architecture)
- OPNFV: the latest OPNFV release, Fraser, expands cloud native NFV capabilities in nine different projects, more than double the number of supported Kubernetes-based scenarios; it has deployed two containerized VNFs, and integrated additional cloud native technologies from CNCF relating to service mesh (Istio/Envoy), logging (Fluentd), tracing (OpenTracing with Jaeger), monitoring (Prometheus), and package management (gRPC)
- CNCF Cross-cloud Continuous Integration (CI): this is working on cross-project interoperability and cross-cloud deployments of all cloud native technologies and shows the daily status of builds and deployments on a status dashboard
- Ligato: this provides a platform and code samples for development of cloud native VNFs (and includes a VNF agent for Vector Packet Processing (FD.io) as well as a Service Function Chain (SFC) controller for stitching virtual and physical networking.
- (Network) Service Mesh: this embraces a novel approach to solving complicated L2/L3 use cases in Kubernetes (ones tricky to address with the existing Kubernetes Network Model); inspired by Istio (see above), Network Service Mesh maps the concept of a service mesh to L2/L3 payloads.
“Containerization has been one of the cornerstones of our network transformation,” said Catherine Lefevre, AVP of Research Technology Management, AT&T.
“Cloud-native development represents the next level of efficiency as part of the ONAP target architecture and we’re excited to be a part of this initiative. We expect significant benefits from the OOM Project, such as improved scalability and resiliency, as well as additional cost efficiencies.”
Enterprise Times: what does this mean
For those who do not know, 5G is shaking up the telco industry in a way similar to that in which blockchain is shaking up logistics and supply chain. In the case of 5G introduction, most telcos are having to rethink the fundamentals about how to support the services and applications at a speed commensurate with the underlying communications. This is necessitating an ever greater move from VMs, already pretty much standard in computing, to VMs optimised for containerisation: CNCF + LFN.
With this hybrid approach, service providers will be able to to deliver next-generation services by realizing the promise of containers, utilizing within clouds. These, combined with the traditional open source ecosystem-wide benefits, add:
- reduced CAPEX and OPEX
- increased development speed