Taking a step back

When discussing the specific benefits and approaches of leveraging eBPF programs, it is very easy to head directly into a technical rabbit hole. The technology is very detailed and can be used for a wide variety of use cases. Consequently, conversations can quickly get wrapped around specifics while glossing over the fundamental elements of the technology. As is true with any newer technology, it is often helpful to level-set and take a step back to discuss the basics. This post will serve to do just that- provide a high level view into the fundamentals of an eBPF program, and more specifically, into an eBPF program being used for 5G SA visibility.

What is eBPF, and why is it so important?

The Extended Berkeley Packet Filter (eBPF) functions constitute a relatively new and powerful set of capabilities embedded in the Linux kernel. First released in 2014 (w/ Linux 3.18) we are seeing accelerating adoption of eBPF for very good reason.

The access that eBPF provides enables a variety of important use-cases in modern cloud-native environments. Use-cases span across application and network performance monitoring, service mesh, load balancing, continuous discovery, dynamic topology and anomaly detection for a variety of development, systems engineering, operations, cloud infrastructure, 5G / IoT, and cybersecurity applications. We discuss these in more detail further below.

As 5G stand alone (SA) environments are beginning to roll out in more earnest, there is an ongoing conversation about how to best support visibility of these container-centric platforms. Network function vendors, carriers, MNOs, and MVNOs all have skin in the game and are taking part in this conversation. At the core of the discussion is a very simple question- what is the best way to instrument and observe these complex and heavily containerized systems?

Traditional tools are no longer viable- this is common knowledge across the ecosystem. The days of deploying taps are long gone, and the days of relying on virtual taps for “cloud resources” have also faded away. We are now firmly in the era of “cloud-native”- the first major evolution of the cloud. Cloud-native has ushered in a new focus on how to best leverage virtual resources and distributed computing, with the core tenet being a shift from VMs and VNFs to containers and CNFs. The challenge now is determining how to best introspect these containerized environments.

How to Get Visibility into 5G SA Ephemeral and Cloud-native Network Resources 

Cloud native and containerized architectures are becoming the de facto design standard for 5G networks and applications. In the telecommunications industry, the players are focused on building out 5G Stand Alone (SA) deployments to deliver the promise of faster connection speeds to enable IoT, medical, autonomous use cases - not to mention improved communications, support the streaming of real-time content and the promise of a myriad of new applications and services. As we work with Tier 1 operators, MVNOs and analytics providers we are encountering a staggering issue: they can no longer adequately monitor, correlate, and measure critical network and application communications events at the container level and across the infrastructure.

One of the biggest drivers that has impacted the design of 5G systems is the goal of providing extremely low latency and high-speed data rates throughout the entire network. The increase in data delivery speeds with 5G environments promises staggering benefits- we are talking about moving from the 1 Gbps world of 4G into a promised 10 Gbps future- or more simply put, an evolution akin to shifting from the horse and buggy to internal combustion engines. Such an enormous jump in the speed at which the world’s most valuable resource (data) can be exchanged helps explain the amount of energy and excitement around 5G that we are all collectively experiencing.

But how does this translate into architecture principles?

Leaving carrier aggregation (CA) and massive MIMO aside for another conversation, we will focus on the network itself. For starters, the 3GPP determined early on that the control plane (CP) and user plane (UP) must be split (across both the RAN and the core) so that each plane can be independently scaled and flexibly deployed. In addition to this split, the decision to take a NFV/SDN, or “cloud-native” approach to the underlying resources is critical in achieving the promised speeds of 5G. Cloud-native allows for centralization of compute resources, and optimization of all physical resources that are serving network functions (NF), regardless of location in the network.

NF communications within the SBA