5G Success Starts with Cloud-Native Infrastructure
5G is transforming the digital landscape for service providers, bringing with it new use cases and revenue opportunities. Service providers who can successfully transition to 5G can benefit from new enterprise applications, industrial automation, IoT, as well as consumer services like gaming and AR/VR. These new use cases are enabled by a new 5G standalone (SA) core built on a cloud-native service-based architecture (SBA). In order to make the most of these new opportunities, service providers must define and deploy a consistent cloud-native infrastructure from the core to the far edge that can support the 5G Core, vRAN and N6-LAN network functions (NF), as well as enterprise and consumer applications and services. Cloud-native infrastructure lays the foundation for a service provider’s success with 5G.
Because infrastructure is a critical building block for 5G deployments, determining a service provider’s ability to fully realize new 5G use cases, it is imperative for service providers to define, manage, and control their own 5G cloud-native infrastructure. In fact, there is a great deal of precedent for focusing investment on infrastructure. One can look to the hyperscalers Google, AWS, Azure, and even Apple; all of these companies invested heavily in building an infrastructure that could reliably and securely deliver revenue generating services and customer applications.
Leveraging technologies that power today’s modern web applications, 5G infrastructure is built on a cloud-native, containerized architecture that enables new levels of operational automation, flexibility, and adaptability for the service provider. Kubernetes has become the industry standard for container management and orchestration, and it is what almost all service providers use for their cloud-native infrastructure. Service provider networks, however, place new, unique demands on the flow of data into and within the Kubernetes cluster. Kubernetes isn’t natively equipped to meet these demands. In the following sections, we will examine the unique requirements that a cloud-native infrastructure must meet in order to support critical vRAN, 5G Core NFs, and enterprise and consumer applications, then we will discuss how F5 addresses these requirements.
In order for service providers to deliver reliable, secure, and scalable services, they must account for three primary types of requirements:
- Control: Service providers must be able to apply policy control over multiple traffic types that are unique to a service provider network. Being able to apply intelligent traffic management will allow service providers to support new services like network slicing, support the transition from 4G to 5G protocols, and provide the foundation needed for new 5G-enabled use cases.
- Security: In order to maintain high levels of customer trust and retention, security controls must be applied at multiple points and across multiple layers in the network.
- Visibility: Visibility of traffic flow into and within the infrastructure will improve operational efficiency, increase the efficacy of troubleshooting, and make revenue controls more flexible.
First, we will examine the requirements and solution for ingress/egress networking of the Kubernetes cluster, also called the “north-south traffic.” Standard Kubernetes networking is sufficient for most web applications running in a cloud environment where HTTP/HTTPS is the primary communication protocol into and within the Kubernetes cluster. A service provider environment presents unique challenges for Kubernetes networking because of the need to support a range of protocols. The move to 5G will not be a hard switch; most service providers will need to run 4G and 5G concurrently, and they need a migration solution that will help them do this. For example, as the 5G SA core is rolled out, many service providers will leverage their existing 4G billing and charging systems to speed the delivery of 5G, allowing them to more quickly get a return on their 5G investment. This means that their Kubernetes clusters must support both for 4G and 5G protocols. A service proxy for ingress/egress control is required to enhance existing Kubernetes functionality.
Figure 1: The F5® BIG-IP® Service Proxy for Kubernetes makes it easier to support multiple protocols.
A service proxy providing ingress/egress control will be able to meet the stringent requirements of a service provider network by providing enhanced networking services for Kubernetes:
- Support for multiple protocols, including 4G and 5G signaling
- Routing
- Load balancing
At the ingress point of the Kubernetes cluster, service providers must also protect the cluster from attacks and provide per-subscriber visibility. Applying a set of robust security services at the point of ingress into the cluster is the first line of defense. Security services such as DDoS protection, firewall, and WAF can be applied at ingress to prevent malicious traffic from entering the cluster and impacting 5G core network functions and customer applications. In addition to ingress security, service providers need visibility into per-subscriber traffic. This valuable data aids in troubleshooting network problems and also can be used for revenue assurance. Service providers spend a tremendous amount of money on revenue assurance to ensure that events can be tracked for compliance and billing purposes. This data can be gathered at the entry point to the Kubernetes cluster and then compared to reports from the dynamic set of containers.
Figure 2: A service proxy can help improve security and visibility by tracking data at ingress.
In summary, a service proxy providing ingress/egress control, security, and visibility provides the critical functionality that Kubernetes needs in order to meet the demands of a 5G cloud-native infrastructure.
Now that we have addressed requirements for north-south traffic into a Kubernetes based cloud-native infrastructure, we can examine the requirements and challenges for traffic within the cluster. Like ingress and egress, east-west communication between services running within the cluster must meet higher standards for observability and security in order to be compatible with cloud-native 5G infrastructure. Service providers must be able to apply security policies that control communication between the services within the cluster. The disaggregation of the 5G core creates a requirement for more within-cluster observability, allowing service providers to assess the health of their services are healthy, and identify the root cause of failures when they are not. Service providers must also ensure that their infrastructure has the capacity to meet governmental requirements such as lawful intercept. These requirements present challenges for Kubernetes networking and controls. One method of addressing these challenges is to implement a service mesh such as Istio, which adds the following capabilities:
- Reliability: retries, timeouts, mitigating cascading failures
- Observability and debugging: monitoring, tracing, metrics
- Security: authN/authZ, managing secrets, ensuring encryption
- Traffic management: service discovery, custom routing, canary deploys
Figure 3: F5® Aspen Mesh™ improves visibility and security in east-west communication within a Kubernetes cluster.
F5 is a leader in application, network, and security services and provides a range of solutions for 5G core and cloud-native 5G infrastructure. F5 provides two main products that address the challenges service providers face when building a cloud-native infrastructure to support the networking and security requirements for the vRAN, 5G Core, and enterprise application.
- F5 BIG-IP Service Proxy for Kubernetes (BIG-IP SPK)
- Carrier-Grade Aspen Mesh
BIG-IP SPK is unique in the industry, providing ingress/egress control with multi-protocol signaling support and security specifically designed for service providers deploying a cloud-native infrastructure across their footprint. BIG-IP SPK also aligns with Kubernetes design patterns for configuration and orchestration. This solution makes it possible to apply industry-leading networking and security features to a Kubernetes based infrastructure.1
Ingress/Egress Control
- L4 Load Balancing: TCP, UDP, and SCTP
- L7 Load Balancing: Diameter, SIP, HTTP/2
- GTPcV2 Load Balancing
- Routing
- Rate limiting
Security
- Signaling Firewall, DDoS, WAF
- Encrypt/Decrypt
- Topology Hiding
Visibility
- Revenue assurance
- Statistics and Analytics
In addition, BIG-IP SPK can leverage the enhanced capabilities of Intel SmartNIC for greater performance and scalability.
Figure 4: BIG-IP Service Proxy for Kubernetes can integrate with SmartNIC for enhanced performance.
Carrier-Grade Aspen Mesh is a service mesh purpose-built for service provider cloud-native infrastructures. The Aspen Mesh service mesh is built on open source Istio and adds features critical for a service provider network.
- Unequaled traffic visibility within each 5G core Kubernetes cluster, allowing revenue assurance and enabling service providers to monetize 5G using existing billing systems.
- Stronger security with a consistent approach to encrypting and authenticating all traffic between multi-vendor and multi-site network functions, built on the strongest mTLS techniques and tied back to a carrier-grade, 3GPP-compatible certificate authority.
- Traffic control and policy management that enable service providers to efficiently route service communications and configure and enforce business and compliance policies for the service mesh and network traffic.
Aspen Mesh also provides packet capture capabilities, which standard Kubernetes does not provide. Packet capture facilitates troubleshooting communication issues between CNFs within the cluster and gives service providers the infrastructure necessary to comply with governmental requirements like lawful intercept.
BIG-IP SPK and Carrier-Grade Aspen Mesh work in tandem to resolve the challenges of using Kubernetes in a 5G cloud-native infrastructure. BIG-IP SPK addresses the need for multi-protocol signaling support, security, and visibility of traffic into the Kubernetes cluster, while Carrier-Grade Aspen Mesh address communication between CNFs, both critical functions to the deployment of a 5G cloud-native infrastructure. The figure below depicts a 5G infrastructure utilizing BIG-IP SPK and Aspen Mesh.
Figure 5: Cloud-native networking architecture
Service providers understand the central role a cloud-native infrastructure will play in the success of their 5G deployment, and in their ability to support the applications and services enabled by a new 5G powered network. Service providers are looking for solutions that will provide them the control, security, and visibility needed for the 5G cloud-native infrastructure. F5 understands the demands of a service provider network and provides solutions that enable service providers to use Kubernetes to successfully build and deploy their cloud-native 5G infrastructure.
Connect with F5
