GN5-2 Programmable Networks: Current State and Trends

© GÉANT Association on behalf of the GN5-2 project. The research leading to these results has received funding from the European Union’s Horizon Europe research and innovation programme under Grant Agreement No. 101194278 (GN5-2). Co-funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union. The European Union cannot be held responsible for them. 09-09-2025 Programmable Networks: Current State and Trends Grant Agreement No.: 101194278 Work Package: WP6 Task Item: T1 Nature of Document: White Paper Dissemination Level: PU Lead Partner: FAU/DFN Document ID: GN5-2-25-111DCD Authors: Asier Atutxa (EHU/RedIRIS); David Franco (EHU/RedIRIS); Eduardo Jacob (EHU/RedIRIS); Frederic Loui (RENATER); Ivana Golub (PCSS); Susanne NaegeleJackson (FAU/DFN); Pavle Vuletić (UoB/AMRES); Simon Leinen (Switch) Abstract The document analyses the current status of network programmability and programmable networks and suggests possible future work in this area within the GÉANT project. Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD ii Contents Executive Summary 1 1 Introduction 2 2 Network Programmability – Background and Solutions 3 2.1 First Steps in Network Programmability: Towards Control Centralisation 3 2.2 Control Plane Programmability 4 2.2.1 SDN Controllers 4 2.2.2 Southbound Interfaces 5 2.2.3 OpenFlow Protocol 6 2.2.4 Open-Source Control Plane Landscape 7 2.3 Data Plane Programmability 7 2.3.1 Data Plane Programming Models 8 2.4 Devices and Targets 9 2.4.1 Hardware-Based 9 2.4.2 Linux-Based Packet Processing Solutions 13 2.4.3 Software-Based Targets 15 2.5 Data Plane Programming Languages 16 2.5.1 P4 Language 16 2.5.2 Network Programming Language - NPL 17 2.5.3 C/C++ 18 2.5.4 Very High Speed Integrated Circuit (VHSIC) Hardware Description Language - VHDL 18 3 Network Programmability Use Cases and Examples 20 3.1 Network Programmability in 6G 20 3.2 AI/ML and Network Programmability 21 3.2.1 AI Applications 21 3.2.2 ML Applications 22 3.3 Network Programmability in Data Centres 23 3.4 Network Programmability for Network Function Virtualisation 24 4 Network Programmability in the R&E Community 25 4.1 Network Programmability Support for Network Monitoring 25 4.1.1 Flow Monitoring in Switch 25 4.1.2 High Performance Flow Monitoring Using Programmable NICs 25 4.1.3 In-Band Network Telemetry (INT) 25 4.2 Network Programmability Support for Network Security 26 4.2.1 eBPF/XDP Anti DDoS Application in SURF 26 Contents Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD iii 4.3 White Boxes Deployment in NRENs 26 4.4 CERN IPv6 Packet Marking 27 4.5 UFES - PolKA & MPolKA 27 5 RARE and GP4L 28 5.1 RARE – Router for Academia, Research and Education 28 5.1.1 The RARE Control Plane – freeRtr 28 5.1.2 Programming Language and Data Planes for RARE 28 5.1.3 RARE Use Cases 29 5.1.4 RARE Packaging 30 5.1.5 RARE Documentation 31 5.2 GP4L 31 5.2.1 RARE and GP4L Experiments 32 6 Conclusions 34 Glossary 35 References 38 Figures Figure 2.1: PISA data plane programming model - Image Source: [] 8 Figure 2.2: The Marvell Octeon 10 block diagram []. 12 Figure 2.3: DPDK kernel bypass compared to the standard Linux kernel stack [3] 14 Figure 2.4: Information flow in the P4 processing pipeline, Picture Source [] 17 Figure 2.5: NPL architecture model, Picture source [] 18 Figure 3.1: Overview of a P4 program for deploying an ML detection model to a P4-switch. 23 Figure 5.1: GP4L with RARE deployments [April 2025] 32 Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 1 Executive Summary This white paper provides a comprehensive overview of the current state of network programmability and programmable networks. It explores their historical evolution, technological background, current implementations and possible future directions and opportunities for research and experimentation, particularly within the GÉANT project. Network programmability has evolved significantly during the last decade, offering greater flexibility, efficiency, and customisation in packet processing. This evolution is traced in this document from the early days up to the development of distributed control plane and control plane programmability, data plane programmability, and data plane programmable models and languages. The document also covers some ongoing work on these technologies being carried out in research and education institutions and National Research and Education Networks (NRENs). Examples include the use of white boxes and P4-programmable hardware. Special emphasis is given to the Router for Academia, Research, and Education (RARE) open-source operating system and the Global Platform for Labs (GP4L) – both developed over a few iterations of the GÉANT project. This white paper also underscores the importance of continued research and experimentation in network programmability to adapt to evolving technological trends. Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 2 1 Introduction Network engineering has evolved over the last few decades, which have seen the development of several technologies and trends that have changed how communications are understood in our society. Each of these innovations has pushed towards better network performance and efficiency (lower delay and energy consumption, higher reliability and available bandwidth, etc.), adapting communications to the characteristics of different scenarios and use cases. In this context, one of the most studied concepts is network programmability, which encompasses the data and control plane and aims to provide complete customisation of packet processing throughout the network. Programmable networks have several advantages over traditional networks, such as greater flexibility and the capacity to create custom pipelines, process packets with specific requirements, or implement protocols that might not otherwise be provided by vendors. In view of the several benefits offered by programmable networks, academia, research and industry have focused efforts on the active development of network devices and software. Companies such as Barefoot, Intel, and Netronome have developed Application-Specific Integrated Circuits (ASICs) and Network Interface Cards (NICs) to be implemented in switches and Network Processing Units (NPUs). These, together with the associated proprietary software, have contributed to the expansion of programmable networks. On the other hand, several entities have been developing open-source alternatives, so that general-purpose equipment can be used to deploy programmable networks. In this context, the GÉANT project Network Development Work Package (WP6) Technology Task (Task 1) has developed an open-source multifunctional routing software platform called RARE (Router for Academia, Research and Education). RARE has been designed to provide a cost-effective, high-performance Network Operating System (NOS) that has the particularity of combining one control plane with multiple data planes. RARE can be deployed on several targets, including various P4-programmable hardware and software switches as well as DPDKand XDP-based targets. The flagship product of this project combines RARE and the Tofino chipset, merging the flexibility of open-source routing software with the terabits per second (Tbps) forwarding capability of the Tofino chip family. Due to recent changes brought in by the main network programming technology promoters and hardware manufacturers, such as Intel stopping the development of Tofino, the current roadmap for RARE and other similar alternatives and efforts remains uncertain. The objective of this white paper is to examine the state of the art and the current trends and initiatives in the development of network programmability within this context. Section 2 of the document provides a background and an overview of existing network programmability solutions, including control and data plane programmability, network programmability devices, targets, models and languages. Section 3 provides an insight into the adoption of network programmability examples and use cases. Examples from NRENs are provided in section 4. Special focus is given to RARE and the GP4L and their use cases (section 5). Finally, the white paper draws some main conclusions and highlights possible steps for the future of network programmability and RARE (section 6). Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 3 2 Network Programmability – Background and Solutions Over the past decade, network programmability has been extensively studied by both researchers [1] and manufacturers. Several initiatives have emerged in academia and industry that have advanced the technology to its current state in networking and communications [2] [3] [4]. The evolution of network programmability began with centralisation of control in network devices in the control and data plane. This in turn enabled programming of the control and data plane of network devices, and soon resulted in a proliferation of hardware-, Linuxand software-based solutions, programmability models and languages, all of which are described in more detail in the rest of this chapter. 2.1 First Steps in Network Programmability: Towards Control Centralisation Communication networks were traditionally based on commercial, off-the-shelf network devices, which were designed to provide specific services that are aligned with the requirements of user applications. These devices were customised by manufacturers to operate at high speeds and to accommodate a range of traffic types. Such traditional devices relied on distributed routing protocols that involved cooperation between network nodes to obtain a unified network view and apply the required routing policies. This cooperation required the implementation of sophisticated routing algorithms. This increased the convergence time and complexity for identifying an optimal routing. This is of particular importance in networks that are subject to constant changes. Moreover, although these devices were able to work at high speeds and support typical network traffic, in some cases they were not flexible enough to be adapted to specific scenarios. Users relied on software updates for the implementation of new functions, which – as they used proprietary and closed software – was subject to limitations due to the vendor interests or the development cycle of networking equipment manufacturers, among other reasons. Also, being proprietary, they were usually not fully open or could not be programmed by external contributors. Additionally, network researchers could not implement newly proposed protocols due to the lack of evaluation architectures or devices in such a vendor-locked environment and therefore could not experiment with novel networking mechanisms. Besides, depending on their priorities and roadmaps, networking equipment manufacturers can require long periods to design, implement, test, polish and commercially deploy new features – unless these happen to be their primary focus and interest, in which case development may be faster. In some cases, vendor development dynamics can also depend on the development cycle of chip vendors. Subsequently, during the 2000s, the concept of separation between the control and data planes began to gain traction, driven by the objective of simplifying networking platforms. These new devices were designed with a focus on hardware packet forwarding, rather than software forwarding. The control plane could subsequently be centralised and offloaded to computational hardware located remotely. This is the origin of Software-Defined Networking (SDN), which was formalised in 2008 with the definition of OpenFlow. OpenFlow was introduced as the standard protocol for centralising control and deploying networks formed by devices that simply forward packets according to a set of flow-based match-action rules. With OpenFlow, all the routing decisions were moved to the centralised controller, providing interfaces for programming custom control-plane applications that improved the flexibility of network solutions. Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 4 2.2 Control Plane Programmability Traditionally, the control and data planes have been tightly coupled in communication networks, meaning that network devices, such as routers and switches, manage both the control and forwarding functions internally. This traditional approach, though reliable, limits the flexibility and adaptability of network infrastructure, making it difficult to scale, innovate, or manage efficiently. With the rise of cloud computing and mobile applications, and the increasing demand for dynamic and scalable network environments, traditional network infrastructure faces limitations in meeting modern requirements. Control plane programmability emerged as a solution to decouple the control plane from the data plane, enabling centralised and programmable management of network resources. The main benefits of control plane programmability are: • Centralised control: routing and forwarding decisions are made by a centralised entity that has a unique and global view of the network’s topology and status. This prevents loops and other problems associated with distributed network control. Operators can manage the network as a whole rather than dealing with individual devices. They manage large, complex networks from a central point, reducing complexity and improving response times. This simplifies troubleshooting, traffic engineering, and security enforcement. • Flexibility: administrators can easily modify network policies, routing paths, and overall network behaviour in real time. • Scalability: as networks grow in complexity, programmable control planes can simplify management and reduce the risk of errors during configuration. Network configurations can be applied across hundreds or thousands of devices without manual intervention. Instead of manually configuring each network device, the control plane pushes configurations and policies across the network. • Automation: the northbound interface is defined to program the control plane. Automation tools and scripts can be used to perform routine tasks like network provisioning, traffic engineering, or fault management. Traffic conditions, security threats, or service requests can trigger real-time adjustments. This reduces operational costs and human error. • Security: with a global view of the network, more consistent and granular security policies can be enforced. • Innovation and experimentation: new services, protocols, or network optimisations can be tested and deployed with minimal impact on the existing infrastructure. The aforementioned characteristics serve as key motivators for the growing interest in control plane programmability within modern networks. Consequently, the following subsections will delineate the pivotal aspects of control plane programmability, encompassing the overall communication and management framework. This includes discussion of SDN controllers, southbound interfaces, and the OpenFlow protocol. 2.2.1 SDN Controllers Software-Defined Networking (SDN) is one of the most important concepts in control plane programmability. SDN facilitates the separation of the control plane from the data plane, giving rise to a more flexible and centralised network management model. The SDN controller, which resides in the control plane, is the centralised entity responsible for managing the control plane across the network. It has a global view of the network topology and can control the behaviour of network devices, such as switches and routers, through programmable interfaces. It oversees making routing decisions. It essentially decides how data packets should be forwarded based on network policies and conditions. Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 5 The main functions of an SDN controller include: • Centralised view: the SDN controller maintains a centralised view of the network’s topology, current state, and traffic conditions, allowing it to make informed routing decisions. • Policy Enforcement: network policies related to security, Quality of Service (QoS), and traffic engineering can be centrally enforced through the controller. • Resource Management: the controller optimises the use of network resources by allocating bandwidth, rerouting traffic in case of congestion or failure, and adjusting network paths based on changing conditions. • Programmability: the SDN controller enables network operators and applications to interact with the network infrastructure through Application Programming Interfaces (APIs). The northbound interface allows network operators to define applications that control the behaviour of the network. The southbound interface provides a mechanism to communicate with data plane devices and configure them. In addition, east/west-bound interfaces are defined to synchronise with other SDN controllers. The most popular SDN controllers include: • OpenDaylight [5]: An open-source SDN controller (Linux Foundation) that provides a modular platform that supports a variety of southbound protocols, including OpenFlow, NETCONF, and BGP. The latest version (Scandium-SR1) was released in November 2024. • ONOS (Open Network Operating System) [6]: ONOS is designed with a focus on scalability and reliability. It supports large-scale SDN deployments, particularly in service provider networks. It is oriented to production networks. The latest ONOS LTS version (X-Wing 2.7) was released in July 2021 and it has been three years since ONOS received its last update on GitHub’s official repository. TeraFlowSDN appears to be the replacement for ONOS. • Ryu [7]: an open-source SDN framework that provides a set of APIs to manage switches using protocols like OpenFlow. It provides great flexibility and compatibility thanks to the Python-based programming interface, which makes it suitable for research and experimentation. According to its official repository, it is not currently maintained. There is an alternative, os-ken [8], which provides the Ryu library tailored for OpenStack. • Cisco ACI (Application Centric Infrastructure) [9]: This commercial SDN controller is designed to provide automated management of both physical and virtual network environments. At the time of writing, it is still maintained by Cisco, which provides subscription-based access to different features. • TeraFlowSDN (TFS) [10] is an open-source, micro-service-based and carrier-grade SDN controller capable of integrating with current NFV and MEC frameworks. It was developed in the context of an H2020 project, and there is now an ETSI Software Development Group (SDG) dedicated to TFS. 2.2.2 Southbound Interfaces In traditional networks, control and data planes are tightly integrated within devices, but southbound interfaces are key in SDN architectures for decoupling these planes and enabling centralised control. Southbound interfaces serve as the communication channel between the SDN controller and the data plane devices, such as routers, switches or firewalls. These interfaces allow the controller to populate the forwarding tables of the data plane devices. Southbound interfaces define how an SDN controller communicates with data plane devices. They allow the controller to query the network topology, gather statistics, configure devices, and enforce policies. Southbound interfaces enable the SDN controller to dynamically modify how devices forward traffic, thereby enabling real-time adjustments to network conditions. By supporting multiple southbound protocols, SDN Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 6 controllers can interact with various types of devices from different vendors, reducing vendor lock-in and improving interoperability. Southbound interfaces also allow for granular control over packet handling, ensuring precise network traffic management and optimised performance. The most common southbound interfaces are: • OpenFlow [11]: This is the most well-known and widely used southbound protocol in SDN networks. It allows the controller to interact directly with the forwarding plane of network devices, specifying how packets should be handled. • NETCONF (Network Configuration Protocol) [12]: This is primarily used for configuration management and monitoring. It uses XML-based data to configure network devices. • BGP (Border Gateway Protocol) [13]: BGP can also be used as a southbound protocol, enabling controllers to make decisions on inter-domain routing. This means the SDN controller acts as a BGP speaker and communicates with the network devices using BGP messages. • OVSDB (Open vSwitch Database Management Protocol) [14]: OVSDB is used to manage and control Open vSwitch instances, a popular virtual switch for network virtualisation. 2.2.3 OpenFlow Protocol As previously stated, the OpenFlow protocol is the de facto standard for the implementation of the SDN southbound interface. It is a foundational element of SDN architectures and is widely considered the first standard interface for SDN. It facilitates communication between the SDN controller and the forwarding devices in the data plane. OpenFlow enables the SDN controller to program network switches by providing a set of forwarding or flow rules that define how traffic should be handled. The controller installs these flow rules in the switch’s flow table, allowing the switch to forward packets accordingly without needing further intervention from the controller unless conditions change. Each flow rule in the OpenFlow protocol consists of three main components: • Match Fields: Each flow rule represents a group of packets, also known as flow, which is identified by the match fields. In other words, it is the criteria for identifying traffic flows. The matching fields are based on packet headers such as source/destination IP addresses, port numbers, protocol type, etc. • Actions: Instructions for the data plane device on how to handle the packets that match the criteria, such as dropping, forwarding them to a specific port, or modifying packet headers. • Counters: Statistics on how many packets or bytes match a flow rule, allowing the controller to monitor network conditions. One of the main benefits of OpenFlow is that it abstracts control logic from the physical devices, which simplifies the overall network architecture and the procedures to manage and control it. OpenFlow also provides a standard interface that applies to different manufacturers, thus reducing vendor lock-in. OpenFlow is commonly used in data centres to optimise traffic flows, balance loads, and enable virtualisation. It can also be employed in Wide Area Networks (WANs) to ensure efficient traffic routing and management across multiple sites. OpenFlow is also used for enhancing the security of the network by implementing centralised security policies. The OpenFlow protocol has evolved through various versions, with each iteration introducing more complex features such as support for multiple flow tables, group tables for multipath routing, and enhanced match fields for more granular packet inspection. The latest version of OpenFlow is 1.5.1. Even though it was released in 2015, OpenFlow is still seen as a pivotal protocol in the technological background of network programmability, Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 13 more importantly, well-known programming paradigms such as VPP and DPDK are available, enabling integration with a complete ecosystem of applications. 2.4.1.6 White Boxes In the networking world, a “white box” typically refers to a generic, low-cost networking device from an original design manufacturer that can be tailored to specific requirements and offer an alternative to proprietary solutions. Manufacturers such as Edgecore, Delta, and Celestica are producing high-performance generic hardware capable of running various software stacks, including Software for Open Networking in the Cloud (SONiC) [54], Cumulus Linux [55], or proprietary systems such as RTBricks [56], IP infusion [57] or Arrcus [58]. This trend towards white-box networking is complemented by a disaggregated approach, where the network operating system (NOS) is chosen independently of the hardware. This approach is popular with large hyperscalers such as Google and Facebook, leading to the emergence of platforms such as Pica8 and Cumulus (now part of NVIDIA), which provide highly customisable networking software [59]. By adopting these disaggregated solutions, NRENs can tailor their networks to specific needs, driving innovation and efficiency in network management. In addition, this approach supports the integration of cutting-edge technologies and facilitates rapid adaptation to evolving network requirements, ensuring robust and scalable network infrastructures. It is likely that, with time, more solutions and platforms will emerge, and there are some examples of new collaborations in the area of P4 programmable devices being announced, such as between Oxide and Xsight Labs to build the next generation of P4-programmable networks on the Oxide Cloud Computer [60]. 2.4.2 Linux-Based Packet Processing Solutions There are two linux-based packet processing solutions – Data Plane Development Kit (DPDK) and extended Berkeley Packet Filter (eBPF) / eXpress Data Path (XDP). 2.4.2.1 Data Plane Development Kit – DPDK Traditionally, networking equipment provided by vendors such as Cisco, Ericsson, Huawei, Juniper, Nokia, and ZTE used specific ASICs to perform low-level data plane functions like packet processing. The main constraint for these ASICs was the long schedule for introducing new products, which was limited by the silicon development/debug cycles. In this context, DPDK [61] was created as a solution to perform efficient data plane functions using general-purpose CPUs. DPDK is a set of software libraries and drivers, running in user space, that accelerate packet-processing workloads running on all major CPU architectures. DPDK was created by Intel but now is housed as a project under the Linux Foundation. DPDK allows the use of general-purpose CPUs in high-performance environments, from enterprise data centres to public clouds and particularly in communication networks. To accelerate the processing of packets, DPDK allows incoming network packets to transition to user space with no overhead for memory copying, where they are rapidly processed without the expense of context switching between user space and kernel space. In other words, DPDK bypasses the Linux kernel, performing packet processing in user space to maximise networking performance. DPDK achieves this using a Poll-Mode Driver (PMD) running in user space that continually checks incoming packet queues to see if new data has arrived, achieving both high throughput and low latency. Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 14 Figure 2.3: DPDK kernel bypass compared to the standard Linux kernel stack [3] Since 2019, there has also been a surge in the adoption of kernel by-pass mechanisms. DPDK was very popular, however, this was a very low-level C library dedicated to developing hardware-accelerated packet forwarding by NIC chipsets and there was no high-level library available that would abstract DPDK C programming at that time. Vector Packet Processor – VPP [67], in combination with the Linux control plane plugin [68], are enabling DPDK hardware acceleration for all netlink-based control plane software. 2.4.2.2 Extended Berkeley Packet Filter (eBPF) / eXpress Data Path (XDP) eBPF [62] [63] is a Linux-based technology that allows programmers to run sandboxed programs in the operating system kernel. It is used to safely and efficiently extend the capabilities of the kernel without requiring changes to the kernel source code or needing to load kernel modules. Historically, the operating system has always been the ideal place to implement observability, security, and networking functionality due to its kernel’s privileged ability to oversee and control the entire system. At the same time, an operating system kernel is hard to evolve due to its central role and high requirement for stability and security. The rate of innovation at the operating system level has thus traditionally been lower compared to functionality implemented outside of it. XDP [64] provides a framework for BPF that enables high-performance programmable packet processing in the Linux kernel. It runs the eBPF program at the earliest possible point in the software, i.e., when the network driver receives the packet. This means the packet is intercepted before any expensive operations such as pushing the packet up the networking stack have taken place. Thus, the XDP BPF program is executed at the earliest point where it becomes available to the CPU for processing. In contrast to DPDK, XDP works in the Linux kernel, so it does not bypass the kernel to operate in the user space. Keeping the packet in the kernel space has several major advantages: • It can reuse all the kernel networking drivers, user space tooling, or even other available in-kernel infrastructure such as routing tables, sockets, etc. developed upstream in BPF helper calls. • It has the same security model as the rest of the kernel for accessing hardware. Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 15 • There is no need for crossing kernel/user space boundaries since the processed packet already resides in the kernel and can therefore flexibly forward packets into other in-kernel entities like namespaces used by containers or the kernel’s networking stack itself. This is particularly relevant in case of Meltdown and Spectre (security vulnerabilities recently found in Intel, AMD, Apple, and ARM processor chips), as minimising unnecessary transitions between kernel and user spaces can help mitigate performance overhead while ensuring security. • It is possible to handle packets by the regular Linux TCP/IP stack (part of the kernel) without having a separate TCP/IP stack in user space. • It allows for full programmability, keeping a stable application binary interface (ABI) with the same “never-break-user-space" guarantees as with the kernel. • It allows for atomically swapping programs during runtime without any network traffic interruption or even kernel/system reboot. • XDP allows for flexible structuring of workloads integrated into the kernel. For example, it can operate in “busy polling” or “interrupt-driven” mode. Explicitly dedicating CPUs to XDP is not required. There are no specific hardware requirements, and it does not rely on huge pages. • It supports most major 10G or higher networking drivers. 2.4.3 Software-Based Targets Software-based targets are packet-forwarding programs that run on a standard CPU. Software-based targets provide an abstraction layer that emulates the behaviour of a programmable data plane on a standard Linuxbased host. 2.4.3.1 Behavioral Model Version 2 (bmv2) Behavioral model version 2 (bmv2) [65] is the most widely known software-based target. It implements Portable Switch Architecture (PSA) and v1model architectures to run P4 programs. While bmv2 is easy to use and readily available, due to its software-based nature this is mainly used for training, demonstrations, and development rather than for production purposes. 2.4.3.2 Intel P4 Studio Software Development Environment (SDE) Intel P4 Studio Software Development Environment (SDE), often referred to as Open P4 Studio [66] is a set of packages that could be used to develop software for Intel’s family of programmable Ethernet Switches. This open-source version includes Barefoot Runtime Interface (BRI) with the gRPC-based protocol, called BF Runtime, and allows development using the bf_switchd virtual model. However, P4Insight GUI for visualising the hardware resources used by P4 programs, Board Support Package (BSP) and ASIC-specific drivers are not included in the open-source bundle, as explained in [67]. 2.4.3.3 Switch Abstraction Interface (SAI) Switch Abstraction Interface (SAI) is a standardised Application Programming Interface (API) which provides the opportunity to use a consistent and simple programming interface to develop diverse and innovative functionalities on various hardware platforms. Although it is not a target to deploy data plane programs, as they are bmv2 of the bf_switchd, SAI provides an agnostic and vendor-independent way of controlling switch entities like ASICs, NPUs or software switches. SAI enables open networking as it allows the use of the same application stack on different hardware platforms irrespective of vendors, executing true software-hardware decoupling. Several organisations implemented SAI for their solutions, such as Cisco in its Silicon One home-made ASIC, or Intel, who implemented SAI in 2019 as part of their Intel P4 Studio. Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 16 2.5 Data Plane Programming Languages In data plane programmability, data plane programming languages play a crucial role in defining and controlling the behaviour of network devices. This subsection provides an in-depth view of these languages as they have been developed throughout the years, exploring their unique features, advantages, and specific characteristics. 2.5.1 P4 Language The P4 programming language [68] was created to provide a high-level, protocol-independent way to define the behaviour of packet-processing devices. It allows the programmers to describe data plane algorithms using a combination of constructs that provide support for the typical data-plane-specific functionality (e.g., counters, meters, checksum calculations, etc.). The first version of the P4 language (P414) was released in 2014. In 2016, the next version, P416, was introduced to address several P414 limitations. The major contribution of the P416 standard is that it supports multiple different targets and pipeline architectures. This is achieved by separating the core language from the specifics of a given architecture thus making it architecture-agnostic. The structure, capabilities and interfaces of a specific pipeline are encapsulated into an architecture description, while the architectureor target-specific functions are accessible through an architecture library, typically provided by the target vendor. The remainder of this paper will focus on P416 and any further reference to the P4 language is implicitly intended to refer to that version. P4 programs are supplied by the user and are implemented for a particular P4 architecture model. They define algorithms that will be executed by the P4-programmable components and their interaction with those implemented in the fixed-function logic. The composition of the P4 programs and the fixed-function logic constitute the full data plane algorithm. P4 compilers are also provided by the manufacturers, they translate P4 programs into target-specific code, which is loaded and executed by the P4 target. The P4 compiler generates a data plane API that can be used by a usersupplied control plane to manage the runtime behaviour of the P4 target. For instance, the control plane will use this API to fill the data plane tables that are defined in the P4 program. Figure 3.1 taken from [69] depicts the information flow in a P4 processing pipeline, which is divided into different blocks that perform operations to process the packets. The packet headers and metadata are used to pass the information between them, therefore representing a uniform interface. The parser splits up the received packet into individual headers and the remaining payload. Intrinsic metadata from the ingress block, e.g., the ingress port number or the ingress timestamp, is often provided by the hardware and can be made available for further processing. Many targets allow the user metadata to be initialised in the parser as well. The headers and metadata are then passed to the match-action pipeline that consists of one or more matchaction units. The remaining payload travels separately and cannot be directly affected by the match-action pipeline processing. While traversing the individual match-action pipeline units, the headers can be added, modified, or removed and additional metadata can be generated. The deparser reassembles the packet by emitting the specified headers followed by the original packet payload. Packet output is configured with intrinsic metadata that includes information such as a drop flag, desired egress port, queue number, etc. Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 17 Figure 2.4: Information flow in the P4 processing pipeline, Picture Source [70] 2.5.2 Network Programming Language - NPL Network Programming Language (NPL) [71] is an open, high-level language that also addresses the requirements of efficiently programming data planes. Like P4, NPL expresses network behaviour using constructs that take advantage of advanced features of the underlying programmable hardware. NPL building blocks, presented in Figure 3.2 from [72], range from data types that allow the specification of individual control signals to high-level constructs that allow interfacing with complex hardware blocks. NPL includes the following core abstractions: • Data Types: specifies the basic building blocks of any object field. • Parser: specifies the allowed headers within received packets and extracts those headers from the packets. • Logical Bus: specifies the fields and overlays of a logical bus. The logical bus connects various other NPL objects. • Match Action (MA) table: describes a particular table with the associated keys and actions. • Editor: provides the ability to add, remove, or replace a header. • Special Function: a mechanism to call a particular hardware function that may be treated as intellectual property. This provides a structured mechanism to define the interface into these functions without revealing the contents of the function. • Function: provides programmable decision logic without the overhead of a table. For example, it can be used to resolve the results of multiple Match Actions or to resolve the Match Action key selection. • Strength Resolution: a mechanism to resolve multiple tables updating the same object in parallel. • Packet Drop, Packet Trace, and Packet Count: built-in functions to drop, trace, and count packets. • Create Checksum and Update Packet Length: built-in functions to create checksum and update packet lengths. • Metadata for MA and Parser: data not created in the NPL yet still exists at runtime with the packet and can be used by the NPL. Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 18 The NPL language is not bound to any specific hardware architecture, so it can be implemented on multiple hardware platforms such as programmable ASICs, programmable NICs, FPGAs, and software switches. However, certain language constructs are intended to optimise the use of specific hardware features on certain targets. Like any high-level programming language, NPL requires a set of compilers and associated tools to map the programs written to target hardware objects. The front-end compiler is responsible for checking the syntax and semantics of the user-written program in the NPL language generating an Intermediate Representation (IR). The back-end compiler is responsible for mapping these intermediate representations into specific hardware objects. It also generates an API that the control plane uses to manage the behaviour of the switch. Figure 2.5: NPL architecture model, Picture source [73] 2.5.3 C/C++ C++ [ 74 ] is a powerful language choice for network programming and has been extensively used for programmable network devices such as smart NICs, FPGAs, and NPUs. One of the main advantages of this programming language is its focus on high-performance environments. It is heavily used in performanceoriented applications thanks to the direct control it provides over memory management, essential for real-time applications and latency-sensitive traffic forwarding. In this context, several libraries and frameworks use C++ for network programmability, such as: • DPDK: an open-source set of libraries and drivers for high-performance packet processing that supports low-latency applications. • eBPF/XDP: technology that allows the development of programs that run sandboxed in the kernel. XDP extends it allowing fast packet processing at the NIC level. For instance, some devices like Netronome Agilio SmarNICs [75] use either eBPF or C language to efficiently program the data plane processing pipelines, providing full control over memory. 2.5.4 Very High Speed Integrated Circuit (VHSIC) Hardware Description Language - VHDL VHDL, defined in [76], is very often used to design packet processing functionalities for FPGA cards, as it provides a way to define custom logic circuits that process network packets at various protocol layers. The flexibility of VHDL allows for designing logic that processes headers, analyses payloads, and routes or discards packets based on content. All these tasks are performed in hardware, ensuring low latency and high-speed operation. In a typical packet processing application, FPGAs receive incoming data packets, which are streamed in as a series of bits or bytes. VHDL modules then define a series of processing stages to handle different packet Network Programmability – Background and Solutions Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 19 components, such as headers and payloads. Each module within this flow can operate concurrently within the FPGA, leveraging its parallel processing capability. FPGAs can process multiple packets simultaneously or different portions of a single packet at once. Development in VHDL is challenging and requires in-depth knowledge of both digital circuit design and network protocols. Moreover, FPGAs have finite resources, and implementing complex packet processing functions may require careful optimisation. Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 20 3 Network Programmability Use Cases and Examples The last several years have seen important changes in networking architecture, hardware and software, and solutions. Organisations have by and large abandoned vertical integration and adopted a strategy that consists in ensuring a high level of independence from specific hardware vendors. Google has undertaken work on P4based Automated Reasoning [77]. Meta has abandoned SDK-based development and embraced [78] Switch Abstraction Interface (SAI), while Alibaba has decided to use SONiC [79] and is spearheading a routing working group to ensure that SONIC does not remain limited to data centre architecture but is also deployed in a MAN and WAN context. These developments are evidence that there are numerous areas where network programmability can be of help and use. This chapter presents some exploratory use cases, such as the possible advantages network programmability can provide for future 6G networks and support of artificial intelligence (AI) and machine learning (ML). More practical examples are also provided, such as the use of network programmable solutions in data centres, at network access level or flow monitoring. Special emphasis is given to RARE – Router for Academia, Research and Education, its deployments on the Global Platform for Labs (GP4L), and numerous use cases. These scenarios focus on the use of network programmability as a tool, to demonstrate network advancements through network automation and development and supporting the standardisation of new network protocols. 3.1 Network Programmability in 6G New generations of mobile communication systems typically also set the trend for the upcoming technologies and procedures that are deployed in fixed communication networks. For example, the 5G standard natively integrates technologies such as NFV and SDN, which imply the use of network virtualisation and network programmability in 5G networks. Although 5G technology is not yet fully operational, research and academia are already shaping the sixth generation of communications (6G). The key pillars of 6G technology are currently being defined based on emerging trends and research. These pillars will underpin the future development of 6G, enabling it to surpass 5G in terms of capability and innovation. Several sources in the industry have identified which of these pillars are primary along with the technological enablers required to achieve them, such as Native Artificial Intelligence (AI), Extreme Connectivity, and Native Trustworthiness and Security [80] [81]. Deep network programmability, which refers to programming the network both vertically (control and data plane) and horizontally (end-to-end from the radio edge to the core network), is expected to play a relevant role in 6G networks. In this way, 6G will enable a more flexible, dynamic, and efficient management of both the control and data planes to support extreme performance requirements and service-specific operations. This will allow networks to rapidly adapt to evolving demands and support advanced use cases, such as AI-driven automation, intelligent resource allocation, and ultra-reliable low-latency communication (URLLC). Programmable control planes contribute to 6G through: • Dynamic Network Management: In 6G, the programmable control plane will allow operators to adjust network configurations in real time based on specific application requirements or environmental conditions. This includes adjusting network policies, optimising routing paths, and dynamically allocating resources such as bandwidth or power based on the real-time needs of applications like autonomous vehicles, smart cities, or telemedicine. Network Programmability Use Cases and Examples Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 21 • Network Slicing: A key feature of 6G will be enhanced network slicing, where a single physical network can be partitioned into multiple virtual networks, each optimised for a specific service or application. Programmable control planes are crucial for this, enabling the definition and modification of slices based on different parameters such as latency, throughput, and security. • AI-Enhanced Control: AI will be integrated into the control plane to enable predictive and selfoptimising networks. By leveraging programmability, AI systems can dynamically reconfigure networks to optimise performance, energy efficiency, or cost. This will help 6G networks become more autonomous and responsive to real-time demands [82] [83]. Programmable data planes contribute to 6G through: • Customised Data Handling: Programmable data planes enable more sophisticated packet processing and flow management. For example, data can be processed in-network, reducing latency for critical applications. This is especially relevant for use cases such as immersive XR (Extended Reality) or tactile internet, where real-time data processing is crucial. • Offloading Tasks: A programmable data plane can offload computational tasks from end devices, allowing edge computing nodes to handle data processing directly within the network. This reduces the need for raw data transmission back to central servers, optimising bandwidth use and improving latency [84]. Additionally, the expansion of switches and devices with Data Processing Units fosters the acceleration of computational functions in network equipment. As an example, devices that combine programmable data plane technologies and DPUs to increase the variety of tasks that can be offloaded to the data plane are gaining traction [85], as described in the previous section. 6G will rely heavily on edge computing to meet latency and bandwidth requirements for next-generation applications. Programmable control and data planes allow processing to be offloaded to edge nodes. This distributed intelligence across the network ensures that performance-critical tasks are handled with minimal delay. Programmability will also be key in enhancing the security and privacy of 6G networks. It allows for the real-time implementation of security protocols, detection of malicious traffic, and isolation of affected network slices or devices. Network programmability in 6G allows network operators to quickly adapt to new service requirements and adjust their networks without needing major hardware modifications. It also enables networks to handle a wide range of services and devices, scaling resources dynamically as user demands grow. 3.2 AI/ML and Network Programmability In recent years, various data plane programming languages (e.g. P4, eBPF/XDP, and DPDK) have been proposed to accelerate traditional networking operations. Researchers of both academic and commercial environments have widely investigated the application of the aforementioned solutions within their infrastructures. However, none of these languages have been widely adopted as a standard solution in modern networking environments. Data plane programming is not straightforward and introduces a significant learning curve for developers. Learning novel instruction sets is usually expected, whereas developers are required to adhere to the restrictions imposed by the data plane programming languages; these restrictions (e.g. the lack of direct support for loops) safeguard the security of the systems utilised as the program targets. Therefore, the prevalence of such techniques in data centres and core networks is typically hindered by the total effort required by researchers to get accustomed to the intricacies of data plane programming. 3.2.1 AI Applications The advent of Generative Artificial Intelligence (AI) provides novel opportunities to facilitate development in data plane programming languages. Specifically, Large Language Models (LLMs), such as ChatGPT, have been Network Programmability Use Cases and Examples Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 22 proposed as suitable candidates for generating data plane software. For example, the solution proposed in [86] leverages ChatGPT to produce valid data plane programs based on instructions provided in natural language and generate programs in Lucid (i.e. a P4 refinement) of varying complexity by selecting the appropriate ChatGPT prompts and providing the language syntax rules. Another important aspect of data plane programming involves assessing the quality of developed software. Specifically, programs may include bugs and/or important security vulnerabilities that may be exploited by malicious Internet users to compromise critical infrastructures. Various solutions have been proposed to address the aforementioned issue. An example of this is HackP4 [87], a tool that analyses P4 programs both statically and dynamically to discover potential security vulnerabilities. 3.2.2 ML Applications For network providers, as well as security organisations and intelligence services, the use of probes to detect network anomalies is crucial. In addition to identifying anomalies from normal traffic patterns, it is useful to detect known threat patterns. Known threats are traditionally detected using rule-based approaches like Snort [88], which is a commonly open-source Intrusion Detection (IDS) and Prevention System (IPS), where the “rule” book is regularly updated. With the relevant training sets, it is also possible to convert this rule-based approach into a statistical ML-based approach. Unknown threats and malicious patterns including zero-day attack patterns cannot normally be detected using rule-based approaches, yet they can be indicated based on variations from the normal data pattern. ML, in contrast to rule-based approaches, is quite suitable for such anomaly detection. High-performance P4-programmable switches, such as those using Tofino chips, can be utilised for probes if ML is integrated with the data plane. This integration allows for the detection of network intrusions at line-rate, as the traffic is processed directly within the switch, eliminating the need to offload replicated traffic to a dedicated endpoint server for ML analysis. However, implementing more advanced or complex detection models for innetwork traffic analysis and anomaly detection increases hardware resource demands, which can affect the performance of the network devices. Artificial neural networks, particularly autoencoders, are well-suited for unsupervised learning tasks. There are existing frameworks that can map a single autoencoder to the match-action pipeline of a P4-programmable switch, enabling these switches to handle the necessary ML tasks. Since zero-day attacks are inherently unknown beforehand, unsupervised learning is often preferred. Unsupervised learning tasks typically include clustering, density estimation, or anomaly detection. In anomaly detection, the model identifies data values that deviate significantly from other observations, which may indicate attack behaviour. Anomaly detection is similar to density estimation, where the goal is to determine the likelihood of future observations based on past data, as an unlikely set of observed values can be considered an anomaly. When an ML model has been trained using a suitable dataset, which is far from trivial, it is deployed into production on a P4-programmable switch using one of the available mapping frameworks like Planter and/or Mousika. For example, Planter has the “Common P4” module for generating use case P4 code for deploying an ML model. Training features, such as TCP source and destination ports, are extracted through the ingress parser. Planter links these features with feature fields in the "user-defined" metadata from where they can be used as keys in the corresponding feature M/A tables of the mapped ML model. Figure 5.3 shows the linkage between the normal P4 parser flow and the mapped ML model. RARE and GP4L Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 29 5.1.2.1 RARE/freeRtr and DPDK, XDP As a part of its goal to explore different platforms for network programmability, the RARE project team looked for affordable data planes other than P4-based ones. Linux kernel-bypass mechanisms such as DPDK and XDP are examples of affordable and ubiquitous technology with the potential to reduce the digital divide. At first, it was planned to use P4ELTE/T4P4S software to translate RARE P4 programs to DPDK primitives. However, this solution was abandoned when some critical bugs were encountered, so it was decided as an alternative to create a layer that emulated P4 RARE Match Action Unit program behaviour. Instead of yielding P4 primitives, the layer would yield wrapper primitives from the packet forwarding library such as DPDK, XDP and libpcap functions. 5.1.2.2 Unexplored Data Planes (Spectrum, XGS, DNX, Teralynx, FPGA) The next target that was explored was switchdev, which allows a standard Linux to use a specific driver model to integrate networking hardware into the Linux server environment [109]. Such a driver would then allow the Linux kernel to expose hardware networking ports as standard Linux interfaces. For the team, using switchdev would have opened the door to Mellanox/NVIDIA Spectrum ASIC hardware offload capability for freeRtr. The use cases in focus were related to MPLS, however, this work was abandoned due to some limitations of switchdev that were recognised at the time. Several initiatives to adapt the RARE P4 code to some platforms were closed down due to limited support and documentation from vendors and/or hardware and licensing availability, such as those involving Broadcom NPL running on top of the XGS & DNX ASIC families, Marvell Teralynx, Prestera and FPGAs. 5.1.3 RARE Use Cases From its beginnings, the intention of the RARE team was to create software to be run in a production environment that is functional, stable and reliable. The use cases in scope were those that are typical for national research and education networks as well as for small institutions such as schools and campuses, taking also into consideration those affected by low-income and the digital divide. 5.1.3.1 RARE for Data Center Interconnect (DCI) Internet RARE/freeRtr provides backend connectivity via MPLS and BGP labelled unicast to the Regional Computing Mesocenter in the north-east of France managed by CRIANN [110], which also runs the Normandy Regional Network. Initially, it was planned to use RARE/freeRtr on Wedge100BF-32 but, due to Intel announcing that it was dropping Tofino support, CRIANN decided to test and use RARE/freeRtr with DPDK. This connectivity is realised as an overlay on top of the RENATER core backbone network and seamlessly connects other mesocenters in Brittany in the far western part of France and the Lorraine region in the far east of the country. 5.1.3.2 RARE as an Open Source Anti-DDoS Solution The relevance and criticality of DDoS continue to be on the rise due to increased DDoS frequency and DDoS traffic rates reaching another level of magnitude (3,8 Tbps). This means that today's increased requirements for anti-DDoS measures are typically only met by expensive, commercial software products that are often only suited to company network traffic profiles and do not target heterogeneous, open NREN network traffic. This is why, in the context of the NREN/GÉANT community, open-source software products for anti-DDoS solutions (DDoS detection and mitigation), namely NeMo [111] and Firewall-on-Demand (FoD) [112], which complement each other, are actively being developed and operated. In line with the scope and vision of RARE/freeRtr, therefore, the team conducted investigations and tests on how to most efficiently combine RARE/freeRtr and these two GÉANT Anti-DDoS software products. The aim was to make these solutions usable with RARE/freeRtr in particular and easier to use for NRENs and other research RARE and GP4L Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 30 organisations in general. These efforts were successful and RARE/freerRtr can now be leveraged to yield autoinstallable, integrated demonstration and testing container solutions for both products. In the case of FoD, this was used as a basis for a virtual anti-DDoS demonstration [113] combining RARE/freeRtr, FoD and containerlab [114]. 5.1.3.3 RARE 5G UPF Implementation 5G technology is designed for heterogeneous scenarios, improving QoS and performance where huge numbers of users are connected, or high data rates are required. 5G is also designed for private networks, also known as Non-Public Networks (NPN). This technology helps private small-to-large corporations to deploy and manage their own networks, as they currently do with other standards like IEEE 802.11, but with noticeable improvements in QoS and performance. However, a significant drawback of 5G remains the dependency on vendor-specific equipment, which forces network administrators to stick to specific and usually expensive hardware devices. The GÉANT project’s WP6 Task 1 group has proposed the implementation of a 5G User Plane Function (UPF) in RARE/freertr, an open-source multifunctional router. The UPF routes user traffic between the Radio Access Network (RAN) and external networks, enhancing performance and giving network operators full control over user traffic. This approach separates the UPF from the 5G core implementation and leverages general-purpose hardware, eliminating the need for expensive and specific equipment. The proposal aims to serve as a baseline for deploying a more complex entity that could provide additional features defined in the 3GPP architecture. Future work could involve deploying several UPFs to leverage network slicing and provide appropriate QoS for different communications. Such work could be particularly relevant towards promoting open-source developments and reducing dependency on vendor-specific hardware. 5.1.3.4 RARE/freeRtr Network Management Innovation The programmable RARE/freeRtr platform can be used for network protocol development. However, RARE/freeRtr programmability is not restricted to pure control plane functionality development and the RARE team realised that, having the possibility to run multiple IGPs or BGP, they can provide network operators with a convenient way to monitor RARE/freeRtr nodes. In this context: • A Prometheus agent was created powered by a sensor concept. In a nutshell, a sensor can be seen as a CLI parser that is able to return key/value pairs as metrics ready to be scraped by a Prometheus server. • Streaming telemetry was also implemented. Coupled with InfluxDb and Telegraf in nmaas, the network operator can receive granular information from the network element. • BGP-LS was also implemented so that a northbound server can retrieve IGP topology information from an external domain. Various tests have been undertaken with HEAnet and GP4L. • A set of RARE/freeRtr Grafana dashboards have been implemented to provide a full suite of network monitoring dashboards [64]. • An innovative alarm system that monitors IGP topology was also developed using icinga2 and Nagios NRPE transport. This was presented during the 17th SIG-NOC in Paris [115]. 5.1.4 RARE Packaging During the initial phase of the project, creating a P4 environment with bmv2 was an hour-long compilation process. It then became obvious that creating packages would help project team members to quickly start P4 development and the team has now started to prepare RARE software packages for different platforms. RARE and GP4L Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 31 P4 and RARE/freeRtr Ubuntu and Debian packages were the first to be created. These packages helped the RARE and GP4L project participants to effectively start P4 development but were not popular with the P4 community outside of the RARE project as they were not official p4lang packages. External developers were reluctant to install non-certified packages signed by an unknown organisation. In addition, not having a close interaction with the p4.org project made maintenance of the packages extremely difficult as it was not possible to anticipate any dependency changes. Nevertheless, these packages contributed to the elaboration of a RARE/freeRtr ONIE image via a Jenkins CI/CD pipeline. Additionally, the Nix package manager and language were used to create Nix SDE packages, which were also officially accepted by Intel. All the Nix packages can be integrated into an ONIE image ready to be installed in one line. Nix’s inherent properties make sure that the installation is completely reproducible. The time to deploy a P4 node in GP4L was reduced from a few hours, sometimes days, to about five minutes in a predictable way. 5.1.5 RARE Documentation More information and documentation on RARE are available at [116]. 5.2 GP4L During RARE/freeRtr code development it was necessary to test the code in a representative environment. For this purpose, the GÉANT project first deployed four P4 nodes in Amsterdam, Frankfurt, Budapest and Poznan, followed a few years later by five nodes in Geneva. This infrastructure, which is maintained and operated by the Network Development work package of the GÉANT project, was initially meant to be used to test the code developed by the RARE team. However, unexpectedly the RARE team received multiple requests from research organisations wanting to connect their P4 switch to this core infrastructure in Europe, thus leading to the creation of the GÉANT P4 lab, also known as GP4L. Strengthened by this expansion of its European footprint, GP4L also began to attract the attention of research organisations from other countries, such as the USA, Brazil, Japan and Korea. This eventually led to the GÉANT P4 Lab’s expanding into what became the Global P4 lab, a worldwide networking platform available for researchers to experiment with various networking ideas. The map in Figure 4.1 shows the locations at which nodes with RARE deployments are in place (with over 30 nodes being deployed overall) at the time of writing. RARE and GP4L Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 32 Figure 5.1: GP4L with RARE deployments [April 2025] Today, GP4L is an experimental infrastructure distributed across the globe which is mainly dedicated to (i) testing and validating code developed within the RARE project, (ii) enabling researchers to develop applications based on programmable data planes using the GP4L platform, and (iii) supporting geographically distributed networking experiments. 5.2.1 RARE and GP4L Experiments Since their origins, RARE and GP4L have been relied on by the R&E community to enable evaluation and testing of network programmability concepts and solutions. Programmable switches connected in the Global P4 Lab - Global platform for Labs - with or without the RARE/freeRtr software stack, continue to be used by network developers, engineers and researchers in R&E organisations. The following sections provide some examples of how RARE and GP4L have been used by the community to test and validate different network technologies and solutions using the programmable network software and platform. 5.2.1.1 RARE and GP4L SuperComputing Network Research Exhibitions Network Research Exhibitions that take place on a yearly basis during the SuperComputing (SC) conference have provided a good opportunity for project demonstrations, such as: • “Programmable Networking with P4, GEANT RARE/freeRtr and SONIC/PINS”, SC22 [117] • “Global P4 Lab”, SC23 [118] • “PolKA routing approach to support traffic engineering for data-intensive science”, SC23 [119] • “PolKA routing approach to support traffic steering for data-intensive science”, SC24 [120] Each of these presented examples where GP4L has been used to test software solutions developed and deployed in the RARE operating system and then heavily tested on the global P4-based platform. RARE and GP4L Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 33 5.2.1.2 Standardisation Activities and Collaboration with Vendors RARE/freeRtr has been used and developed further to explore and support development of new IETF drafts and protocols. In some cases, further experiments have followed using the GP4L platform for deeper validation and testing. Some examples include: • AMT & Unicast 2 Multicast implementation – The RARE/freeRtr project implemented two complementary components jointly with Juniper: Automatic Multicast Tunnelling or AMT, and a Unicast to Multicast server. The basic idea behind AMT is to provide a mechanism for a client host to receive traffic of interest via a tunnel laid down on top of a non-multicast network with a multicastaware gateway called AMT. The unicast to multicast server that was created and implemented in RARE/freeRtr is a component that converts a unicast traffic stream to a multicast stream. • TreeDN - By combining the two components of the AMT with a multicast network, a content distribution tree can be created, as described in detail in RFC 9706 – TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to Mass Audiences. This document also explicitly mentions RARE: “The RARE network is a global testbed interconnecting several National Research and Education Networks (NRENs) via routers running BIER. AMT relays are deployed to deliver multicast traffic from sources on the RARE network to receivers on unicast-only networks across the Internet. Details of the RARE network are described in [BIER-AMT-Deployment].” • EANTC MPLS BGP-CT interoperability – The RARE/freeRtr team also contributed to the standardisation effort for BGP-CT in [57] draft-ietf-idr-bgp-ct-35 - BGP Classful Transport Planes and draft-ietf-idr-bgp-car-11 - BGP Color-Aware Routing (CAR) and conducted practical BGP-CT interworking with Juniper during EANTC’s multi-vendor MPLS and SDN interoperability test event. • The RARE/freeRtr team implemented the Bit Index Explicit Replication (BIER) protocol [121] on the BMv2, Tofino and DPDK data plane., This was presented at IETF 110 as part of the BIER session. The RARE/freeRtr team participated in an NVIDIA hackathon in March 2022, finishing in 2nd place. The abstract of the hackathon from NVIDIA’s website [55] reads: “FreeRTR Router is a Swiss army knife meant to be used as a primary router but can also be used as a specific appliance. The team evaluated accelerated DPDK and DOCA FLOW and enabled the routing functionality with multiple routing protocols on the DPU leveraging the large and programmable flow tables. As part of their planned innovation, the team also evaluated added services by linking DOCA libraries to provide additional functionality including Firewall, RegEx scanning, MACsec encryption, and DPI engine at line rate. This allowed Team Rare to create one control plane to rule all data planes.” Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 34 6 Conclusions Over the last decade, interest in network programmability has grown both within the commercial and vendor environment and the R&E community, and a wide range of such products are now on offer. These include hardware platforms of devices, Application-Specific Integrated Circuits, Network Interface Cards and Network Processing Units, software solutions for operating systems, development environments, languages and models applied to different scenarios and use cases. This document has provided an overview of all these elements and examined in detail both the completed and ongoing activities taking place in these areas in the research and education community. In particular, the Router for Academia, Research and Education - RARE - operating system and its deployment on the Global Platform for Labs - GP4L are spotlighted as ongoing activities of the Network Development work package of the GÉANT project. The history, development endeavours and reasoning behind them are discussed and illustrated through their operational, production or production-grade use cases. In parallel with its ongoing work, the RARE team is continuously exploring and evaluating possible directions for future work. The team’s direction of work is usually influenced by changes in the market, as new control plane and data plane hardware and software solutions, as well as new programming languages and models become available. The activities of NRENs in Europe and globally as well as the team members’ areas of knowledge and interest also have a bearing on which areas of work are considered for future development. Presently these include but are not limited to: • Using XDP to develop custom BGP extensions and enable efficient network traffic filtering based on fine-grained attack signatures [8] derived from the packet headers and payload. Unlike hardware data planes (e.g. P4), XDP facilitates the adoption of novel experimental features across organisations with diverse network devices. XDP programs mainly depend on device drivers, thus can run on different platforms with minimum software modifications. • Employing HackP4 or similar toolsets to verify the safety of the P4 programs that have already been developed. Since the RARE platform supports various data planes, the HackP4 toolset principles could be extended and applied to the vulnerability assessment of eBPF/XDP and DPDK programs. • Employing LLMs, specifically ChatGPT, to automatically generate P4 or eBPF/XDP code. Such code could address various interesting use cases: (1) DDoS attack detection and mitigation, (2) load balancing, and (3) traffic engineering. The examples presented in this paper highlight how network engineering today relies heavily on network programmability, with more and more solutions from both vendors and network operators aiming to simplify and speed up its use, thus helping further research and development of network infrastructure and services. Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 35 Glossary A ABI Application binary interface AI Artificial Intelligence ALU Arithmetic Logic Unit API Application Programming Interface ASIC Application-Specific Integrated Circuit B bmv2 Behavioral model version 2 BRI Barefoot Runtime Interface BSP Board Support Package C CDN Content Delivery Network CPU Central Processing Unit D DCI Data Center Interconnect DCN Data Centre Network DDoS Distributed Denial of Service DPDK Data Plane Development Kit DPP Data Plane Programmability DPU Data Processing Unit E eBPF extended Berkeley Packet Filter EoL End of Life F FBOSS Facebook Open Switching System FoD Firewall-on-Demand FPGA Field-Programmable Gate Array G GIX Global Internet Exchange GN4-3 GÉANT Network 4 Phase 3, a project part-funded by the EC’s Horizon 2020 programme under Specific Grant Agreement No. 856726 GN5-1 GÉANT Network 5, Phase 1, a project funded by the European Union’s Horizon Europe research and innovation programme under Grant Agreement No. 101100680 and one of the projects implementing the actions defined in the GN5-FPA Glossary Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 36 GN5-2 GÉANT Network 5, Phase 2, a project funded by the European Union’s Horizon Europe research and innovation programme under Grant Agreement No. 101194278 and one of the projects implementing the actions defined in the GN5-FPA GP4L Global Platform for Labs GREN Global Research and Education Network H HFA History-based Finite Automaton I IDS Intrusion Detection System INT In-band network telemetry IPDK Infrastructure Programmer Development Kit IPS Intrusion Prevention System IR Intermediate Representation L LLM Large Language Models M MA Match Action MAT Match-Action Table ML Machine Learning N NeMo Network Monitoring NFV Network Function Virtualisation NIC Network Interface Card NOS Network Operating System NPL Network Programming Language NPN Non-Public Networks NPU Network Processing Unit NREN National Research and Education Network O OCP Open Compute Project P PISA Protocol-Independent Switch Architecture PMD Poll-Mode Driver PSA Portable Switch Architecture Q QoS Quality of Service R RAN Radio Access Network Glossary Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 37 RARE Router for Academia, Research, and Education S SAI Switch Abstraction Interface SDE Software Development Environment SDN Software-Defined Networking SIG-NOC Special Interest Group – Network Operations Centres SONiC Software for Open Networking in the Cloud SRAM Static Random-Access Memory STP Spanning Tree Protocol SVE2 Scalable Vector Extension V2 T Tbps Terabits per second TCAM Ternary Content-Addressable Memory U UFES Universidade Federal do Espírito Santo, Brasil UPF User Plane Function URLLC Ultra-reliable low-latency communication V VHSIC 2.5.4 Very High Speed Integrated Circuit VNF Virtual Network Functions VPP Vector Packet Processing W WAN Wide Area Network X XDP eXpress Data Path XR Extended Reality Programmable Networks: Current State and Trends Document ID: GN5-2-25-111DCD 38 References [1] Marinos DImolianis (NTUA), David Schmitz (LRZ), Henrik Wessing (DTU), Pavle Vuletić (UoB), White Paper: High-Performance Flow Monitoring Using Programmable Network Interface Cards, Grant Agreement No.: 856726, GN4-3-22-N3R07E WP6 Task 3 https://resources.geant.org/wpcontent/uploads/2023/02/GN4-3_White-Paper_High-Performance-Flow-Monitoring-UsingProgrammable-NICs.pdf [2] Poutievski, L., Mashayekhi, O., Ong, J., Singh, A., et al (2022, August). Jupiter evolving: transforming google's datacenter network via optical circuit switches and software-defined networking. In Proceedings of the ACM SIGCOMM 2022 Conference (pp. 66-85) [3] Jupiter evolving: Reflecting on Google’s data center network transformation, August 2022. https://cloud.google.com/blog/topics/systems/the-evolution-of-googles-jupiter-data-center-network [4] RARE (Router for Academia, Research & Education), GÉANT https://docs.rare.geant.org [5] OpenDaylight – The Linux Foundation https://www.opendaylight.org/ [6] Open Network Operating System (ONOS) - Open Networking Foundation (ONF) https://opennetworking.org/onos/ [7] Ryu-SDN https://ryu-sdn.org/ [8] A component-based software defined networking framework in OpenStack. https://github.com/openstack/os-ken [9] Cisco ACI (Application Centric Infrastructure) https://www.cisco.com/site/mx/es/products/networking/cloud-networking/application-centricinfrastructure/index.html [10] TerafFlowSDN – ETSI https://www.teraflow-h2020.eu/ [11] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. 2008. OpenFlow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev. 38, 2 (April 2008), 69–74 [12] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, https://datatracker.ietf.org/doc/html/rfc6241 [13] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, https://www.rfc-editor.org/info/rfc4271 [14] B. Pfaff, “The Open vSwitch Database Management Protocol”, RFC 7047, DOI 10.17487/RFC7047, December 2013, https://datatracker.ietf.org/doc/html/rfc7047 [15] VyOS https://vyos.io/ [16] OpenBGPD https://openbgpd.org/ [17] BIRD https://bird.network.cz/ [18] ExaBGP https://github.com/Exa-Networks/exabgp [19] GitHub – osrg / gobgp https://github.com/osrg/gobgp [20] FRRouting https://frrouting.org/ [21] GitHub – holo-routing / holo https://github.com/holo-routing/holo