P4-Based INT Implementation on FPGAs: A Hardware-Accelerated Approach

P4-Based INT Implementation on FPGAs: A Hardware-Accelerated Approach Angelos Dimoglis∗, Luca Cetino†, Anestis Dalgkitsis∗, Chrysa Papagianni∗Paola Grosso∗, ∗Multiscale Networked Systems, University of Amsterdam, Amsterdam, The Netherlands {a.dimoglis, a.dalgkitsis, c.papagianni, p.grosso}@uva.nl †NetGroup, Politecnico di Torino, Torino, Italy [email protected] Abstract—The growing scale and complexity of modern networks demand enhanced visibility and real-time adaptability beyond what traditional monitoring solutions offer. Programmable data planes, supported by languages like P4, allow users to define packet processing behavior and integrate advanced functionalities directly into network devices. In-band Network Telemetry (INT) leverages this programmability to embed detailed, per-packet network state information into data flows, facilitating real-time insights such as path tracing and congestion detection with minimal overhead. In this paper, we present two implementations of INT on P4-programmable FPGA-based SmartNICs. We evaluate their performance in the FABRIC testbed, an international research platform equipped with extensive computing and storage resources connected via optical links. Our results show that INT increases marginally the average RTT–up to 0.45%–while RTT variability remains comparable to our baseline setup. Furthermore, the overall resource utilization remains under 2% across all components. These findings confirm that INT imposes modest processing and hardware overhead, with minimal impact on latency and resource footprint, making it well-suited for real-time monitoring of complex network infrastructures. Index Terms—Programmable Networks, Network Monitoring, In-band Network Telemetry, P4, FABRIC, FPGA I. INTRODUCTION The Internet enables global communication, connecting people, devices, and services. As networks grow in scale and complexity, demands for performance, reliability, and visibility also increase. Traditional monitoring fails to provide the fine-grained real-time insights necessary to manage and optimize these increasingly dynamic environments. To meet the demands of modern networks, it is essential to not only observe but also adapt to changing conditions in real time. This need for greater visibility and flexibility has driven the evolution of programmable data planes, which offer new opportunities to address the limitations of traditional, opaque network infrastructures. In particular, the emergence of P4, a domain-specific language for programming packet processors, has enabled fine-grained control over how packets are processed within network devices. Unlike fixed-function hardware, P4 empowers developers to define custom packet processing logic without requiring changes to the physical infrastructure. This programmability has paved the way for embedding novel functionalities, such as real-time telemetry collection, directly into the data plane. In-band Network Telemetry (INT) [1] leverages these advancements, enabling detailed network state information to be embedded into data packets, as they traverse the network. By collecting real-time, fine-grained telemetry information with minimal overhead, INT enables unprecedented perpacket visibility into network behavior, facilitating valuable insights such as path tracing, congestion detection, and device-specific metrics. In this paper, we present two INT implementations for path tracing to enhance network visibility: one over Layer 3.5 (GRE) and the other over Layer 4 (TCP). These are deployed on the FABRIC testbed [2], an international research infrastructure comprising interconnected sites distributed across the globe. Our setup leverages FPGA-based SmartNICs as programmable network devices, configured using the P4 language to implement custom data plane logic. Through these implementations, we demonstrate how INT enables fine-grained insights into modern network operations with minimal overhead, and how this enhanced observability supports the broader goal of digital sovereignty in an increasingly opaque Internet infrastructure. The remainder of this paper is organized as follows. Section II describes basic concepts, such as P4, Inband Network Telemetry, and FPGAs as programmable network devices. Then, in section IV, the two P4 applications, operating on different layers, are documented in detail. Next, in section V, we give a short description of the used testbed (FABRIC), and we examine the performance of the two implementations in terms of resource utilization and network performance. Lastly, in section VI, we conclude by highlighting the most important findings and give some future directions. II. BACKGROUND P4 [3] is a domain-specific programming language designed to specify the behavior of the data plane in network devices. It allows developers to describe packet processing algorithms using a combination of generalpurpose imperative constructs and specialized declarative ones for data-plane-specific tasks such as counters, meters, and checksum calculations. Originally introduced with P414, P4 has evolved with P416 to support a broader range of targets and pipeline architectures by separating the core language from device-specific details, making it architecture-agnostic. This architecture-agnostic design has enabled P4 to be effectively compiled and deployed across a diverse range of hardware and software platforms. Depending on the performance requirements and deployment context, P4 programs can be executed on a variety of targets (ASICs, NPUs, FPGAs etc.), each offering different trade-offs in programmability, speed, and integration capabilities. Regardless of the underlying target, the execution model of a P4 program follows a common logical structure defined by its control flow, which is depicted in Figure 1. This structure organizes packet processing into modular stages, enabling a consistent and portable abstraction across different platforms. The main components of this control flow are a parser, the match-action pipeline and a deparser which respectively extract packet headers, process them based on defined rules through a series of match-action units, and reconstruct the packet for transmission [4]. Match Logic Match Logic Action Logic Action Logic Programmable Parser Programmable Deparser Programmable match-action pipeline Metadata Metadata Fig. 1: Typical P4-switch control flow in the ProtocolIndependent Switch Architecture (PISA) A. In-band Network Telemetry Network telemetry has emerged as a key approach for modern network data collection and analysis, offering enhanced scalability, accuracy, coverage, and performance compared to traditional measurement methods. Broadly speaking, telemetry refers to the automated process of remotely gathering and processing network information, providing network operators with extensive visibility into network behavior. Among the various telemetry techniques, INT has gained significant attention in both academic and industrial communities. The P4 INT Specification v2.1 [1], defines mechanisms for collecting telemetry data directly within data packets, as they traverse the network. The specification outlines several modes of operation, including INT-MD (eMbed Data), INT-MX (MiXed mode), and INT-XD (eXport Data). Among these, INT-MD embeds both the telemetry instructions and metadata directly into the packet headers, allowing each transit device to append its local state information as the packet passes through, as illustrated in Figure 2. We employ this mode for its simplicity, self-contained design, and alignment with the goals of in-band telemetry. This approach shifts network measurement to a purely dataplane-driven process, minimizing control-plane interaction, and enabling per-hop visibility and real-time capture of transient network issues (bottlenecks, equipment failures etc.) [5]. Host 1 INT Source Node INT Transit Hop INT Sink Node Host2 Telemetry Server Packet Header Data Packet Header Data INT Header Metadata-1 Packet Header Data INT Header Metadata-1 Metadata-2 Packet Header Data INT Header Metadata-1 Metadata-2 Metadata-3 Packet Header Data Data Packet Data Packet INT Report Fig. 2: Example In-band Network Telemetry System B. FPGAs and SmartNICs The INT framework embeds telemetry operations in the data plane. While traditional fixed-function ASICs lack the flexibility for such advanced processing, programmable ASICs support INT such as the Intel Tofino series of P4-programmable Ethernet switch ASIC. However, as Intel has discontinued the development of the next-generation Tofino products, P4-programmable SmartNICs provide a viable and low cost alternative, extending fine-grained visibility even into application traffic. The flexibility of the solution increases further with the use of FPGA-based SmartNICs; specialized network interface cards utilizing FPGAs that provide a balance between the high performance required for data plane operations and the flexibility needed for complex packet processing. Initially, SmartNICs relied on general-purpose CPUs and dedicated hardware accelerators for tasks such as encryption or compression [6]. However, newer generations, like AMD Alveo U280, have replaced the CPU with a reconfigurable FPGA, enabling the implementation of fully programmable data planes. III. RELATED WORK Initial explorations of use of INT on high-performance programmable devices can be found in [7] and [8]. Specifically, in [7] the authors investigated the performance of P4-enabled networks over optical media to assess the potential of detailed telemetry for ultra-low latency applications such as 5G ULLC. They evaluated multiple P4 parameters on a testbed composed of an Inventec P4 switch, a Ciena 8700 switch, and two P4enabled FPGA-based Alpha-Data KU3 NICs at the end hosts, using DPDK for P4 packet forwarding to achieve efficient 40 Gbps transmission. The study collected perdevice metadata through INT, including timestamps, switch ID, queue occupancy, and hop latency. The experiments were performed locally and were not ported to a large-scale testbed. In [8] the authors introduce IntOpt, a scalable and expressive telemetry framework for monitoring Service Function Chains (SFCs) in NFV environments. The system leverages INT for active probing and collects fine-grained network statistics through P4-programmable data planes. To minimize monitoring overhead, IntOpt employs a Simulated Annealing-based Random Greedy (SARG) meta-heuristic that optimizes the placement and frequency of monitoring flows across the network. The framework’s evaluation relies on FPGA-based benchmarking using the P4FPGA toolkit [9] on the NetFPGASUME platform, which is used to model the delay and overhead introduced by INT operations such as packet parsing and telemetry header processing. The experiments were conducted on a realistically sized topology with 37 nodes and varying numbers of flows. However, the paper does not clearly indicate the traffic volume generated, making it difficult to evaluate the relative impact of telemetry operations on switch and network performance. More recently, in [10] the authors present a complete toolchain and deployment workflow for deploying custom P4 programs on FPGA-based targets, and a clockbased INT mechanism that collects timestamps through INT to estimate one-way delay. Since the timestamps rely on local FPGA clocks, which are not fully synchronized, the authors propose integrating a PTP client on the FPGA to synchronize with FABRIC’s GPSsynchronized PTP server as future work. They validate correct operation through two separate experiments on Open Cloud Testbed (OCT) and FABRIC, but they do not provide comprehensive performance results under varying realistic network loads. IV. PATH TRACING & TRUST-AWARE PATH ROUTING We aim to demonstrate the feasibility of implementing INT in real-world programmable data planes with two distinct P4-based implementations. One focuses on path tracing over layer 3/3.5 using IP/GRE encapsulation, while the other operates at layer 4 by embedding telemetry data in TCP options. These solutions are deployed on FPGA-based SmartNICs and are designed to showcase both the expressiveness of the P4 language and the practical considerations in enabling fine-grained, inband telemetry. We provide the details for each INT application and respective HW development framework. A. Hardware Platform & Development Framework Our INT implementation is based on the AMD Alveo U280 Datacenter Accelerator Card, which offers substantial onboard hardware resources. The FPGA chip on the board serves as the foundation for our design. Detailed technical specifications of the board and its FPGA can be found in [11]. To support our INT applications on the Alveo U280, we use the ESnet SmartNIC framework [12], an open-source toolchain designed specifically for programming AMD/Xilinx Alveo FPGA cards with P4. The framework integrates Xilinx tools and supports additional components such as DPDK, enabling streamlined development and deployment workflows. It separates the process into two main phases: (i) a development workflow for compiling P4 code into FPGA bitfiles, and (ii) a deployment workflow for loading and running those bitfiles on Alveo hardware. This structured approach significantly simplifies the process of transforming P4 programs into high-performance, in-network telemetry applications. B. Path Tracing over GRE The P4 INT specification [1] outlines different options for the INT header placement within a packet’s header stack. The INT header can be inserted either as a protocol option or encapsulation payload for any encapsulation protocol currently available. INT over GRE (Generic Routing Encapsulation) was the preferred header placement for this application. The final structure of the packet is shown in Figure 3a. The following metadata is collected: Device ID: Inserted by each device (FPGA) with a preconfigured value — Can be used for path tracing. Hop Count: Indicates the remaining INT nodes that may append metadata. Each INT node decrements this value; if zero, INT data should not be added. The main processing of the P4 Application is taking place in the programmable match-action pipeline, which was described in section II. This pipeline defines how packets are matched against tables and ultimately manipulated by the programmable device. Specifically, each table specifies a set of keys for look-up and a corresponding set of actions to be executed upon a successful match. In this implementation, along with the (a) INT over GRE (b) INT Header as TCP Option Fig. 3: INT Header Location tables for Layer 2/3 forwarding, another table is used for INT operations: int operation: Performs a lookup using a domainspecific instruction field of the INT header (as defined in [1]), and determines the corresponding INT actions to be executed. These actions involve collecting telemetry metadata in-band by directly inserting the metadata into the appropriate field of the packet’s metadata stack. C. Path Tracing & Trust Evaluation over TCP In this implementation, a slightly modified In-band Network Telemetry scheme is employed. The custom INT header is embedded as a TCP option, positioned immediately after the TCP header. This placement facilitates more effective identification of collected metadata when using traffic analysis tools such as Wireshark or Zeek. Also, the collection of device metadata encapsulated in TCP Options has been already demonstrated in previous works with INT [13]. The revised location of the INT header is illustrated in Figure 3b. In addition to the INT header, an auxiliary Counter header is included, which contains the number of subsequent INT headers. This information is essential for the parser, enabling it to determine how many INT headers to process based on the number of hops. As a result, the P4 application becomes more adaptable, eliminating the need for data plane modifications when programmable nodes are added or removed along the path. In this implementation, additional metadata is collected to support the evaluation of a programmable device’s trustworthiness: Device ID: A unique identifier assigned to each device is appended to the packet. This allows reconstruction of the packet’s path by analyzing the sequence of collected IDs. Location: Devices embed their geographic location, enabling users to identify where along the globe their traffic was processed. Vendor: Indicates the manufacturer of the device (e.g., Cisco, Nokia), providing insight into the hardware and potential supply chain trust. Firmware: Represents the currency of the device’s firmware. A higher value may imply that the device is running a more recent version, likely including the latest security patches, making it more suitable for handling sensitive or critical data. Telemetry data is appended only to TCP packets. This P4 application also utilizes match-action tables for INTrelated operations: specs retrieval: Functionally similar to the int operation table in “Path Tracing over GRE”. A corresponding action is executed to embed metadata into the packets. traffic origin: This table identifies the port (of the device) where client-side TCP traffic is expected. By matching this port, telemetry operations are limited to packets traveling towards the destination host (server). V. EXPERIMENTS A. FABRIC To validate our INT implementations and assess their behavior in realistic, high-performance settings, we deployed them on the FABRIC testbed. FABRIC (Adaptive Programmable Research Infrastructure for Computer Science and Science Applications) [2] is an international research platform that supports advanced experimentation across multiple areas of computer science, including networking. Distributed across commercial colocation sites, national labs, and campuses, FABRIC’s core infrastructure spans 29 U.S. locations, each equipped with extensive computing and storage resources connected via high-speed, dedicated optical links. It also links to the broader Internet, and through FABRIC Across Borders (FAB), now including four international nodes in Asia and Europe. Figure 4 shows the global FABRIC network, with Terabit core and 100G links. FABRIC was chosen for our experiments because it supports custom network topologies, non-standard networking operations like Inband Network Telemetry (INT), and provides access to advanced hardware, such as AMD/Xilinx Alveo U280 FPGA-based SmartNICs. B. GRE Path Tracing: Preliminary Experimental Results This experiment is based on the implementation “Path Tracing over GRE”, which was described in subsection IV-B. The topology used for this experiment is depicted in Figure 5. It includes four different virtual machines, two for the FPGAs and two for the end-hosts. Our experiment spans over two different sites: Kansas and California. Fig. 4: FABRIC Testbed [14] Fig. 5: FABRIC Testbed Slice Implementing the INT Domain The two virtual machines on nodes FPGA 1 and FPGA 2 are connected to a SmartNIC (Alveo U280), and serve as programmable INT devices. A source node initiates traffic, crafting packets that embed Domain Specific (DS) Instructions to represent one edge of the INT domain. As packets flow through FPGA 1 and 2, these devices execute the requested instructions within their programmable data planes. Finally, a sink node collects the processed INT traffic, extracts, and analyzes the embedded metadata. For the experiment, synthetic network traffic is generated at the INT Source Node using a Python script built with the Scapy library. The script defines custom packet classes to match the header formats expected by the P4 application. At the receiving end, the INT Sink Node acts as the final hop of the INT domain. Here, packet analysis is performed using tcpdump, which captures and displays the raw byte structure of incoming packets. The DS Instruction (value 0x0001) used in the tests requests the INT devices to “push” the switch ID metadata into the packet. This mechanism allows the INT domain to reconstruct the packet’s path through the network with fine granularity, as each device leaves a unique trace in the packet headers. To evaluate the performance of In-band Network Telemetry (INT), we measure the Round Trip Time (RTT), which serves as an indicator of network latency. The experiment consists of two phases. In the first phase, baseline latency is established using standard packets that carry a dummy UDP payload and are forwarded without any INT metadata. In the second phase, the same measurements are repeated using INT-formatted packets to quantify the impact of telemetry processing. Overall, the results indicate that the RTT for INT packets remains close to that of non-INT packets, suggesting that the additional telemetry operations introduce only minimal overhead. Some fluctuations are observed, with INT packets occasionally exhibiting slightly higher latency, possibly due to transient queuing at the FPGA switches. However, the general trend shows that INT processing does not consistently increase delay. Latency remains within an acceptable range, demonstrating that the FPGA-based implementation efficiently supports telemetry functionality without substantially impacting network performance. C. TCP Trust-aware Telemetry: Experimental Results In this case, the experimental topology is a hybrid network consisting of both software and hardware targets (see Figure 6). The nodes are geographically distributed across four sites: Texas, New Jersey, Kansas, and Washington D.C. Fig. 6: Hybrid topology of bmv2s and FPGA-based SmartNICs The software targets are bmv2 switches running on general-purpose CPUs. In contrast, the hardware targets are FPGA-based SmartNICs, identical to those used in the previous experiment. Due to lack of available ports, FPGAs could not be deployed at the end-hosts, so bmv2s were used instead. All the network devices (except the P4 Collector) are running the transport-layer telemetry, which was described in detail in subsection IV-C. In this scenario, we are sending TCP traffic from Host 1 to Host 2 using iperf3. As traffic is passing through the network, all the switches (software and hardware) along the path are embedding their metadata (device ID, location, vendor, and firmware) into the packets. At the last hop (Switch 3), all the collected metadata (INT report) are forwarded to the P4 Collector, while the original packet is being sent to its destination (Host 2). The P4 Collector is a bmv2 switch that replaces the traditional telemetry server by performing telemetry processing directly in the data plane. Unlike telemetry servers, which operate in software and are constrained by CPU performance, the P4 Collector enables real-time decision-making at line rate. This approach significantly reduces latency and overhead, making it more suitable for time-sensitive applications and high-throughput environments. A key function of our system is the computation of atrust level for each network device, representing how trustworthy a device is based on user-defined policies or preferences [15]–[17]. For example, if a user prefers their data to be processed at location X rather than location Y, the switch at location X would be assigned a higher trust level. This functionality is implemented directly in the data plane by the P4 Collector. The P4 Collector processes in-band telemetry metadata in two stages: first, it maps the metadata to intermediate values using matchaction tables; then, it aggregates these values to compute the final trust level. By handling this logic at line rate, the P4 Collector supports real-time, policy-driven trust assessment with minimal latency and overhead. After determining the trust level of each device, the P4 Collector selects a data forwarding path based on the user’s preferences; it automatically chooses the most trusted route for the traffic. Subsequently, an in-network control message is generated and sent to the relevant P4 devices, instructing them to update the forwarding behavior for the specific TCP flow. This enables dynamic, trust-aware path selection directly within the network, without relying on external control-plane intervention. We evaluate the performance of our approach by comparing it against a baseline scenario using simple IPv4 forwarding. Our evaluation focuses on three key aspects: (1) the resource utilization of the P4 application on FPGA hardware targets, (2) the maximum achievable throughput under varying numbers of TCP flows, and (3) the performance of multiple concurrent TCP flows under constrained bandwidth, analyzing throughput stability and latency behavior. 1) FPGA Resource Utilization: Table I compares resource usage between baseline IPv4 forwarding and the INT-enhanced design. Enabling INT introduces notable relative increases: CLB LUTs: +43.2% overall, with LUTs as logic increasing by 54.6%, due to added processing of telemetry metadata (e.g., device ID, location). CLB Registers: +43.1%, indicating more flip-flops are needed to manage the state associated with telemetry processing. LUTs as Memory: +23.2%, suggesting additional memory is utilized for storing metadata or intermediate processing results. Block RAM Tiles: Unchanged, indicating INT does not significantly affect BRAM—This is consistent with the design of Vitis Networking P4, where standard metadata and match-action tables are primarily implemented using LUTs and registers, with BRAMs reserved for larger or more complex storage needs [18]. Resource IPv4 Fwd (%) INT (%) Difference (%) CLB LUTs 1.32 1.89 +43.18 LUT as Logic 0.88 1.36 +54.55 LUT as Memory 0.95 1.17 +23.16 CLB Registers 1.09 1.56 +43.12 Block RAM Tile 1.74 1.74 +0.00 TABLE I: IPv4 Forwarding vs INT: Comparison of FPGA Resource Utilization (Post-Synthesis) Despite these relative increases, as shown in the first two columns of Table I, the absolute resource footprint remains modest (under 2%). This highlights the feasibility of integrating INT capabilities into existing FPGAbased SmartNICs without substantial hardware overhead. 2) Maximum Throughput with Varying TCP Flow Counts: Throughput measurements were collected using iperf3, with each test configured to generate a specified number of simultaneous TCP flows and run for five minutes. Table II shows the maximum achievable throughput across different numbers of concurrent TCP flows, comparing simple IPv4 forwarding against the INT-enhanced pipeline. In all cases, the INT version consistently achieves lower throughput, with an average reduction of around 36–38% depending on the number of flows. For instance, with a single TCP flow, throughput drops from 129.37 Mbps to 80.11 Mbps (-38.1%), and even with 32 flows, the reduction remains similarly significant at -35.95%. # Flows Forwarding (Mbps) INT (Mbps) Difference (%) 1 129.37 80.11 -38.07 4 217.88 140.57 -35.48 8 248.88 157.01 -36.91 16 281.92 178.67 -36.63 32 322.96 206.85 -35.95 TABLE II: Maximum Throughput (on average after 4 runs) This performance degradation is primarily due to the packet cloning operation performed at the final hop of the network path. As part of the INT processing logic, each packet is cloned to generate an INT report, which is forwarded to the P4 Collector. This effectively doubles the number of packets that need to be processed at that hop—one continuing to the destination, and one destined for the collector. Since the final switch in this setup is a software-based bmv2 switch, the extra processing load leads to noticeable throughput bottlenecks. However, this overhead would be negligible with a hardware-based target, where packet cloning and forwarding can be handled at line rate. 3) Performance under Bandwidth Constraints: To evaluate system performance under constrained bandwidth with multiple concurrent TCP flows, we ran experiments using iperf3 with eight parallel flows at target rates of 5, 10, and 20 Mbps, each lasting five minutes. These bandwidth levels reflect typical real-world application scenarios—for example, basic web browsing, VoIP, or low-resolution video streaming at 5 Mbps; video conferencing and standard-definition streaming at 10 Mbps; and high-definition streaming or large file transfers at 20 Mbps. This range of conditions allows us to assess system behavior under realistic and progressively more demanding network loads. Figure 7 illustrates the throughput behavior over time, comparing the baseline IPv4 forwarding and our INTenhanced pipeline. Across all bandwidth targets, both configurations maintain relatively stable throughput, with minimal short-term fluctuation. However, we observe that the INT-enabled configuration tends to exhibit slightly higher variance, especially at higher rates (e.g., 20 Mbps), where occasional short dips in throughput are visible. These transient drops, though not frequent, suggest that the additional INT processing introduces minor instability under high aggregate load. Fig. 7: Throughput fluctuation: 8 flows of 5/10/20 Mbps (Single run) To quantify these fluctuations, Figure 8 shows the throughput standard deviation over time for the 10 Mbps case, averaged over four runs. The INT-enhanced setup exhibits slightly higher and more frequent spikes, indicating that INT can introduce brief delivery oscillations, likely due to added processing or queuing overhead. However, it is important to note that the standard deviation does not exceed 1 Mbps in either setup, suggesting that these fluctuations remain relatively limited and do not significantly impact overall throughput stability. In addition to throughput stability, Round-Trip Time (RTT) is a key performance metric, as it directly influences perceived responsiveness and user experience in latency-sensitive applications. Preliminary results for the scenario with eight concurrent TCP flows at 10 Mbps show that the INT-enhanced configuration exhibits consistently higher RTT values than the baseline, suggesting a modest increase in latency due to the additional telemetry processing. This observation is further supported by the Cumulative Distribution Function Fig. 8: Throughput Standard Deviation: 8 flows of 10 Mbps (4 runs) (CDF) of RTT measurements shown in Figure 9, where the INT-enhanced configuration is slightly shifted to the right compared to the baseline. The overall RTT difference remains within 0.2 milliseconds, indicating that the telemetry mechanisms introduce only minimal end-to-end latency overhead. Fig. 9: RTT CDF for 8 flows of 10 Mbps (Single run) Table III shows aggregated RTT statistics for baseline and INT setups over varying bandwidths. To account for varying FABRIC testbed load from other uses, the results were averaged over multiple runs that were conducted throughout the day. INT introduces a slight increase in average RTT—approximately 0.12% at 5 Mbps, 0.20% at 10 Mbps, and 0.45% at 20 Mbps—while RTT jitter remains comparable between setups, with standard deviation values around 2 ms for both. These results confirm that INT imposes a modest processing overhead, causing small but consistent latency increases without significantly affecting RTT stability under fluctuating network conditions and testbed usage. Bandwidth Forwarding RTT (ms) INT RTT (ms) (Mbps) Avg Std Avg Std # Runs 5 84.38 2.11 84.48 2.12 4 10 84.41 2.12 84.58 2.13 4 20 84.48 2.12 84.86 2.00 4 TABLE III: Average RTT and standard deviation across all runs (averaged over averages) VI. CONCLUSION This work explored the use of In-band Network Telemetry (INT) as a scalable and fine-grained alternative to traditional telemetry methods like SNMP and NetFlow. By embedding metadata directly into live traffic and processing it in the data plane, INT enables realtime visibility into network conditions without relying on polling or the control plane. We presented and evaluated two INT implementations for network visibility: one over GRE and another combining path tracing with trustaware routing over TCP. These implementations were deployed on FPGA-based SmartNICs in the FABRIC Testbed, leveraging Alveo U280 accelerator cards and a P4-based toolchain. Our initial experiment (GRE Path Tracing), conducted across two sites in the FABRIC testbed, demonstrated accurate path tracing by marking packets with switch identifiers and collecting per-hop metadata. Performance tests showed that INT processing introduced minimal overhead. These results confirmed that FPGA-based INT can deliver high-resolution telemetry while maintaining acceptable network performance, validating its applicability in modern programmable infrastructures. The experiment on TCP Trust-aware Telemetry extended the evaluation to a realistic hybrid topology across four geographically distributed sites, implementing trust-aware routing via in-band telemetry facilitated by a P4 Collector. FPGA resource usage increased moderately (e.g., +43% LUTs and registers), but overall overhead stayed modest. Throughput dropped by 36– 38% compared to baseline IPv4, mainly due to packet cloning at the final software switch. Still, performance remained stable under varying loads, with only minor fluctuations and a slight RTT increase (up to 0.45%). These results show that INT-enabled telemetry remains practical for multi-site deployments, offering improved visibility with acceptable trade-offs. Future work will focus on reducing packet overhead through Per Flow Aggregation (PFA) [19], which distributes telemetry metadata across multiple packets within the same flow. Efforts will also include deploying FPGAs on end-nodes to enable end-to-end hardwarebased telemetry processing, reducing latency and software overhead. Finally, experiments will be extended to longer paths involving additional sites across the FABRIC testbed to assess scalability and performance in more complex, geographically distributed topologies. ACKNOWLEDGMENT This work has been funded by CIENA, the Dutch Research Council NWO project CATRIN (NWA.1215.18.003) and the HORIZON SNS JU DESIRE6G project (grant no. 101096466). REFERENCES [1] I.-b. N. Telemetry, “In-band network telemetry (int) dataplane specification,” P4. org Applications Working Group, 2020. [2] I. Baldin, A. Nikolich et al., “FABRIC: A National-Scale Programmable Experimental Network Infrastructure,” IEEE Internet Computing, vol. 23, no. 6, pp. 38–47, Nov. 2019. [3] P. Bosshart, D. Daly et al., “P4: Programming protocolindependent packet processors,” ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, pp. 87–95, 2014. [4] F. Hauser, M. H¨ aberle et al., “A survey on data plane programming with P4: Fundamentals, advances, and applied research,” Journal of Network and Computer Applications, vol. 212, p. 103561, Mar. 2023. [5] L. Tan, W. Su et al., “In-band Network Telemetry: A Survey,” Computer Networks, vol. 186, p. 107763, Feb. 2021. [6] “What is a smartNIC and how is the technology shaping modern data centres?” [Online]. Available: https://ubuntu.com/blog/what-is-a-smartnic-and-how-is-thetechnology-shaping-modern-data-centres [7] H. Singh, C. Huang et al., “Int-sdn: Evaluation of various p4 parameters using optical telemetry having reconfigurable data plane on 40 gbps line rate,” in 2019 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PACRIM). IEEE, 2019, pp. 1–6. [8] D. Bhamare, A. Kassler et al., “Intopt: In-band network telemetry optimization for nfv service chain monitoring,” in ICC 20192019 IEEE International Conference on Communications (ICC). IEEE, 2019, pp. 1–7. [9] H. Wang, R. Soul´ eet al., “P4fpga: A rapid prototyping framework for p4,” in Proceedings of the Symposium on SDN Research, 2017, pp. 122–135. [10] S. Bal, Z. Han et al., “P4-based in-network telemetry for fpgas in the open cloud testbed and fabric,” in IEEE INFOCOM 2024IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS). IEEE, 2024, pp. 1–6. [11] “Summary • Alveo U280 Data Center Accelerator Card Data Sheet (DS963) • Reader • AMD Technical Information Portal.” [Online]. Available: https://docs.amd.com/r/en-US/ds963u280/Summary [12] E. S. Team, The ESnet Framework, The Regents of the University of California, Lawrence Berkeley National Laboratory, 12574861 Canada Inc., Malleable Networks Inc., and Apical Networks, Inc., 2022, all rights reserved. [Online]. Available: https://groundsada.github.io/esnet-smartnic-tutorial/ [13] A. Dimoglis, L. C. de Almeida et al., “Lightweight int on the tofino programmable switch,” in Proceedings of the 30th Annual International Conference on Mobile Computing and Networking, 2024, pp. 2430–2436. [14] “FABRIC Portal.” [Online]. Available: https://portal.fabrictestbed.net/about/about-fabric [15] A. Dimoglis, F. Alhamed et al., “In-network control for flow steering,” in 2024 24th International Conference on Transparent Optical Networks (ICTON). IEEE, 2024, pp. 1–4. [16] C. Hesselman, P. Grosso et al., “A Responsible Internet to Increase Trust in the Digital World,” Journal of Network and Systems Management, vol. 28, no. 4, pp. 882–922, Oct. 2020. [17] S. Mazumdar and T. Dreibholz, “Towards a Privacy Preserving Data Flow Control via Packet Header Marking,” in Proc. IEEE HPCC/DSS/SmartCity/DependSys 2022. Hainan, China: IEEE, Dec. 2022, pp. 1509–1516. [18] “Introduction • Vitis Networking P4 User Guide (UG1308) • Reader • AMD Technical Information Portal,” https://docs.amd.com/r/en-US/ug1308-vitis-p4-user-guide. [19] K. Papadopoulos, P. Papadimitriou, and C. Papagianni, “PFAINT: Lightweight In-Band Network Telemetry with Per-Flow Aggregation,” in 2021 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), Nov. 2021, pp. 60–66.