# CEI-Net: An open-source framework for P4-driven network management on the CEI Continuum

Carlos Gonzalez, Salim Mahamat Charfadine

► To cite this version:

Carlos Gonzalez, Salim Mahamat Charfadine. CEI-Net: An open-source framework for P4-driven network management on the CEI Continuum. MedComNet 2025 - 23rd Mediterranean Communication and Computer Networking Conference, IEEE, Jun 2025, Cagliari (Sardinia), Italy. pp.1-5, 10.1109/MedComNet65822.2025.11103524. hal-05176967

HAL Id: hal-05176967

https://inria.hal.science/hal-05176967v1

Submitted on 28 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# CEI-Net: An open-source framework for P4-driven network management on the CEI Continuum

Carlos GONZALEZ

IMT Atlantique, INRIA, LS2N

UMR CNRS 6004, F-44307

Nantes, France

carlos-javier.gonzalez-santamaria@ls2n.fr

Salim MAHAMAT CHARFADINE

ENASTIC

National Superior School of TIC

N'Djaména, Tchad

charfadine12@gmail.com

**Abstract**—This paper presents a Docker and Ansible-based framework for deploying and analyzing network topologies, focusing on performance metrics such as latency, throughput, and packet loss. By leveraging containerized environments, the proposed approach ensures lightweight, scalable, and efficient network emulation while maintaining flexibility in software deployment. The network efficiency and congestion were evaluated under varying payload sizes and architectural conditions. The results show that the cloud-based single topology achieves the lowest latency and highest throughput, making it ideal for centralized data-processing applications. The tree topology (edge hierarchy) introduces moderate latency owing to hierarchical forwarding, whereas the spine-leaf topology (distributed IoT) experiences higher latency variations and retransmissions, indicating increased congestion during large-scale deployments. Existing CEI Continuum frameworks that employ QEMU-based VMs and P4-based Mininet testbeds introduce higher latency and packet loss owing to infrastructure constraints and processing overhead. The results highlight the advantages of containerized network simulations for real-time high-performance networking applications, making them particularly suitable for edge computing and Internet of Things environments. To validate the scalability and reproducibility of our deployment, we implemented the framework on Grid'5000 using Enoslib, which provides programmable access to the bare-metal servers. This architecture enables the deployment of realistic, high-performance networking environments under controlled experimental conditions, supporting the extensive emulation of edge and cloud scenarios across distributed infrastructures.

**Index Terms**—SDN, docker, ansible automation, P4, edge-computing, IoT.

## I. INTRODUCTION

Software-Defined Networking (SDN) has revolutionized data center architectures by enabling centralized and programmable control over network infrastructure. Major cloud providers, such as Amazon, Google, and Microsoft, have adopted SDN to streamline the administration of scalable networks [1]. Among SDN protocols, OpenFlow remains a widely accepted standard for managing forwarding rules on devices such as the Open vSwitch (OVS) [2]–[4]. However, OpenFlow's limited flexibility and reliance on centralized control introduce latency and reduce responsiveness, particularly in dynamic, high-traffic environments.

To address these limitations, the P4 language has emerged as a powerful alternative, offering fine-grained programmability at the data plane [5], [6]. P4 enables custom header parsing and packet processing logic, which allows real-time traffic manipulation and performance monitoring directly on programmable switches [7]–[9]. Compared with OpenFlow, P4 supports lower latency and more adaptive network behavior, making it especially suitable for latency-sensitive scenarios such as edge computing and IoT [10]. Despite these

benefits, existing P4-based platforms often rely on simplified testbeds, such as Mininet, which do not adequately emulate the performance characteristics of embedded systems or real-world deployments [11], [12].

The integration of Ansible, Docker, and P4 offers transformative possibilities for embedded systems within the CEI Continuum spanning the IoT, edge, and cloud computing. In IoT and edge environments, where devices require efficient resource management and real-time responsiveness, they can automate the deployment of network configurations, thereby enabling a consistent and error-free setup for embedded systems. This is particularly beneficial for edge computing nodes that rely on a scalable infrastructure to manage the dynamic influx of IoT devices. Ansible is used to automate the deployment and configuration of network elements, ensuring consistency and reducing the need for manual configuration. Furthermore, Docker provides lightweight containerized environments for hosts and switches, thereby allowing flexible and isolated network emulation. The P4 BMv2 (Behavioral Model v2) was employed as a programmable switch, enabling custom packet-processing logic [13].

This study addresses this gap by proposing a practical and scalable testbed architecture that integrates Ansible, Docker, and P4 within the CEI Continuum context. Unlike prior studies that used emulated environments, our approach leverages real deployments on Grid'5000 a reconfigurable bare-metal testbed to achieve high-fidelity experiments. By adopting lightweight TinyCore OS containers and programmable BMv2 switches, we offer a realistic framework for evaluating edge-to-cloud communication, latency, and resource management in embedded networked systems. Our work advances the state of the art by providing an experimental platform that combines scalable container-based simulations, automated orchestration via Ansible, and programmable forwarding logic using P4. Specifically, this study contributes to the literature in the following ways:

* **Optimized edge-cloud communication:** Enhances decision-making and data exchanges across the CEI Continuum,

* **Integration of ansible, docker, and P4:** Enables real-time simulation and analysis of network behavior, optimizing latency, and computational performance,

* **Scalability and efficiency:** Evaluates the Grid'5000 server nodes' ability to sustain increasing computational loads without significant performance degradation,

* **Realistic embedded system emulation:** Moves away from Mininet to leverage tools better suited for CEI Continuum,
* Enhanced edge and IoT resource management: Enables energy-efficient network emulation for embedded systems.

By addressing the current limitations of experimental evaluation tools and emphasizing reproducibility and modularity, this study serves as a foundation for future research on programmable networking, edge intelligence, and embedded system optimization.

## II. BACKGROUND AND RELATED WORK

Lantz et. al. [14] demonstrated a simpler and efficient approach using Mininet's cluster mode to easily deploy a virtual testbed of lightweight containers on a single machine, an ad hoc cluster, or a dedicated hardware testbed. By adding an open source distributed network operating system such as ONOS, they can create a flexible and scalable open source development platform for distributed SDN systems and application software development.

Previous studies have explored P4-based networking solutions for SDN performance analysis, real-time monitoring, and intrusion detection. A Mininet-based testbed evaluates SDN performance, showing that increased packet processing raises delays and impacts throughput due to CPU constraints [9]. Another study introduced a high-performance in-band IDS using P4, integrating NetFlow and a Decision Tree model, achieving minimal computational overhead, and out-performing existing solutions in terms of accuracy and efficiency [15]. In addition, a P4-based monitoring framework for L4S networks leverages In-band Network Telemetry (INT) to enhance real-time monitoring with minimal resource impact [16]. Collectively, these studies demonstrate the potential of P4 for optimizing network performance, security, and scalability in high-speed and cloud environments.

Building on a similar focus on the CEI Continuum, but utilizing virtual machines, [17] proposed a framework for automating infrastructure deployment and benchmarking, encompassing cloud, edge, and endpoint devices. The framework simplifies the deployment of complex distributed systems by enabling researchers and engineers to emulate various infrastructure, install software, and benchmark applications with minimal effort. It leverages virtual machines for realistic emulation and integrates them with resource managers, such as Kubernetes and OpenFaaS, for application benchmarking.

In [18], the authors developed and tested an architecture for managing an IoT network by using the OpenFlow protocol with Raspberry Pi terminals. A comparative study was conducted with and without a load balancer to measure network performance. It was proven with a testbed that this solution addresses the issue of managing a massive number of connected objects through load balancing. In [19], the authors developed a level 2 platform to evaluate controller stability. A comparative study was conducted with different network sizes for OpenDaylight (ODL) and Open Network Operating System (ONOS) controllers. To integrate firewall functionalities, a Ryu-type controller was used to illustrate network function virtualization (NFV) with the concept of SDN.

In [20], the authors proposed a framework for a virtual laboratory with SDN for automated management of networks intended for student training. This solution allows for gradual

abstraction of network complexity through web access, enabling an advanced configuration of network functionalities. Named as ProNA, the framework consists of a web-based network laboratory application, an image for reproducible SDN exercises in containers, virtual machines, and a template for developing the data plane or control plane code. ProNA is a pedagogical tool that allows remote training of students via an interface.

Pineda et al. [21] developed a testbed on an autonomous 5G mobile network using SDN and NFV. This testbed is essential for evaluating the impact of SDN on the configuration, optimization, and performance improvement of mobile networks. By integrating several open tools such as Open5GS, srsRAN, UERANSIM, OpenDayLight (ODL), and OpenvSwitch (OVS), this simulation not only evaluates the latency and partitioning of configurations, but also proves that the concept of SDN is a reality. Technically, this solution allows for the analysis, management, and security of 5G networks. In [22], SDN was used to improve security in dynamic environments of a containerized blockchain network. This scalable solution based on SDN allows for the detection and mitigation of DDoS attacks. The integration of search, monitoring, and detection functions in an SDN controller using the OpenFlow protocol allows for the detection and mitigation of DDoS attacks. Packet flow transfer, control, and monitoring rules in the network are implemented using a programming language.

These softwarized networks rely on complex technology stacks, starting with low-level virtualization technologies and ranging up to machine learning-based orchestration solutions. One of the main challenges in these environments is verifying that the deployed functions and services operate correctly and meet the quality goals set by stakeholders before they are put into production. In [23], this challenge was addressed by introducing the novel concept of a verification and validation (V&V) platform for NFV, which enables the automatic testing and qualification of single-network functions and complex services.

## III. ARCHITECTURE

The architecture of our implementation was designed using real deployments in Grid'5000,<fnref n="1" /> leveraging its extensive reconfigurability and high-performance computing capabilities [24]. The study does not rely on model-based assessment but on measurements obtained from actual network emulations and empirical data collection. Our architecture integrates SDN principles with containerized environments using Docker, Ansible for automation, and P4 BMv2 for programmable data-plane operations. The modular design of CEI-Net<fnref n="2" /> was deployed using EnOSlib [25], which allows for the integration of cloud, edge, and IoT computing environments, facilitating an in-depth analysis of the network performance, resource management, and scalability under diverse experimental conditions. The framework was built on a Dell PowerEdge R630 server equipped with 128 GiB of memory to ensure sufficient capacity for memory-intensive applications. For storage, the node features a 400 GB SSD SAS Toshiba PX04SMB040 as the primary disk. The testbed was implemented on an ecotype cluster consisting of high-

<footnote n="1">¹https://www.grid5000.fr/w/Grid5000:Home</footnote>

<footnote n="2">²https://gitlab.inria.fr/cargonza/CEI-Net</footnote>
<figure><img src="image_2.png" /><figcaption>Fig. 1. P4-BMv2 Ansible Emulation Environment and Evaluation.</figcaption></figure>

performance computing nodes designed for intensive computational workloads.

Figure 1 illustrates the proposed Zone-Based CEI design which leverages distinct network topologies to optimize the performance across different deployment scenarios. Zone 1 utilizes a single-switch topology with a 10.0.1.0/24 network range, providing a compact and efficient infrastructure for localized cloud-edge computing with minimal latency, as shown in Fig. 1(a). Zone 2 employs a tree topology within the 10.0.3.0/24 subnet, facilitating a hierarchical edge network ideal for multi-tier IoT data aggregation and processing Fig. 1(b). Finally, Zone 3 adopts a spine-leaf architecture in the 10.0.5.0/24 range, ensuring high scalability and performance, making it suitable for large-scale edge-cloud environments that demand low-latency, high-throughput connectivity Fig. 1 (c). Fig. 1(d) shows the main components of the P4 packet-processing pipeline for a programmable BMv2 switch. It handles Ethernet, ARP, and IPv4 packets and implements basic Layer 2 switching and Layer 3 forwarding.

In our testbed, TinyCore OS containers functioned as lightweight emulated IoT endpoints. These containers were configured to generate network traffic using both TCP and ICMP protocols, allowing the assessment of connectivity, latency, and throughput under varying payload conditions. Specifically, each container transmits data to programmable P4-based switches using tools such as iperf3 and hping3, which emulate application-layer data transmission and control plane probing, respectively. Although the containers do not simulate specific IoT sensor workloads or application-layer protocols, such as MQTT, in this study, their use focuses on evaluating the network layer behavior and infrastructure responsiveness across the CEI continuum. This approach provides a reproducible and resource-efficient mechanism for stress-testing programmable forwarding paths and assessing end-to-end performance metrics relevant to edge and cloud offloading scenarios.

Our implementation leverages a customizable P4 program executed on the BMv2 switch, which goes beyond the default forwarding behavior by supporting Ethernet, ARP, and IPv4 packet handling, along with basic Layer 2 switching and Layer 3 forwarding. Although the underlying structure aligns with conventional SDN emulation patterns, the emphasis lies in the dynamic and automated deployment of the testbed using Ansible to provision resources, configure components, and orchestrate experiments. This integration not only minimizes manual overhead but also enhances the reproducibility and scalability of the system. The programmable forwarding plane of BMv2 enables the exploration and validation of new data-plane functionalities, such as dynamic rule updates and

traffic management strategies, within a realistic Docker-based topology. Real-time performance monitoring further distinguishes our setup by supporting an in-depth evaluation of the system behavior under varying CEI workload conditions.

## IV. SYSTEM MODELING AND PROBLEM FORMULATION

In this section, we present system modeling and problem formulation for deploying a containerized topology using Ansible. The problem involves setting up Docker containers that represent hosts and switches, connecting them with virtual Ethernet (veth) interfaces, and configuring their networking attributes. Table I provides a structured definition of the key symbols used in the mathematical representation of network topology and system workflow. Each symbol is essential for describing the setup, configuration, and execution of a containerized network environment. Below is a detailed explanation of these key elements.

<table><caption>TABLE I
SYMBOL DEFINITIONS</caption><thead><tr><td>Symbol</td><td>Definition</td></tr></thead><tbody><tr><td>G = (V, E)</td><td>Graph representing the network topology</td></tr><tr><td>V</td><td>Set of vertices (containers: hosts and switches)</td></tr><tr><td>E</td><td>Set of edges (virtual Ethernet connections)</td></tr><tr><td>H</td><td>Set of host containers</td></tr><tr><td>S</td><td>Switch container</td></tr><tr><td>P</td><td>Set of virtual Ethernet (veth) pairs</td></tr><tr><td>veth<sub>2i</sub>, veth<sub>2i+1</sub></td><td>Ends of a virtual Ethernet pair</td></tr><tr><td>PID(v<sub>i</sub>)</td><td>Process ID of container v<sub>i</sub></td></tr><tr><td>DockerInspect(v<sub>i</sub>)</td><td>Function to retrieve container PID</td></tr><tr><td>Assign(veth<sub>2i</sub>, v<sub>j</sub>)</td><td>Assigns veth pair to container v<sub>j</sub></td></tr><tr><td>IP(h<sub>i</sub>)</td><td>IP address assigned to host h<sub>i</sub></td></tr><tr><td>S<sub>0</sub>, S<sub>1</sub>, ..., S<sub>6</sub></td><td>States in Ansible playbook execution</td></tr><tr><td>T</td><td>Function representing full system execution</td></tr><tr><td>ConfigSwitch(s)</td><td>Switch configuration mapping veth pairs to MAC addresses</td></tr><tr><td>MAC<sub>i</sub></td><td>MAC address assigned to interface</td></tr></tbody></table>

### A. System Representation

We define the network topology as a graph.

$$G = (V, E)$$

where V is the set of vertices representing containers (hosts and switches) and E ⊆ V × V is the set of edges representing the veth connections.

1) Container Definitions: Let:

$H = \{h_1, h_2, \dots, h_k\}$ be the set of host containers.

$S = \{s\}$ be the single switch container.

$$V = H \cup S$$

Here, H represents the host container and S is the switch container.
2) Virtual Ethernet (veth) Pairs: The set of virtual Ethernet pairs, P, is defined as:

$$P = \{(veth_{2i}, veth_{2i+1}) | i \in \{0, 1, \dots, m-1\}\}$$

where veth$_{2i}$ and veth$_{2i+1}$ represent the two ends of a virtual Ethernet link.

### B. Container-to-PID Mapping

Each container $v_i \in V$ is assigned a process identifier (PID):

$$PID(v_i) = p_i \quad \text{where } p_i \in \mathbb{N}.$$

Mapping was obtained using Docker's inspection mechanism.

$$PID(v_i) = DockerInspect(v_i).$$

### C. Veth Pair Assignment

We assign veth pairs to containers using

$$\forall (veth_{2i}, veth_{2i+1}) \in P, \quad Assign(veth_{2i}, v_j) \wedge Assign(veth_{2i+1}, v_k)$$

where $v_j, v_k \in V$ are the containers connected by a pair.

### D. IP Address Configuration

Each host $h_i \in H$ is assigned an IP address,

$$IP(h_i) = 10.0.x.i/24.$$

The mapping of IP addresses to the veth interface is

$$IP(veth_{2i}) = IP(h_i).$$

### E. Task Workflow

The Ansible playbook execution is modeled as a sequence of state transitions:

* **Initialization:**

$$S_0 \xrightarrow{\text{Set\_Fact}} S_1$$

where $S_0$ is the initial state and $S_1$ includes the generated variables $(P, V)$.

* **Veth Pair Removal:**

$$S_1 \xrightarrow{\text{Remove}(P)} S_2$$

* **Container Deployment:**

$$S_2 \xrightarrow{\text{Run\_Containers}(V)} S_3$$

* **Veth Pair Creation:**

$$S_3 \xrightarrow{\text{Create}(P)} S_4$$

* **Namespace Assignment:**

$$S_4 \xrightarrow{\text{Assign}(P, PID(V))} S_5$$

* **IP Address Configuration:**

$$S_5 \xrightarrow{\text{ConfigIP}(P)} S_6$$

### F. Switch Configuration

Switch $s \in S$ is configured with its interface as

$$\text{ConfigSwitch}(s) = \{(veth_{2i+1}, \text{MAC}_i) | i \in \{0, 1, \dots, k-1\}\}$$

where MAC$_i$ denotes the assigned MAC address for each interface.

### G. Overall Execution

The complete system execution can be represented as

$$\mathcal{T}(S_0) = S_6$$

where:

$$\mathcal{T} = \begin{array}{l} \text{ConfigIP} \Rightarrow \text{Assign} \Rightarrow \text{Create} \Rightarrow \text{Run\_Containers} \\ \qquad \Rightarrow \text{Remove} \Rightarrow \text{Set\_Fact.} \end{array}$$

This workflow ensures a dynamic setup of the topology, including container deployment, network namespace management, and IP configuration. In this framework, various network topologies were implemented using Ansible, Docker, and P4 BMv2 to create a programmable and automated network environment. The implemented topologies include single-switch, tree, and spine-leaf architectures, each of which was designed to emulate real-world networking scenarios. Ansible playbooks orchestrate the creation and configuration of these topologies by deploying Docker containers, assigning virtual Ethernet veth pairs, configuring IP addresses, and establishing P4 forwarding rules. This approach allows scalable, reproducible, and programmable network experiments, making it ideal for testing and validating custom data plane behaviors and SDN applications.

1) Single-Switch Topology: In a simple topology with a single switch (e.g., the BMv2 switch), we define

$$H = \{h_1, h_2, \dots, h_k\} \quad (\text{Set of host containers})$$

$$S = \{s\} \quad (\text{Single switch container})$$

$$V = H \cup S$$

$$E = \{(h_i, s) | h_i \in H\}$$

This configuration represents a star topology in which all hosts are directly connected to the switch.

2) Tree Topology: Tree topology hierarchically organizes the network

$$S = \{s_0, s_1, \dots, s_n\} \quad (\text{Set of switches})$$

$$E = \{(s_0, s_i) | i \in \{1, 2, \dots, m\} \} \cup \{(s_i, h_j) | h_j \in H, i \in \{1, 2, \dots, m\}\}.$$

where $s_0$ is the root switch, $s_i$ is a branch switch, and $h_j$ is a host.

3) Spine-Leaf Topology: A more scalable design is the spine-leaf topology.

$$S_{\text{leaf}} = \{s_{l1}, s_{l2}, \dots, s_{lm}\} \quad (\text{Leaf switches})$$

$$S_{\text{spine}} = \{s_{s1}, s_{s2}, \dots, s_{sn}\} \quad (\text{Spine switches})$$

$$H = \{h_1, h_2, \dots, h_k\} \quad (\text{Hosts})$$

$$E = \{(h_i, s_{lj}) | h_i \in H, s_{lj} \in S_{\text{leaf}}\} \cup \{(s_{lj}, s_{si}) | s_{lj} \in S_{\text{leaf}}, s_{si} \in S_{\text{spine}}\}$$

Each host connects to a leaf switch, and each leaf switch connects to all spine switches, thereby ensuring multiple paths for redundancy and load balancing.
<figure><img src="image_3.png" /><figcaption>Fig. 2. Impact of Payload Size on Latency: RTT Distribution Analysis.</figcaption></figure>

## V. TEST AND RESULTS

Table II presents a comparative analysis of different network topologies in terms of latency, throughput, and packet loss. The results indicate that the single topology exhibits the lowest latency (ranging from 0.5 to 1.8 ms) and the highest throughput (179–192 Mbps), with minimal packet loss (0–0.5%). The tree topology and spine-leaf topology demonstrate moderate latency levels (3.1–4.5 ms and 2.8–4.4 ms, respectively) and medium throughput (85–92 Mbps and 88–94 Mbps, respectively), both experiencing packet loss rates between 0.1% and 1%. These findings suggest that although a single topology is optimal for low-latency, high-throughput applications, tree, and spine-leaf topologies may provide more scalable and resilient architectures.

<table><caption>TABLE II
COMPARISON OF NETWORK TOPOLOGIES</caption><thead><tr><td>Topology</td><td>Latency (ms)</td><td>Throughput (Mbps)</td><td>Packet Loss (%)</td></tr></thead><tbody><tr><td>Single</td><td>Low (0.5-1.8)</td><td>High (179-192)</td><td>Low (0-0.5%)</td></tr><tr><td>Tree</td><td>Moderate (3.1-4.5)</td><td>Medium (85-92)</td><td>Medium (0.1-1%)</td></tr><tr><td>Spine-Leaf</td><td>Moderate (2.8-4.4)</td><td>Medium (88-94)</td><td>Medium (0.1-1%)</td></tr></tbody></table>

In addition, with the MTU configured at 1500 bytes, this setup is particularly well suited for edge computing and IoT deployments, where efficient packet transmission and minimal overhead are critical for maintaining network performance. The 1500-byte MTU is the standard for most networks, making it ideal for general IoT applications, including the TinyCore OS running on lightweight devices. Moreover, the MTU can be adjusted to adapt to various network environments and communication protocols, such as cellular networks, MQTT, and CoAP (IoT protocols over IP), as well as Low-Power Wide Area Networks (LPWAN), such as LoRaWAN and NB-IoT links. This adaptability ensures optimal performance across diverse IoT infrastructures, enhancing the connectivity and data transmission efficiency in constrained environments.

Fig. 2 shows the analysis of network efficiency and congestion under different payload sizes and architectural conditions, iperf3 was used to measure bandwidth and retransmissions by sending multiple parallel TCP streams with a 100, 200, 500, 1000 byte Maximum Segment Size (MSS). Additionally, hping3 sends SYN packets to assess the Round Trip Time (RTT) and connection response behavior. The cloud-based single topology demonstrated the lowest latency (14.3–17.7 ms) and highest throughput, making it ideal for

centralized processing Fig. 2 (a). The tree topology (edge hierarchy) exhibits moderate latencies (31.4–35.4 ms) owing to hierarchical forwarding, as shown in Fig. 2 (b), whereas the spine-leaf topology (distributed IoT) exhibits higher latency variations (33.1–36.8 ms) and retransmissions, indicating increased congestion Fig. 2 (c).

The observed divergence between the RTT values presented in Fig. 2 and the latency values reported in Table II is attributed to the use of different measurement tools and methods. Specifically, Table II quantifies the one-way transmission latency as estimated by iperf3 during continuous TCP data transfers, primarily reflecting the transport-layer performance under sustained load conditions. In contrast, Fig. 2 illustrates the RTT values obtained using hping3 through the transmission of SYN packets, capturing the combined forward and return path delays and emphasizing network-layer responsiveness. Furthermore, RTT measurements inherently incorporate additional factors, such as control plane processing, connection establishment overhead, and the probing technique itself, whereas iperf3-derived latency represents a smoothed estimation of data transmission delays within established TCP flows.

Scalability and resource efficiency are evaluated by analyzing the CPU and memory saturation during high-density container deployments across 500 tiny hosts and a BMV2 switch in a linear topology. The experiments systematically measured the system load of each server node to determine the point at which the computational resources became a limiting factor. The system exhibits moderate CPU stress, consuming a significant share of CPU resources (up to 95% for a single process). Despite the load, memory usage remained low, indicating that CPU saturation, rather than memory exhaustion, is the primary scalability constraint under the current high-container deployment scenario.

Compared with [9], where the P4-based Mininet testbed experienced increased delays (up to 14 ms) and significant packet loss rates (up to 45%) owing to server limitations and elevated packet processing overhead, our approach demonstrated considerably lower latency and improved reliability. Similarly, although the CEI Continuum framework evaluated in [17] leverages QEMU-based VMs to approximate near-bare-metal performance, it incurs substantial resource overheads, longer boot times, and scalability challenges under increasing system load and endpoint concurrency. In particular, [17] shows that real-time offloading becomes unsustainable beyond four concurrent endpoints in a cloud setting, leading to exponential latency increases due to queuing delays. In contrast, our P4-based CEI Continuum testbed emphasizes
scalability, programmability, and efficient resource usage, enabling the deployment of network topologies that maintain consistently low latency and high throughput, even under varied load conditions. This highlights the practical advantages of containerized and programmable network environments for future CEI applications over traditional VM-based and emulated solutions.

## VI. CONCLUSION AND FUTURE WORKS

This study highlights the advantages of a Docker and Ansible-based framework as a lightweight and scalable alternative to the traditional virtual-machine-based network emulation. The findings indicate that the tested network topologies achieve minimal latency and a high throughput. The evaluation of different topologies revealed that a single topology is optimal for centralized processing, tree topology balances scalability with performance trade-offs, and spine-leaf topology encounters congestion challenges, underscoring the need for efficient routing and queuing mechanisms. The P4-based Mininet testbed and CEI Continuum framework exhibited higher latency and packet loss due to processing overhead and infrastructure limitations. Whereas virtual-machine-based solutions offer greater flexibility for heterogeneous architectures, containerized deployments provide faster provisioning, lower resource consumption, and enhanced efficiency in CEI Continuum environments. Future research will focus on enhancing automation, incorporating real-time monitoring and AI, and exploring additional network configurations to further optimize the performance in diverse edge-computing environments.

## REFERENCES

[1] Z. Zha, A. Wang, Y. Guo and S. Chen, "Towards Software Defined Measurement in Data Centers: A Comparative Study of Designs, Implementation, and Evaluation," in IEEE Transactions on Cloud Computing, vol. 11, no. 2, pp. 2057-2070, 1 April-June 2023, doi: 10.1109/TCC.2022.3181890.

[2] M. B. Jiménez, D. Fernández, J. E. Rivadeneira, L. Bellido and A. Cárdenas, "A Survey of the Main Security Issues and Solutions for the SDN Architecture," in IEEE Access, vol. 9, pp. 122016-122038, 2021, doi: 10.1109/ACCESS.2021.3109564.

[3] Z. A. Bhuiyan, S. Islam, M. M. Islam, A. B. M. A. Ullah, F. Naz and M. S. Rahman, "On the (in)Security of the Control Plane of SDN Architecture: A Survey," in IEEE Access, vol. 11, pp. 91550-91582, 2023, doi: 10.1109/ACCESS.2023.3307467.

[4] A. Kanwal, M. Nizamuddin, W. Iqbal, W. Aman, Y. Abbas and S. Mussiraliyeva, "Exploring Security Dynamics in SDN Controller Architectures: Threat Landscape and Implications," in IEEE Access, vol. 12, pp. 56517-56553, 2024, doi: 10.1109/ACCESS.2024.3390968.

[5] P. Zanna, P. Radcliffe and K. G. Chavez, "A Method for Comparing OpenFlow and P4," 2019 29th International Telecommunication Networks and Applications Conference (ITNAC), Auckland, New Zealand, 2019, pp. 1-3, doi: 10.1109/ITNAC46935.2019.9077951.

[6] Y.-K. Chang, H.-Y. Wang and Y.-H. Lin, "A Congestion Aware Multi-Path Label Switching in Data Centers Using Programmable Switches," 2021 IEEE International Conference on Networking, Architecture and Storage (NAS), Riverside, CA, USA, 2021, pp. 1-8, doi: 10.1109/NAS51552.2021.9605422.

[7] F. Paolucci, F. Civerchia, A. Sgambelluri, A. Giorgetti, F. Cugini and P. Castoldi, "P4 Edge node enabling stateful traffic engineering and cyber security," in Journal of Optical Communications and Networking, vol. 11, no. 1, pp. A84-A95, Jan. 2019.

[8] A. Liatifis, P. Sarigiannidis, V. Argyriou, and T. Lagkas, "Advancing SDN: from OpenFlow to P4, a Survey," ACM Computing Surveys, Aug. 2022, doi: https://doi.org/10.1145/3556973.

[9] L. D. Hasnaa, E. Mulyana and G. N. Nurkahfi, "Performance Analysis of Mininet-based Testbed for Software Defined Network with P4 Programmable Data Plane," 2023 17th International Conference on Telecommunication Systems, Services, and Applications (TSSA), Lombok, Indonesia, 2023, pp. 1-7, doi: 10.1109/TSSA59948.2023.10366975.

[10] D. Scano et al., "Enabling P4 Network Telemetry in Edge Micro Data Centers With Kubernetes Orchestration," in IEEE Access, vol. 11, pp. 22637-22653, 2023, doi: 10.1109/ACCESS.2023.3249105.

[11] Di Lena, G., Tomassilli, A., Saucez, D., Giroire, F., Turletti, T. & Lac, C. Distrinet: a mininet implementation for the cloud. SIGCOMM Comput. Commun. Rev. 51, 2-9 (2021,3), https://doi.org/10.1145/3457175.3457177

[12] M. N. A. Sheikh, I.-S. Hwang, M. S. Raza, and M. S. Ab-Rahman, 'A Qualitative and Comparative Performance Assessment of Logically Centralized SDN Controllers via Mininet Emulator', Computers, vol. 13, no. 4, 2024.

[13] P4 Language Consortium. Behavioral Model (bmv2), 2016, [online] Available: https://github.com/p4lang/behavioral-model.

[14] B. Lantz and B. O'Connor, 'A Mininet-Based Virtual Testbed for Distributed SDN Development', SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 365-366, Aug. 2015, doi.org/10.1145/2829988.2790030.

[15] Y. Chen, S. Layeghy, L. D. Manocchio, and M. Portmann, "P4-NIDS: High-Performance Network Monitoring and Intrusion Detection in P4," arXiv.org, 2024. https://arxiv.org/abs/2411.17987.

[16] H. N. Nguyen, B. Mathieu, M. Letourneau, G. Doyen, S. Tuffin and E. M. d. Oca, "A Comprehensive P4-based Monitoring Framework for L4S leveraging In-band Network Telemetry," NOMS 2023-2023 IEEE/IFIP Network Operations and Management Symposium, Miami, FL, USA, 2023, pp. 1-6, doi: 10.1109/NOMS56928.2023.10154331.

[17] M. Jansen, L. Wagner, A. Trivedi, and A. Iosup, 'Continuum: Automate Infrastructure Deployment and Benchmarking in the Compute Continuum', in Companion of the 2023 ACM/SPEC International Conference on Performance Engineering, Coimbra, Portugal, 2023, pp. 181-188. https://doi.org/10.1145/3578245.3584936.

[18] Arman, Syed Adib and Rahman, Md. Mahfujur and Rahman, Syeda Fabliha and Urmi, Nazia Parvin and Umee, Progya Paromita and Muslim, Nasif and Islam, Salekul, "Developing an IoT Networks-based Testbed for Software-Defined Networks", in IEEE Region 10 Symposium (TENSYMP), pp. 1752-1755, 2020, doi:10.1109/TENSYMP50017.2020.9230874.

[19] Jayatunga, Eranda and Dilshani, Karunanayaka and Rathnamalala, Damitha and Milan, Pubudu, "Fully Integrated Software-Defined Networking (SDN) Testbed Using Open-Source Platforms", in SN Computer Science, pp. 1-15, vol. 3, 2022 doi:10.1007/s42979-021-00973-2

[20] Rieger, Sebastian and Stiemerling, Martin, "ProNA: A Virtual Lab Framework to Teach Network Automation and SDN in Undergraduate Courses", In IEEE Network Operations and Management Symposium, p. 1-3, 2024, doi: 10.1109/NOMS59830.2024.10575540

[21] Pineda, Diana and Harrilal-Parchment, Ricardo and Akkaya, Kemal and Ibrahim, Ahmed and Perez-Pons, Alexander, Design and Analysis of an Open-Source SDN-based 5G Standalone Testbed, In IEEE INFOCOM 2023 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pp. 1-6, 2023, doi:10.1109/INFOCOMWKSHPS57453.2023.10225862.

[22] Chiras, Anargyros and Peratikou, Adamantini and Stavrou, Stavros, "Increasing Security of Containerized Blockchain using SDN", In Panhellenic Conference on Electronics & Telecommunications (PACET), pp. 1-5, 2024, doi: 10.1109/PACET60398.2024.10497057.

[23] M. Peuster et al., "Introducing Automated Verification and Validation for Virtualized Network Functions and Services," in IEEE Communications Magazine, vol. 57, no. 5, pp. 96-102, May 2019, doi: 10.1109/MCOM.2019.1800873.

[24] F. Cappello et al., "Grid'5000: a large scale and highly reconfigurable grid experimental testbed," The 6th IEEE/ACM International Workshop on Grid Computing, 2005., Seattle, WA, USA, 2005, pp. 8 pp-, doi: 10.1109/GRID.2005.1542730.

[25] Cherrueau, R., et al. "EnosLib: A Library for Experiment-Driven Research in Distributed Computing," in IEEE Transactions on Parallel and Distributed Systems, vol. 33, no. 6, pp. 1464-1477, 2022.