The Linux Foundation brings network automation and cloud native communities together
The Linux Foundation announced further collaboration between telecom and cloud industry leaders enabled by the Cloud Native Computing Foundation (CNCF) and LF Networking (LFN), fueling migrations of Virtual Network Function (VNFs) to Cloud-native Network Functions (CNFs).
As networks evolve to support services and applications, they will need to embrace characteristics inherent to cloud native architecture, such as scalability, automation, and resiliency.
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 on public, private, or hybrid cloud environments) are lighter weight and faster to instantiate. Container-based processes are also easier to scale, chain, heal, move and back up.
Two of the Linux Foundation projects – ONAP (part of LF Networking) and Kubernetes (part of CNCF) – are coming together in telecom architecture as operators evolve their VNFs into CNFs running on Kubernetes.
“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,” said Arpit Joshipura, General Manager, networking, The Linux Foundation.
“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.”
“I’m thrilled to collaborate with our sister Linux Foundation organization, LF Networking, to demonstrate the capabilities of CNFs,” said Dan Kohn, Executive Director of Cloud Native Computing Foundation.
“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.”
Early examples of both VNF and CNF enablement are seen within ONAP and 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, brings the next phase of network architecture evolution (3.0): it runs on Kubernetes, and works 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: 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: Enables ONAP modules to be run on Kubernetes, contributing to availability, resilience, scalability and more for ONAP deployments and sets the stage for implementation of a microservices architecture, expected with the third release, Casablanca, due out later this year.
OPNFV: The latest OPNFV release, Fraser, expanded cloud native NFV capabilities in nine different projects, more than doubled the number of supported Kubernetes-based scenarios, 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). These updates move the cloud native capabilities from container orchestration to include operational needs for cloud native applications. Additionally, the FastDataStacks project takes advantage of FD.io work to incorporate the VPP dataplane into Kubernetes networking capabilities to enable cloud native network-centric services.
CNCF Cross-cloud Continuous Integration (CI): Ensures cross-project interoperability and cross-cloud deployments of all cloud native technologies; shows the status of builds and deployments on a status dashboard.
Istio: Allows users to connect, manage, and secure microservices for both containerized and non-containerized workloads.
Ligato: Provides a platform and code samples for development of cloud native VNFs. It includes a VNF agent for Vector Packet Processing (FD.io) and a Service Function Chain (SFC) controller for stitching virtual and physical networking.
(Network) Service Mesh: An approach solving L2/L3 use cases in Kubernetes that are tricky to address with the existing Kubernetes Network Model. Inspired by Istio, Network Service Mesh maps the concept of a service mesh to L2/L3 payloads.
As telecom network transformation requires a hybrid approach, service providers will be better equipped to deliver services by realizing the promise of containers, utilizing the best of both telecom and cloud.
Combined with open source, ecosystem-wide benefits include portability, resiliency, reduced capex and opex, increased development velocity, automation, and scalability.
“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.”
“Cloud-native NFV delivers on the agility, velocity and cost savings promised so many years ago in the NFV manifesto. We are at the cusp of solving the two major blockers: VNF→ CNF transition, and a cloud-native way to wire the CNFs together in Kubernetes,” said David Ward, CTO and chief architect of Engineering, Cisco.
“VPP provides the feature rich high performance userspace dataplane needed for CNFs, Ligato provides the toolkit for building the CNF agents to manage the VPP dataplane, and Network Service Mesh provides a truly ‘cloud-native’ approach to how to stitch CNFs together. We look forward to seeing the good work in these areas at Kubecon in Seattle in December.”
As migrations of VNFs to CNFs continue to evolve, the open source networking ecosystem enters the next phase of innovation, ‘Harmonization 3.0.’ The next phase (Harmonization 3.0) drives collaboration between edge and carrier cloud and enterprise.