P4Timely: Evaluating Time Synchronization Resilience in Programmable Networks

P4Timely: Evaluating Time Synchronization Resilience in Programmable Networks S´ ergio Rossi Brito da Silva , Francisco Germano Vogt , Marcelo Caggiani Luizelli , Fabricio Rodriguez Cesen , Fl´ avio Geraldo Coelho Rocha , Christian Esteve Rothenberg Universidade Estadual de Campinas, Brazil Universidade Federal do Pampa, Brazil Telefonica Research, Spain Universidade Federal de Goi´ as Abstract—Accurate time synchronization is essential for emerging networked applications that demand low latency, high precision, and coordinated operations, such as those found in data centers, time-sensitive networking (TSN), and distributed systems. In this demo, we introduce P4Timely, a flexible and programmable framework designed to evaluate and prototype time synchronization protocols in real time. Built using P4 and commodity programmable hardware, P4Timely enables users to easily configure synchronization settings through a simple interface, specify network conditions such as delay, jitter, and packet loss, and define whether nodes act as synchronizing or synchronized entities. P4Timely supports dynamic reconfiguration at runtime and provides built-in monitoring tools to assess synchronization accuracy under diverse network conditions. Index Terms—Time-synchronization, Programmable switches. I. INTRODUCTION Time synchronization is fundamental to modern systems that require precise coordination among devices. In data center networks, it enables efficient packet scheduling to mitigate congestions [1]. In mobile networks, synchronization is critical for Time Division Duplex (TDD) operation [2] and enabling successful Radio Access Network (RAN) disaggregation in Open RAN architectures [3]. Many other applications, including cooperative robotics, and autonomous driving [4], also rely on accurate time synchronization. However, due to the inherent drift of clock oscillators and varying operating conditions [5], desynchronization can occur, leading to application failures and significant network performance degradation [2]. To address the desynchronization issues, several protocols have been developed to synchronize devices across networks, each offering different levels of accuracy and precision. The Network Time Protocol (NTP) is one of the most widely used protocols for clock synchronization, providing millisecondlevel accuracy, but it does not synchronize the clock’s frequency or phase [6]. The Precision Time Protocol (PTP) offers significantly higher accuracy, reaching sub-microsecond levels, and synchronizes clock frequency and phase [6]. The generalized PTP (gPTP), a PTP variation, further enhances synchronization accuracy, ensuring reliable and precise coordination of networked devices [7]. Other synchronization protocols, such as HUYGENS, DTP, DPTP, and M-PTP, have been specifically designed for data center networks [8]. Synchronization messages (e.g. NTP,PTP,DPTP) Outside devicesTofino switch User Definitions Synchronization mode Synchronization protocol Packet Error Rate Additional Packet Delay Fig. 1: P4Timely Overview Even when these protocols are applied, synchronization errors may still occur due to network events such as packet drops, which result in lost synchronization information; jitter, which leads to inaccurate clock adjustments; or out-of-order packets, which can cause protocol errors and be disregarded. As a result, synchronization accuracy may be compromised; therefore, evaluating these protocols under varying conditions is essential to understanding their accuracy, robustness, and resilience in real-world scenarios. To evaluate these protocols, some works have been evaluating and deploying them into devices such as programmable switches [9], FPGAs [10], and other specialized hardware platforms, analyzing parameters like accuracy and, in some cases, security aspects. However, these studies often overlook common network issues, such as packet loss, delays, and jitter, which are crucial for accurately assessing protocol performance under realistic conditions. Moreover, they tend to concentrate on only one protocol, limiting the scope for comprehensive comparative analysis. In this work, we propose P4Timely, a new framework to facilitate the evaluation of synchronization protocols using P4-based programmable switches. As depicted in Figure 1, P4Timely is a Tofino-based solution capable of receiving and generating synchronization messages. It can operate as either a master node, synchronizing other devices based on its clock, or a slave node, adjusting its clock according to received synchronization messages. P4Timely supports multiple synchronization protocols, including gPTP, PTP, and NTP, providing flexibility for various network environments. Additionally, it allows users to introduce and configure network events such as 979-8-3315-4345-7/25/$31.00 ©2025 IEEE 318 2025 IEEE 11th International Conference on Network Softwarization (NetSoft) | 979-8-3315-4345-7/25/$31.00 ©2025 IEEE | DOI: 10.1109/NETSOFT64993.2025.11080560 Authorized licensed use limited to: The University of Toronto. Downloaded on August 23,2025 at 15:30:44 UTC from IEEE Xplore. Restrictions apply. packet losses, delays, jitters, and out-of-order packets, enabling a controlled evaluation of synchronization robustness under realistic conditions. Furthermore, synchronization messages can be generated at any time and with any desired frequency, taking advantage of Tofino’s built-in packet generator, ensuring accurate and high-performance testing of different synchronization strategies. Therefore, P4Timely offers significant contributions to the evaluation of the performance, accuracy, and reliability of time synchronization mechanisms II. P4TIMELY ARCHITECTURE & WORKFLOW Next, we provide an overview of how P4Timely is designed, architected, and implemented. Our design principles are grounded in simplicity and flexibility. P4Timely is designed to be easy to use, highly customizable (e.g., allowing the integration of new synchronization protocols), and adaptable to dynamic network conditions in real time. The core idea of synchronization protocols is to use one device to synchronize with another by sending relevant information. Then, P4Timely is designed to be able to act as either the device that synchronizes the others or the synchronized device. So, P4Timely supports sending and receiving synchronization messages and responds accordingly. Additionally, the solution is also capable of sending synchronization timing data to a server for further monitoring or analysis. Next, we present our architecture components, followed by an example of the execution workflow, and then some implementation details. A. Architecture We design our solution to run on the Intel Tofino switch, and the architecture of the solution is described in Figure 2. In this architecture, packets cross the switch through the input to the output ports, passing through the P4Timely control blocks inside the ingress pipeline, the traffic manager, and then the egress pipeline. Furthermore, when our solution needs to send messages periodically, the packets are generated using the Tofino packet generation unit and handled inside the pipelines. When a packet enters the ingress pipeline, it is first identified by the packet identifier block, stating the source, destination, and packet protocol fields. In the presence of any error, the packet is dropped; otherwise, it enters the timing storage and computing block that uses RegisterActions to save the packet ingress timestamp and other crucial protocol fields inside Tofino registers and performs the corresponding computation according to the protocol. When a response packet needs to be sent, the packet goes to the Packet Editor block, where the packet is edited and populated with the appropriate fields of the response packet. Then, in the packet scheduler, the output ports are set and, if required, a new consecutive message is created that will bypass the rest of the pipeline and recirculate inside the Tofino. After the ingress pipeline, the packet is forwarded to the traffic manager, where multicast is configured to deliver the packet to all devices involved in the synchronization process. Subsequently, the packet proceeds to the egress pipeline. Within the packet editor block of the egress pipeline, the Tofino Pipeline Tofino Packet Generation Unit INPUT PORTS Egress Pipeline OUTPUT PORTS Traffic Manager Multicast Network Events Packet Editor Ingress Pipeline Timing Storage and Computing Drop Packet Editor Packet Scheduler Packet Identifier Timing Storage and Computing Fig. 2: P4Timely Architecture. appropriate timestamp is inserted into the packet. The timing storage and computing block then operates similarly to its counterpart in the ingress pipeline, storing the egress timestamp of the packet. Finally, the packet reaches the network events block, which, based on user-defined configurations, may apply actions such as dropping or delaying the packet. B. Workflow The P4Timely workflow is designed to be both simple and flexible. From the user’s perspective, configuration is performed through a settings file. Users can specify the synchronization protocol, define network conditions—such as additional latency, jitter, packet loss, or packet reordering—and designate whether the device operates as a synchronizing or synchronized node. Figure 3 presents an example in which the gPTP protocol is executed by two Tofino devices running P4Timely. These devices communicate with each other and are connected to servers responsible for analyzing the synchronization process. In this scenario, the user selects the protocol along with its parameters – specifically, the interval for peer delay calculation and synchronization phases – as well as the network conditions, such as a packet loss probability of 0.001%. The operation mode is also configured, with the blue Tofino acting as the synchronized node and the red Tofino as the synchronizer, although any protocol-compatible device could fulfill either role. Once the configuration is completed, the workflow initiates, adhering to the gPTP protocol behavior while incorporating the specified network conditions. The blue Tofino initiates the synchronization process by sending a request message to the red Tofino and then waits for a response. Upon receiving the request, the red Tofino identifies the protocol and replies with the appropriate response messages. Based on the user-defined configuration, the red Tofino subsequently transmits synchronization messages to the blue Tofino at regular intervals. For monitoring purposes, P4Timely 319 Authorized licensed use limited to: The University of Toronto. Downloaded on August 23,2025 at 15:30:44 UTC from IEEE Xplore. Restrictions apply. Synchronized node Synchronizer node Pdelay_Req Pdelay_Resp Pdelay_ Resp_Follow_Up Sync Sync Follow_Up Sync Follow_Up Sync Peer delay calculation phase Synchronization Phases Monitoring server Monitoring server Info_sent_msg Info_rcvd_msg Info_rcvd_msg Info_rcvd_msg Info_rcvd_msg Info_rcvd_msg Info_rcvd_msg Info_rcvd_msg Info_sent_msg Info_sent_msg Info_sent_msg Info_sent_msg Info_sent_msg Info_sent_msg Fig. 3: P4Timely gPTP workflow example. generates a separate packet for each message sent or received, which is forwarded to the connected monitoring server. This packet includes the protocol identifier and the corresponding timestamp – taken from the ingress pipeline if the message was received, or from the egress pipeline if the message was sent. Once synchronization is established, both nodes transmit their data to the monitoring server to evaluate synchronization accuracy. Thereafter, synchronization messages are exchanged at the frequency defined in the configuration file. If necessary, network conditions can be dynamically modified at runtime to reflect changes in the experimental setup. III. DEMONSTRATION Setup. We evaluate the performance of P4Timely using two Tofino Switches (Edgecore Wedge 100BF-32X) and one server (Intel Xeon E5-2620v2, dual-port 10G Intel X540-AT2 NIC, and 64GB of RAM running Ubuntu 20.04). The two Tofino switches are connected via a 100G QSFP28 interface, while the connection within the server is via a 10G SFP+ interface. The packets generated by our solution depend on the protocol. Limitations. P4Timely is continuously updated. Until now, only some protocols are compatible: PTP, gPTP, DPTP, and NTP. Furthermore, although it supports real-time network condition modification, P4Timely does not support real-time protocol change. P4Timely also does not yet have an interface for defining new protocols (e.g., customized). Regarding the role as grandmaster, although Tofino switches typically have internal oscillators capable of acting as master clocks in synchronization processes, external references disciplined by GPS are recommended for highly accurate timing requirements, such as those demanded by the Open RAN fronthaul. IV. FINAL REMARKS This work introduces P4Timely1, a novel framework designed to evaluate time synchronization protocols under a wide range of network conditions. P4Timely supports multiple protocols, such as NTP and PTP, and enables the emulation of 1https://github.com/SergioRBDS/P4Timely.git Sinchronizer Sinchronized Monitoring Server Netsoft desk Remote scenario Tofino A Tofino B Synchronization messages Fig. 4: Demonstration setup to be presented in Netsoft. various network impairments, including latency, jitter, packet loss, and packet reordering. These capabilities make it a powerful tool for analyzing and comparing the performance of different time synchronization mechanisms. As future work, we plan to extend the framework to support additional protocols and integrate P4Timely into more complex network topologies, enabling more thorough evaluations in realistic environments. ACKNOWLEDGMENT This work was supported by Ericsson Telecomunicac¸ ˜ oes Ltda. , and by the Sao Paulo Research Foundation (FAPESP) , grant 2021/00199-8 (CPE SMARTNESS) , 2024/16207-8, 2020/05183-0 and 2023/00794-9. Also, it was supported by Foundation for Research of the State of Rio Grande do Sul (24/2551-0001394-6). This study was also partially funded by CAPES, Brazil-Finance Code 001, and CNPq (404027/2021-0). Also has been partially supported by the European Union’s Horizon Europe project under grant agreement No. 101070473 (FLUIDOS). REFERENCES [1] L. Li et al., “High-precision time synchronization based on timestamp mapping in datacenter networks,” Electronics, vol. 14, no. 3, p. 610, 2025. [2] C. Hausl et al., “Mobile network testing of 5g nr fr1 and fr2 networks: Challenges and solutions,” in 2022 16th European conference on antennas and propagation (EuCAP). IEEE, 2022, pp. 1–5. [3] A. Maamary et al., “Synchronization plane in o-ran: Overview, security and research directions,” IEEE Communications Magazine, 2024. [4] F. Li et al., “An enhanced method for nanosecond time synchronization in ieee 1588 precision time protocol,” Processes, vol. 11, no. 5, p. 1328, 2023. [5] K. Balakrishnan et al., “Clock synchronization in industrial internet of things and potential works in precision time protocol: Review, challenges and future directions,” International Journal of Cognitive Computing in Engineering, vol. 4, pp. 205–219, 2023. [6] S. Duan et al., “Research and testing of clock synchronization for 5g-tsn industrial control network,” in 2024 6th EEI. IEEE, 2024, pp. 867–874. [7] ——, “Comparison and testing of time synchronization accuracy between ieee 1588v2 and ieee 802.1 as,” in Proceedings of the 2023 13th ICCNS, 2023, pp. 300–305. [8] K. He et al., “Multi-hop precision time protocol: An internet applicable time synchronization scheme,” in NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium. IEEE, 2022, pp. 1–9. [9] P. G. Kannan et al., “Precise time-synchronization in the data-plane using programmable switching asics,” in Proceedings of the 2019 ACM Symposium on SDN Research, 2019, pp. 8–20. [10] Y. Geng et al., “Exploiting a natural network effect for scalable, finegrained clock synchronization,” in 15th USENIX NSDI 18, 2018, pp. 81–94. 320 Authorized licensed use limited to: The University of Toronto. Downloaded on August 23,2025 at 15:30:44 UTC from IEEE Xplore. Restrictions apply.