P4-TAS：基于 P4 的 TSN Time-Aware Shaper

Time-critical applications in industrial automation and automotive systems rely on networks that provide deterministic guarantees such as low latency, minimal jitter, and virtually zero packet loss. To meet these stringent requirements, two complementary technologies have emerged: Time-Sensitive Networking (TSN) and Deterministic Networking (DetNet). TSN is a suite of IEEE 802.1 standards that enhances Ethernet to support real-time communication by introducing mechanisms for traffic shaping [ 1, 2, 3 ] and reliability [ 4 ]. In contrast, DetNet is a Layer 3 technology standardized by the IETF that extends these capabilities to routed networks by enabling bounded latency and high reliability across multiple IP hops [ 5 ].

Scheduled traffic is a concept in TSN where transmission times of talkers are coordinated to avoid queuing in intermediate nodes so that frames traverse the network with minimal delay. This coordination is called scheduling and yields a network-wide schedule that ensures deterministic forwarding. Various traffic shaping mechanisms, such as Credit-Based Shaper (CBS), Asynchronous Traffic Shaper (ATS), and the Time-Aware Shaper (TAS) exist in TSN. Among them, the TAS stands out by leveraging a Time Division Multiple Access (TDMA)-like approach to protect scheduled traffic from interference, e.g., by best-effort flows, thereby ensuring low latency and bounded delay. This is achieved through transmission gates which periodically open and close queues. Further, Per-Stream Filtering and Policing (PSFP) is a TSN mechanism that combines rate and time-based policing to drop out-of-schedule frames.

DetNet leverages TSN concepts in combination with technologies such as MPLS or IP. In DetNet deployments, TSN can be employed as a sub layer to provide deterministic forwarding in sub networks. In practice, TSN implementations are typically hardware-based and optimized for bandwidths up to \qty 1. However, DetNet targets broader use cases, including high-throughput applications and data center backbones. This hierarchical composition allows for scalable designs that combine the high-speed capabilities of DetNet with the precise timing mechanisms of TSN. The integration of both technologies enables sophisticated traffic shaping and reliability mechanisms across backbone infrastructure.

The contribution of this paper is manifold. We present P4-TAS, a P4-based implementation of the TAS on the Intel Tofino™ 2 switching ASIC that enables TSN-compliant shaping and policing in the data plane. Our design introduces a novel mechanism for periodic queue control using a continuous stream of internally generated TAS control frames. It builds upon a mechanism from our prior P4-PSFP work [ 6 ] which uses the internal packet generator as a clock source. P4-TAS also incorporates PSFP and includes an MPLS/TSN translation layer [ 7 ], enabling TSN traffic shaping to be applied to DetNet flows at line rates up to 400 Gb/s. A key contribution of this work is the identification and quantification of internal processing delays that affect scheduling precision. Such delays are typically undocumented in commercial TSN-capable switches but are crucial for accurate traffic scheduling [ 8, 9 ]. Our implementation reveals multiple delay sources within the data plane and provides corresponding measurements on a nanosecond scale. We demonstrate that our approach achieves internal delays orders of magnitude smaller than those reported for some commercial platforms [ 9 ], offering transparency. Finally, we evaluate the scalability of P4-TAS and compare it to available TAS implementations.

The rest of the paper is structured as follows. In Section II, we provide background information on TSN, DetNet, and the P4 programming language. In Section III, we review related work on combining TSN and DetNet systems, and on simulations and hardware implementations of those technologies. Section IV introduces the P4 implementation, including our system architecture and the P4-TAS mechanism. In Section V, we evaluate internal delays, measure the transmission gate accuracy externally, analyze the scalability, and compare P4-TAS to other implementations. Finally, in Section VI, we conclude the paper.

In this section, we provide technical background on TSN, DetNet, and the P4 programming language.

We first give a brief overview of TSN, explain scheduled traffic, and then summarize the concepts of the TAS and PSFP.

TSN is a suite of IEEE 802.1 standards that augment traditional Ethernet to support deterministic communication with strict Quality of Service (QoS) guarantees. TSN networks are built from interconnected bridges and end stations. A data flow, referred to as a TSN stream, originates from a talker (sending station) and is directed to one or more listeners (receiving stations). A TSN stream is identified based on its VLAN tag, its Layer 2 destination address, and optionally other header fields [ 4 ]. Before a stream is allowed to transmit, it has to undergo admission control [ 4 ]. This process involves the talker advertising its traffic characteristics, e.g., latency requirements, through a stream descriptor. The network then decides whether to admit the stream by evaluating resource availability and making reservations accordingly.

In TSN, streams can be scheduled, i.e., their sending times at talkers are coordinated such that frames experience minimal delay at intermediate bridges. This coordination is computed offline and yields a network-wide schedule. The calculation of such schedules is outside the scope of this work. More information on scheduling in TSN can be found in a survey by Stüber et al. [ 10 ]. Time synchronization on a sub-microsecond scale is critical for scheduling in TSN. For that purpose, protocols like the Precision Time Protocol (PTP) are employed [ 11 ].

Scheduled streams in TSN are typically assigned the highest priority and must be protected from lower-priority traffic, e.g., best-effort traffic. This ensures that scheduled frames reach each intermediate node at their scheduled times. TAS and PSFP are mechanisms to protect scheduled traffic using gating mechanisms. Both are illustrated in Figure 1 and explained in the following.

The TAS, standardized in IEEE Std 802.1Qbv [ 1 ], provides time-based shaping at the egress. Each egress port provides eight FIFO queues associated with frame priorities from the VLAN tag [ 12 ]. These queues are controlled by transmission gates which are controlled by a gate control list (GCL). A GCL is a periodic sequence of entries, each specifying a time slice and a corresponding gate state. In the TAS, we call this the transmission GCL (tGCL). Each tGCL entry specifies a duration and an eight-bit vector indicating which of the eight transmission gates are open or closed. Frames in queues with an open transmission gate are transmitted in FIFO order while frames in queues with a closed transmission gate remain buffered. After all entries have been processed, the sequence repeats periodically with a cycle length h h.

PSFP, standardized in IEEE Std 802.1Qci [ 3 ], enforces per-stream conformance at the ingress by combining rate policing with time-based policing. In this way, PSFP ensures adherence to the resource bounds established by admission control. While rate policing is a well-known mechanism, time-based policing targets scheduled traffic and is the focus of this work. For time-based policing, each stream is associated with a stream gate controlled by a periodic GCL which we call the stream GCL (sGCL). The sGCL defines the gate state over time and thereby the admitted transmission windows of the stream. Frames arriving outside their admitted window are dropped immediately, i.e., before queuing, preventing them from consuming reserved resources.

In Figure 1, two streams enter the TSN bridge. Based on their sGCLs, the first stream gate is open while the second is closed. Accordingly, frames of stream 1 are forwarded while frames of stream 2 are dropped by PSFP. Both streams then share the same egress port queues which are controlled by the tGCL. Here, only the first transmission gate is open, so only frames stored in queue 1 are transmitted.

Stream gates in PSFP differ from transmission gates in TAS in three ways. First, stream gates apply per stream whereas transmission gates apply per egress port and queue. Second, an sGCL entry defines the state of a single stream gate while a tGCL entry defines the states of all eight queues. Third, closed stream gates drop frames before queueing while closed transmission gates buffer frames in the queue.

The DetNet architecture enables real-time applications with extremely low packet loss rates and a bounded latency [ 5 ]. It is standardized by the IETF DetNet working group. DetNet operates on the networking, e.g., IP, layer and provides QoS and reliability to the lower layer, e.g., to MPLS and TSN. DetNet is applicable to networks under a single administrative control, e.g., to private WANs, or campus-wide networks.

The bounded latency in DetNet is achieved by eliminating packet loss resulting from queue congestion within a node. For that purpose, bandwidth and buffer resources are reserved at each node. Resource reservations can be made using the Resource reServation Protocol (RSVP). For traffic engineering within DetNet, mechanisms defined by the IEEE 802.1 working group such as the TAS are applicable.

The DetNet architecture separates the data plane functions into two sub-layers. First, the service sub-layer provides DetNet QoS mechanisms such as bounded latency and service protection, e.g., by adding sequence number information to packets. Second, the forwarding sub-layer provides connectivity between Detnet service sub-layer processing nodes [ 13 ]. Various data plane technologies for DetNet exist, e.g., DetNet over MPLS [ 13 ], and DetNet over IP [ 14 ]. With DetNet over MPLS, the forwarding and service sub-layers are identified by MPLS labels, called the Forward label (F-Label), and the Service label (S-Label). One or more F-Labels are used to forward the packet through the DetNet domain. The S-Label follows after the F-Labels and is used to identify the DetNet flow. Based on the identified DetNet flow, QoS mechanisms are applied. Further, a DetNet control word (d-CW) follows after the MPLS stack. This control word contains a sequence number for protection mechanisms of DetNet.

Standards exist that interconnect TSN networks using the DetNet MPLS data plane [ 15, 7 ]. For DetNet MPLS over TSN, DetNet flows are identified based on the S-Label at the DetNet / TSN domain border and are translated into TSN streams. For that purpose, IEEE Std 802.1CBdb [ 16 ] defines an MPLS DetNet flow identification which identifies the S-Label and pushes a new VLAN ID. Then, TSN stream identification is applied based on the new VLAN ID. With those interconnected data planes, TSN services such as the TAS and PSFP can be applied to DetNet flows.

Programming Protocol-independent Packet Processors (P4) is a domain-specific programming language to implement custom data planes in P4-programmable switches [ 17 ]. A P4 program can manipulate packets and make forwarding decisions to implement custom algorithms. In the following, we describe the concepts of the P4 pipeline, the packet generator, and a feature called advanced flow control (AFC). A survey by Hauser et al. provides more information on P4 [ 18 ].

P4-programmable switches are called targets and implement a specific architecture. The Intel Tofino™ 2 switching ASIC is a hardware-based P4 target. Typically, a P4 architecture follows a pipelined structure. The pipeline of the Tofino Native Architecture (TNA), the architecture used by the Intel Tofino™, is illustrated in Figure 2.

The TNA consists of an ingress block and an egress block, each with a programmable parser, control blocks, and a deparser. After processing frames in the ingress control block, frames are queued in the traffic manager component of the TNA. This component is configurable but not programmable [ 19 ].

Control blocks in a P4 program define the logic of the algorithm. They leverage metadata for packet processing. A P4 program defines two different types of metadata. First, user-defined metadata stores information during the pipeline processing. Second, intrinsic metadata contains information given by the architecture, e.g., the ingress timestamp of a frame, and the ingress port. Control blocks are composed of match+action tables. The concept of a MAT is illustrated in Figure 3 [ 20 ] and explained in the following.

In a MAT, selected packet header fields and metadata form a composite key. Each packet is matched in the MAT according to the selected key fields. On a match in the table, an associated action is executed which can manipulate packet data or make a forwarding decision. The data plane defines the structure of a MAT, i.e., the key fields, and the actions. However, the content of these MATs is filled by the control plane. Further, registers are a commonly used feature in P4 that allow for stateful processing of packets.

P4 control blocks support logical and simple arithmetic expressions but do not support loops to maintain line rate processing. To enable iterative algorithms, packets can be recirculated. Modified headers from the first pass are available in the second. Recirculation introduces delay and requires dedicated ports. Architectures like the TNA offer internal recirculation ports, or can provision physical ports for recirculation.

The Intel Tofino™ natively supports time synchronization using PTP [ 11, 19 ]. Further, Kannan et al. [ 21 ] propose a data plane implementation of PTP which can be leveraged to achieve high-precision time-synchronization.

The TNA provides an internal packet generator which can be configured to generate packets through a dedicated internal port. Generated packets are processed in the pipeline. Multiple applications with different triggers, such as a periodic trigger, can be configured to trigger packet generation. Further, the packet generator can be configured to generate B B batches with a batch size of K K packets each to enable packet bursts. A generated packet contains a packet generation header added by the traffic generator. This packet generation header identifies the application, the batch number, and the packet number in the batch [ 19 ].

A feature specific to the Intel Tofino™ 2 is advanced flow control (AFC) which enables control over the queues, i.e., dispatching or holding back frames, of an egress port in the traffic manager. The queue state is manipulated by writing an AFC value into a packet’s intrinsic metadata during pipeline processing. As this operation must be triggered by an incoming packet, each queue state change is initiated by packet arrival. A single packet can control exactly one queue. The AFC value is computed based on the egress port, queue ID, and the desired queue state. Importantly, the controlled queue does not need to correspond to the egress port or queue assigned to the processed packet itself.

In this section, we review related work on the combination of TSN and DetNet systems, and on simulations and hardware implementations of those technologies.

The integration of TSN and DetNet has received considerable attention in recent years due to their critical role in facilitating ultra-low latency communication in 5G networks. Nasrallah et al. [ 22 ] provide a comprehensive overview of TSN and DetNet technologies, emphasizing their importance for time-critical applications in 5G environments. Building on this foundation, Abuibaid et al. [ 23 ] conduct a case study that measures the performance of TSN and DetNet in a practical 5G setting. Furthermore, Wüsteney et al. [ 24 ] propose a latency model for time-sensitive communication traversing networks that integrate TSN and DetNet. Menendez et al. [ 25 ] present a software-based implementation of the TAS using XDP and eBPF. Further, they integrate TSN functionality into DetNet environments with a MPLS over UDP/IP data plane. While their open-source implementation represents a significant step towards TSN / DetNet integration, their evaluation does not consider internal timing behavior and only measures traffic rates up to \qty 600.

Despite these advances, challenges remain in realizing efficient hardware implementations that integrate TSN and DetNet functionalities while identifying and quantifying internal timing behaviour which this work aims to address.

Numerous simulation frameworks have been developed to model TSN [ 26, 27 ], DetNet [ 28 ], or both [ 29 ]. In particular, Addanki et al. [ 29 ] offer a simulator that integrates building blocks for DetNet at the network layer and TSN at the link layer. Polverini et al. [ 30 ] describe a P4-based DetNet implementation for the BMv2 software target leveraging an SRv6 data plane for reliability. While such simulations are valuable for exploring the interaction between TSN and DetNet, they do not fully address the challenges of real-world deployment. Implementing time-sensitive mechanisms in hardware introduces additional complexity due to resource constraints and timing precision requirements. Ahmed et al. [ 31, 32 ] provide FPGA-based implementations of the CBS and ATS of TSN, while we presented a P4-based hardware implementation of the PSFP mechanism on an ASIC [ 6 ].

Several commercial hardware platforms support TAS and PSFP. NXP’s automotive-grade SJA1105TEL switch ASIC provides eight egress queues per port with a time granularity of \qty 200. This ASIC supports time-gated transmission of up to 1024 flows [ 33, 34 ]. Similarly, Microchip’s SparX-5i [ 35 ] and PD-IES008 [ 36, 37 ] families expose time interval configuration with nanosecond granularity and support up to 10,000 tGCL entries. These platforms demonstrate that TAS is available in hardware, but published information typically stops at high-level feature descriptions such as queue counts, GCL sizes, or time granularity. A summary of these capabilities is provided in Section V-D and compared against P4-TAS in Table II. Although these platforms claim nanosecond configuration granularity, reliable queue updates at this scale are not feasible in practice due to undocumented internal delays and hardware limitations. A recent work by Eppler et al. [ 9 ] quantified such undocumented timing behavior inside commercial TSN switches. Their measurements reveal internal scheduling and gate transition delays in the order of hundreds of nanoseconds to several microseconds which is significant for schedule synthesis and can lead to missed transmission windows if not accounted for.

In this work, we present a hardware implementation of selected TSN and DetNet mechanisms on a programmable ASIC. Unlike prior academic or commercial platforms, our design enables a transparent evaluation of internal delays, thereby offering deeper insights into their behavior and integration in real systems.

In this section, we describe the implementation of the P4- TAS switch incorporating the PSFP and the TAS mechanism on the Intel Tofino™ 2 switching ASIC. First, we describe the system architecture and integration into DetNet domains. Then, we present the implementation of the TAS mechanism in P4. Finally, we explain improvements to the P4-PSFP implementation. The source code is publicly available on GitHub [ 38 ].

The P4-TAS implementation is designed as an Ethernet switch that provides TSN functionality. It performs TSN stream identification as defined in IEEE Std 802.1CB [ 4 ] and applies traffic shaping with the TAS as well as policing with PSFP. These mechanisms allow P4-TAS to operate natively inside a TSN domain and provide deterministic forwarding for TSN streams. In addition to its role within a pure TSN network, P4-TAS can also act as a border element between a DetNet domain and a TSN domain. In this case, it processes incoming MPLS-encapsulated DetNet flows and translates them into TSN streams based on IEEE Std 802.1CBdb [ 16 ]. This enables DetNet to leverage the TSN sub-layer for scheduling and shaping. The integration scenario is illustrated in Figure 4.

At the ingress to the TSN domain (step 1), the P4-TAS switch translates DetNet flows into TSN streams by pushing a VLAN tag based on the S-Label. Afterwards, TSN stream identification is applied using the destination MAC address and the pushed VLAN tag (step 2). Subsequently, the identified TSN stream is subjected to traffic shaping and policing with TAS and PSFP (step 3), and the frame is forwarded through the TSN domain. At the egress (step 4), the VLAN tag is removed to restore the original DetNet flow.

The TAS defined in IEEE Std 802.1Qbv periodically opens and closes multiple egress queues according to a tGCL. Periodic behavior, such as in a GCL, is not natively supported by P4. Further, queue states on the Intel Tofino™ 2 can be controlled with AFC, but such changes can only be triggered by the arrival of a frame, and each frame can update only a single queue of one egress port. To implement the TAS under these constraints, P4-TAS combines three building blocks: a periodic time model for the tGCL, a dedicated stream of continuous TAS control frames to trigger AFC updates, and a tGCL MAT that maps control frames to queue state changes. They are described in the following. Finally, an overview is given of how they operate together in the pipeline.

Modeling the periodicity of GCLs in programmable P4 hardware is challenging since periodic behavior is not natively supported. Timestamps in the Intel Tofino™ are absolute, i.e., their values continuously increase, whereas the time slices in GCLs are relative and follow a periodic pattern. Thus, each frame’s absolute timestamp must be mapped to its corresponding position within the current GCL period. While this could be achieved with a modulo operation, such operations are too complex to perform at line rate in the data plane.

In our previous work [ 6 ], we described an approach to model the periodicity of sGCLs in a P4-based PSFP implementation. In this approach, we leveraged the internal packet generator of the Intel Tofino™ as a clock source. At the end of each GCL cycle, the internal packet generator generates a period-completion frame. The ingress timestamp of this frame is stored in a register and references the timestamp of the last completed period. For all other frames, i.e., non-period-completion frames, the ingress pipeline subtracts this stored value from the frame’s absolute timestamp to obtain a relative timestamp within the ongoing sGCL cycle. In this way, every frame is mapped into a relative time window of one cycle length. The absolute hardware clock of the switch can be used consistently while the sGCL is treated as a repeating list of entries. We leverage this mechanism to implement the periodicity of tGCLs for the TAS. However, unlike sGCLs in PSFP, where each sGCL entry opens or closes a single stream gate, i.e., admits or drops a frame, a tGCL entry must control multiple transmission gates by opening and closing queues. Thus, the periodicity mechanism serves as the basis for the TAS, but additional mechanisms are required to continuously update the gate states of all egress queues during each tGCL entry.

Queues on the Intel Tofino™ 2 can be opened or closed by processing intrinsic AFC metadata of a frame in the pipeline. The controlled queue does not need to correspond to the egress port or queue assigned to the frame itself. A single frame can control exactly one queue of one port of the switch. In this section, we explain the concept of timely control of all queues which implements the tGCL.

To implement tGCL queue state changes with AFC on the Intel Tofino™ 2, each queue state update must be triggered by the arrival of a frame. For this purpose, P4-TAS employs the internal packet generator to continuously produce TAS control frames. These frames are generated in back-to-back batches of eight so that each queue is assigned one frame. Each TAS control frame carries intrinsic metadata with the identifiers of the queue and egress port it controls. Upon arrival, its position in the tGCL cycle is calculated based on the frame’s arrival timestamp as described in Section IV-B1. Then, the position in the tGCL cycle and the intrinsic metadata are matched against the tGCL MAT which specifies whether the corresponding queue should be opened or closed at that point in time.

The TAS control frames are minimally sized (\qty 64B) and contain no payload beyond intrinsic metadata. They are continuously generated with a minimal inter-arrival time to ensure that queue states follow the configured tGCL precisely. This mechanism does not consume bandwidth for user traffic since the internal packet generator and a dedicated internal port are exclusively used for the TAS control traffic. In practice, there is a short delay between consecutive TAS control frames. Since a queue can only change state when its associated control frame arrives, delayed opening or closing may occur. We evaluate the impact of this behavior in Section V-A3.

The tGCL is encoded as a MAT in the egress pipeline and is shown in Figure 5. TAS control frames from Section IV-B2 are matched against it.

Each entry in the MAT corresponds to one of the eight queues of a tGCL entry, i.e., eight MAT entries per tGCL entry are required. The entry specifies whether a queue should be currently open or closed. The lookup key is composed of the relative timestamp in the tGCL which is calculated according to Section IV-B1, the queue identifier, and the egress port. The MAT action writes a precomputed AFC value which encodes the queue, the egress port, and the state, into the frame’s intrinsic metadata. This triggers the queue state update. The queue state update has a small delay which is evaluated in Section V-A2.

The mechanisms in Section IV-B1 – IV-B3 operate together within the P4-TAS pipeline as illustrated in Figure 6.

First, generated period-completion frames mark the boundaries of the tGCL and sGCL cycles and maintain the reference for relative timestamp calculation in step 1. Here, a single frame is generated at the end of each period with duration h h, and its timestamp of the j j -th period t j h t^{h}_{j} is stored in a register for subsequent processing. Afterward, those frames are dropped.

Second, TAS control frames are continuously generated by the packet generator with a minimal inter-arrival time. For those frames, the timestamp relative to the last elapsed period of the tGCL is calculated in step 2. This timestamp is used to match the TAS control frame to the corresponding entry of the tGCL MAT. After queuing the TAS control frame in a dedicated queue of the traffic manager, the AFC mechanism is applied in the egress in step 3. Here, the corresponding queue is opened or closed based on the current tGCL entry using the MAT described in Section IV-B3. Afterward, the frames are dropped.

Third, TSN data frames are policed in the ingress pipeline by the PSFP mechanism to enforce conformance with admitted rates and transmission times. For those frames, the timestamp relative to the last elapsed period of the sGCL is calculated in step 4, and PSFP is applied in step 5. In this step, the frames are policed and either dropped or queued according to their priority. The queue states are either in an open or a closed state based on the tGCL. Frames are forwarded in a FIFO manner as soon as their queue opens.

The Intel Tofino™ 2 ASIC used in this work provides hardware support for IEEE 1588 PTP [ 19 ]. PTP enables sub-microsecond synchronization accuracy by exchanging timestamped messages between network nodes to align their local clocks. This functionality can be implemented entirely with on-board resources of the ASIC [ 19 ]. However, the P4- TAS implementation does not include a PTP synchronization mechanism since integrating such functionality is beyond the scope of this work and not required for the evaluations presented in this paper. Prior work has demonstrated that precise PTP synchronization on Tofino-based switches can be achieved by combining hardware timestamping with control plane clock management [ 39, 19 ] or even entirely within the data plane [ 21 ]. Nevertheless, the TAS functionality and internal delay characteristics we evaluate are largely independent of network-wide time alignment. Future work will explore the integration of P4-TAS into a synchronized multi-hop TSN testbed to enable coordinated, time-aware scheduling across multiple devices.

P4-TAS incorporates the previous P4-PSFP implementation [ 6 ]. The PSFP components stream filter, stream gate, and flow meter are implemented according to IEEE Std 802.1Qci [ 3 ]. The functionality of P4-PSFP has been extensively evaluated in [ 6 ]. In this section, we describe improvements to P4-PSFP that eliminate recirculation, and increase the time resolution of GCLs.

P4-PSFP recirculates TSN traffic for two reasons. First, calculating the relative position in a sGCL does not fit in a single pipeline iteration. Second, the optional maximum frame size filter defined in IEEE Std 802.1Qci [ 3 ] requires frame size info only available in the egress block while drops must occur in the ingress block. Thus, recirculation is necessary, adding a known constant delay. For P4-TAS, we ported the implementation of P4-PSFP from Intel Tofino™ to Tofino™ 2 where the larger pipeline allows the GCL position to be computed in one pass. We also removed the optional maximum frame size filter, eliminating the need for recirculation. If required, the filter can be re-added, at the cost of a recirculation.

sGCL entries in P4-PSFP are modeled as MAT entries with the range matching type. However, the range matching type is limited in the TNA and only \qty 20bits can be matched. Timestamps in the TNA are \qty 48bits with nanosecond granularity. Therefore, in P4-PSFP, \qty 20bits are cut out of the middle of the timestamp to enable the range matching type and enable an appropriate time resolution. Thus, GCLs have a minimum resolution of \qty 2 and a maximum resolution of approximately \qty 4. GCL entries with a lower resolution, or GCLs that last longer cannot be defined in P4-PSFP. However, due to hardware limitations, P4-TAS requires small intervals between tGCL entries where a minimum resolution of \qty 2 is too large. This is further elaborated in Section V-B3. Therefore, we employ an algorithm called range-to-ternary conversion [ 40 ] to increase the resolution of time slices. This algorithm allows to model a single range entry using multiple ternary entries.

The algorithm takes an integer range [ L, R ] [L,R] representing a time slice and breaks it down into the smallest possible set of prefixes that collectively cover the entire range. It does this by repeatedly selecting the largest prefix starting at the current lower bound that remains fully within the range. These selected blocks together ensure complete coverage of the interval [ 40 ]. Some example conversions are given in Figure 7. Each block in Figure 7 denotes a ternary entry that covers parts of the range. The ∗ * denotes a “don’t care” bit, meaning the bit can take either value 0 or 1.

In a GCL, time slices are defined as consecutive, non-overlapping ranges. Under these constraints, Sun [ 41 ] has proven that the solution is both correct and unique.

With this algorithm, GCLs have a resolution of \qty 1 \nano to \qty 78. The upper bound of \qty 78 exceeds the requirements of GCL periods by far and is not necessary in TSN networks. However, the full \qty 48bits timestamp range is available for matching, and reducing the resolution does not have a benefit. The number of ternary table entries required by this conversion algorithm to model GCLs is evaluated in Section V-C.

In this section, we evaluate the P4-TAS implementation. First, we identify and quantify internal delays including the traffic generator accuracy, the queue opening delay, and the TAS control frame delay. Next, we externally measure the duration of tGCL entries and introduce gate switching intervals (GSIs) to mitigate transitional behavior between tGCL entries resulting from the queue opening delay. Then, we assess the scalability of P4-TAS by analyzing the number of supported tGCL and sGCL entries, and the maximum number of streams for identification of DetNet and TSN flows. Finally, we compare P4-TAS to available TAS implementations.

Most TSN scheduling approaches assume ideal switch behavior and neglect implementation-specific effects such as internal delays or jitter. Stüber et al. [ 8 ] address this by proposing a scheduling algorithm that accounts for such inaccuracies. They emphasize the need to consider hardware-induced variability in TAS configurations. While their work focuses on scheduling-level robustness, we take a complementary approach by identifying and quantifying undocumented internal delay sources in a hardware implementation. These findings can support the design of more accurate and robust schedules.

Franco et al. [ 42 ] profile the latency behavior of the Intel Tofino™ ASIC. They analyze factors such as parsing depth and MAT complexity. However, beyond processing delays, additional delay sources exist within TSN bridges that are not typically disclosed [ 9 ]. We quantify several of them in our P4-TAS implementation on the Intel Tofino™ 2 platform. While the measurement results are specific to the P4-TAS implementation on the Intel Tofino™ 2 ASIC, the sources of those delays are also present in other hardware [ 9, 35 ].

First, we evaluate the accuracy of the internal traffic generator which affects the timing of period-completion frames. We then analyze the queue opening delay of the AFC mechanism. Finally, we measure a delay introduced by the packet generator used for TAS control frames, and give a summary of the measurements.

P4-TAS uses the internal packet generator to signal the completion of each tGCL cycle with a configured period h h as described in Section IV-B1. A period-completion frame is generated every h h ns, and the timestamp of the j j -th period, denoted as t j h t^{h}_{j}, is stored in a register. Due to limitations of the packet generator, small timing deviations may occur. To quantify this effect, we measure the difference between the timestamps of consecutive period-completion frames, i.e., t j + 1 h t^{h}_{j+1} and t j h t^{h}_{j}, relative to the configured period h h. The deviation δ ^ TG \hat{\delta}_{\text{TG}} is defined in Equation 1: δ ^ TG \displaystyle\hat{\delta}_{\text{TG}} = (t j + 1 h − t j h) − h. \displaystyle=(t^{h}_{j+1}-t^{h}_{j})-h. (1)

This value is recorded as a time series in a register in the data plane. Based on use cases identified by Stüber et al. [ 43 ], we select representative periods h h: \qty 500 for factory automation, \qty 2 for industrial isochronous traffic, and \qty 128 for aerospace applications. Additionally, we include \qty 10, \qty 499 and \qty 501 to analyze edge cases and artifacts, and \qty 400 since this period is used for the evaluation in Section V-B. For each period, we record the timestamps of 16,000 period-completion frames. Figure 8 shows the results.

The boxplot in Figure 8 shows the median as a red line, the first and third quartiles as the edges of the box, and whiskers that extend to 1.5 times the interquartile range. Values outside this range are plotted as outliers. A positive δ ^ TG \hat{\delta}_{\text{TG}} indicates that the actual period exceeded the configured value by δ ^ TG \hat{\delta}_{\text{TG}} while a negative value means it was shorter by that amount.

Most periods show deviations below δ ^ TG = \qty ​ 2 \hat{\delta}_{\text{TG}}=\qty{2}{}, with all outliers staying within ± \pm \qty 11. An exception occurs at a period of \qty 400 and \qty 500 which shows a wider spread with less outliers. We attribute this to internal scheduling behavior of the packet generator in the Intel Tofino™ switching ASIC. Shifting the period slightly, e.g., to \qty 499 or \qty 501, results in deviations similar to the other configurations.

Although these deviations are small, they can impact the periodicity computation. If a period-completion frame arrives late, the computed relative position within the current GCL cycle may exceed the period h h, which would index an out-of-period entry. To ensure that all frames are assigned to a valid tGCL entry, P4-TAS clamps any calculated position ≥ h \geq h to the final entry of the cycle. Conversely, if a period-completion frame arrives early, the periodicity mechanism in Section IV-B1 semantically evaluates the position modulo h h, so the result always lies in [ 0, h) [0,h). Therefore, the deviation from the configured period is compensated and all frames are mapped to existing GCL entries.

In the TNA, there is a small but non-zero delay between writing the AFC value, i.e., between initiating a queue state change, and the actual update of the queue state in the hardware [ 44 ]. To quantify internal delays in the AFC mechanism, we measure the time between issuing a queue state change and the actual release of TSN frames. We denote this queue opening 1 1 1 Measurements showed that queue opening and closing delays are distributed in the same way in the TNA. delay as δ ^ queue \hat{\delta}_{\text{queue}}. This delay impacts TSN precision and is rarely documented in available hardware. The measurement procedure is implemented in the data plane of P4-TAS and is shown in Figure 9.

In Figure 9, a closed queue is first filled with TSN frames (step 1). When a TAS control frame matches a tGCL entry that opens the queue, it triggers a queue opening via AFC and records the timestamp t change t_{\text{change}} (step 2). The dequeuing timestamp t deq t_{\text{deq}} of the first TSN frame leaving the queue is then used to compute δ ^ queue \hat{\delta}_{\text{\text{queue}}} as shown in Equation 2 (step 3):

δ ^ queue \displaystyle\hat{\delta}_{\text{\text{queue}}} = t deq − t change. \displaystyle=t_{\text{deq}}-t_{\text{change}}. (2)

This value is stored as a time series in a register of the data plane for all observed transitions (step 4).

The tGCL for this measurement is configured with eight consecutive entries, one per priority. Each entry opens the corresponding priority queue for \qty 100, so that the schedule cycles through all eight priorities in turn. TSN traffic is generated using P4TG [ 45, 46, 47 ] at \qty 400 with randomized priorities and \qty 64 frames. This ensures that the queues are saturated. The experiment is run for \qty 60. Figure 10 shows the complementary cumulative distribution function (CCDF) of the measured queue opening delay δ ^ queue \hat{\delta}_{\text{queue}}.

Most delays are below δ ^ queue = \qty ​ 11 \hat{\delta}_{\text{queue}}=\qty{11}{} with a tail extending up to \qty 63 and a mean of μ ​ (δ ^ queue) = \qty ​ 14.63 \mu(\hat{\delta}_{\text{queue}})=\qty{14.63}{}. These results reveal small but measurable internal delays. In particular, the queue opening delay can cause transitional behavior at tGCL boundaries where frames from the previous entry may still be transmitted briefly after the next entry has started. The impact of this effect and the role of gate switching intervals (GSIs) are evaluated in Section V-B3.

For TAS control frames, the internal packet generator is configured to generate a frame every nanosecond. The frames are sequentially generated in batches of eight, with each frame controlling one of the eight priority queues. In practice, however, a frame cannot be generated every nanosecond. Instead, a small delay occurs between frame generation which limits the granularity at which queue state updates can be triggered. To quantify this phenomenon, we collect the timestamp of each TAS control frame in the data plane of P4-TAS and compute the delay δ ^ control \hat{\delta}_{\text{control}} between two consecutive frames i i and i + 1 i+1:

δ ^ control \displaystyle\hat{\delta}_{\text{control}} = t i + 1 − t i. \displaystyle=t_{i+1}-t_{i}. (3)

We collect 100,000 values for δ ^ control \hat{\delta}_{\text{control}}, all calculated in the data plane and stored in a time series register. The resulting histogram is shown in Figure 11.

The measured median is δ ^ control,M = \qty ​ 9 \hat{\delta}_{\text{control,M}}=\qty{9}{}, with only a few frames showing a slightly higher delay of up to \qty 12. Thus, transmission gate states can be updated only every \qty 9. Because frames are generated sequentially in batches of eight, updates for different priority queues are offset sequentially by \qty 9 and cannot occur simultaneously. Further, this means that the transmission gate state update of the same priority can be triggered every 8 ⋅ δ ^ control ≈ \qty ​ 72 8\cdot\hat{\delta}_{\text{control}}\approx\qty{72}{}. This value should be seen as a worst-case upper bound. In practice, the effective delay can be close to zero if a control frame arrives just before a scheduled gate change. Such a short delay only matters if the tGCL entry resolution is on the order of \qty 72 which is much smaller than typical tGCL entry durations [ 8 ].

Table I gives an overview of the identified and measured internal delays in the best and in the worst case.

Those internal delays accumulate to Δ internal \Delta_{\text{internal}} shown in Equation 4:

Δ internal \displaystyle\Delta_{\text{internal}} = δ TG + δ queue + δ control. \displaystyle=\delta_{\text{TG}}+\delta_{\text{queue}}+\delta_{\text{control}}. (4)

The internal delay Δ internal \Delta_{\text{internal}} may reduce or extend the duration of a tGCL entry. Figure 12 illustrates this effect for three consecutive tGCL entries of configured duration d d.

If the preceding tGCL entry i − 1 i-1 experiences a negative internal delay, it is shortened while tGCL entry i i is extended. In addition, tGCL entry i i itself may experience a positive delay. In this case, the actual duration of tGCL entry i i becomes

d ^ i = d + | Δ internal i − 1 | + Δ internal i. \displaystyle\hat{d}_{i}=d+|\Delta^{i-1}_{\text{internal}}|+\Delta^{i}_{\text{internal}}. (5)

In the worst case, Δ internal i \Delta^{i}_{\text{internal}} is composed of the maximum traffic generator deviation, queue opening delay, and control traffic delay: Δ internal, max i = \qty ​ 11 + \qty ​ 63 + \qty ​ 12 = \qty ​ 86 \Delta^{i}_{\text{internal},\max}=\qty{11}{}+\qty{63}{}+\qty{12}{}=\qty{86}{}. Further, Δ internal i − 1 \Delta^{i-1}_{\text{internal}} can be negative if the traffic generator deviation is negative and all other delays are close to zero, yielding up to \qty 11 of shortening. This implies that a tGCL entry may be extended by up to \qty 86, or be shortened by \qty 11. Further, through correlation of consecutive tGCL entries, a tGCL entry may be extended by up to \qty 97 as shown in Figure 12.

In the best case, a TAS control traffic frame arrives exactly at the switchover point to a new tGCL entry, resulting in a control traffic delay of δ control, min = \qty ​ 0 \delta_{\text{control},\min}=\qty{0}{}. Combined with the measured best case queue delay δ queue, min = \qty ​ 1 \delta_{\text{queue},\min}=\qty{1}{}, and traffic generator accuracy δ TG,min = 0 \delta_{\text{TG,min}}=0, the best case internal delay is Δ internal, min = \qty ​ 1 \Delta_{\text{internal},\min}=\qty{1}{}.

These values therefore define a theoretical bound for deviations in tGCL entry duration. The following evaluation section examines how often and to what extent such deviations occur in practice.

P4-TAS enables the configuration of tGCLs and their periods with nanosecond granularity. However, the internal delays characterized in Section V-A may introduce deviations between the configured and the actual durations of tGCL entries. This section evaluates the accuracy of configured tGCL entries by comparing the expected duration with the measured duration observed in the data plane. First, we present the testbed and describe the measurement procedure. Then, we analyze the results and introduce gate switching intervals (GSIs) to improve timing accuracy.

The testbed for the external tGCL entry measurement is shown in Figure 13.

Traffic is generated with P4TG [ 45, 46, 47 ] at a rate of \qty 514Mpps using minimum-size \qty 64 frames and a constant inter-arrival time, i.e., no bursts. Each frame is assigned a random priority sampled from a uniform distribution and is encapsulated with MPLS to validate the DetNet translation. A tGCL with a period of \qty 400 divided into eight \qty 50 entries is configured in P4-TAS. During each entry, only one of the eight queues is open, corresponding to one priority. Incoming MPLS traffic is translated into a TSN stream, after which the configured tGCL is applied based on the resulting TSN stream identifier. After shaping by the TAS, the traffic is forwarded to a third Tofino™ switch which records frame arrival times per priority in a dedicated P4 program.

The measurement procedure in the dedicated P4 program on the third switch is based on detecting changes in priority within the received stream. It assumes that frames of only one priority π ∈ { 0, …, 7 } \pi\in\{0,\ldots,7\} arrive at the measurement switch during each tGCL entry as configured in P4-TAS. A series of timestamps of the first and last frame in a tGCL entry, i.e., of the same priority, is collected and stored in the data plane. This is illustrated in Figure 14.

For priority π = 0 \pi=0, the arrival time of the first frame in the i i -th tGCL entry is stored as t first i, π = 0 t^{i,\pi=0}_{\text{first}}. When the next priority π = 1 \pi=1 appears, the arrival time of the last frame of the previous priority π = 0 \pi=0 is stored as t last i, π = 0 t^{i,\pi=0}_{\text{last}}, and the new frame marks t first i + 1, π = 1 t^{i+1,\pi=1}_{\text{first}}. This is shown in step 1 in Figure 14. The control plane calculates the duration of entry i i for priority π \pi as follows:

d ^ i π = t last i, π − t first i, π. \displaystyle\hat{d}_{i}^{\pi}=t^{i,\pi}_{\text{last}}-t^{i,\pi}_{\text{first}}. (6)

The measured tGCL entry duration is then compared with the configured tGCL entry duration of d = \qty ​ 50 d=\qty{50}{}, and the deviation δ ^ slice i, π \hat{\delta}^{i,\pi}_{\text{slice}} is obtained as

δ ^ slice i, π = d ^ i π − d. \displaystyle\hat{\delta}^{i,\pi}_{\text{slice}}=\hat{d}_{i}^{\pi}-d. (7)

A negative value for δ ^ slice i, π \hat{\delta}^{i,\pi}_{\text{slice}} thus means that the measured tGCL entry duration was shorter than the configured duration while a positive value means that it was longer. A total of 32,764 values for δ ^ slice i, π \hat{\delta}^{i,\pi}_{\text{slice}} is collected.

The identified internal queue opening/closing delay identified in Section V-A2 causes queue state transitions to occur during a short interval instead of instantaneously. This may cause transitional behavior where queues of a tGCL entry are not yet closed while queues of the next tGCL entry have already begun forwarding. As a result, frames from two tGCL entries are transmitted simultaneously, violating the configured tGCL. This overlap is a phenomenon of P4-TAS, not an artifact of the measurement, and must be addressed. To mitigate this effect, we introduce gate switching intervals (GSIs) which are illustrated in Figure 15.

gate switching intervals are short, explicit tGCL entries in which all queues are closed. They are inserted between tGCL entries. These GSIs suppress transitional forwarding behavior and isolate each tGCL entry. We configured GSIs of \qty 30 which was sufficient to eliminate overlap without significantly impacting available transmission time. While the worst-case queue opening delay measured in Section V-A reaches \qty 63, a \qty 30 GSI provides sufficient isolation because the GSI itself is subject to the same internal delays. This effectively extends the GSI ’s duration and ensures that queue state transitions complete before the next scheduled entry begins. Larger GSIs did not improve the results.

First, we measured the deviation of the observed values from the configured duration of tGCL entries without introducing GSIs. The resulting statistics were inconsistent, with a mean deviation across all measurements of μ ​ (δ ^ slice) = \qty − 22.8 \mu(\hat{\delta}_{\text{slice}})=\qty{-22.8}{} and a median of \qty 450. These apparent deviations are not meaningful because consecutive entries frequently overlapped at their boundaries as explained in Section V-B3.

The deviation of the measured values from the configured duration of tGCL entries using GSIs is presented in Figure 16. The metric is computed per priority, i.e., for each π \pi and entry i i as δ ^ slice i, π \hat{\delta}^{i,\pi}_{\text{slice}}, and the histogram is shown aggregated across all priorities because the behavior is identical for all.

The measured distribution in Figure 16 shows two dominant modes: one around \qty -60ns and one around \qty 30ns, separated by a valley around the median of \qty -19. The bimodal distribution results from how delays of consecutive entries interact. A large delay at a boundary makes the current tGCL entry longer than configured, creating the positive cluster. The following tGCL entry then starts late and becomes shorter, creating the negative cluster. A deviation of exactly zero is unlikely since it would require two consecutive delays to be almost identical which is rare in practice. The overall median is slightly negative, reflecting that shortened entries occur somewhat more frequently. The minimum of \qty -239ns represents a rare worst case where one tGCL entry is extended by nearly the maximum possible delay and the neighboring tGCL entry experiences no delay and is consequently shortened by the same amount.

Scalability is a critical aspect for TSN and DetNet deployments which often involve large numbers of scheduled traffic streams. However, many scheduling algorithms overlook hardware resource constraints such as limited MAT capacity [ 8 ]. In this section, we evaluate the scalability of our P4-TAS implementation by analyzing the number of supported tGCL and sGCL entries, and the number of streams for DetNet and TSN stream identification.

Many TSN scheduling algorithms assume an unlimited number of GCL entries [ 8 ]. However, real hardware imposes strict limits due to finite memory resources which may make a schedule undeployable if exceeded. Therefore, we evaluate the number of tGCL and sGCL entries that can be stored in the proposed P4-TAS implementation. First, we analyze how many MAT entries are required per GCL entry. Then, we describe the available GCL sizes in P4-TAS.

Internal delays

No. streams

Δ internal, max = \Delta_{\text{internal, max}}= 86 ns

Predict6G Open Source TSN Platform [ 25 ]

10k entries

In P4-TAS, the tGCL is modeled as a MAT in the egress P4 control block which matches on the relative timestamp and on one of the eight queues. Therefore, for each tGCL entry, eight range MAT entries are required, i.e., one for each gate. The sGCL is modeled as a MAT in the ingress P4 control block which matches on the relative timestamp and on the stream gate identifier. Thus, for an sGCL entry, only a single range MAT entry is required.

Because range matching in the TNA is limited, a range-to-ternary conversion is employed to enable matching on the relative timestamp. The conversion algorithm described in Section IV-C2 replaces a single range MAT entry with multiple ternary MAT entries to increase the resolution of matched timestamps. However, this approach also increases the number of required MAT entries.

Let w w denote the number of bits used to represent the range. Gupta et al. [ 40 ] showed that a range of width w w bits can be transformed into at most 2 ⋅ w − 2 2\cdot w-2 ternary entries. Consequently, in the worst case, modeling a tGCL containing n n tGCL entries results in up to 8 ⋅ n ⋅ (2 ⋅ w − 2) 8\cdot n\cdot(2\cdot w-2), and a sGCL entry in n ⋅ (2 ⋅ w − 2) n\cdot(2\cdot w-2) ternary MAT entries. In practice, the actual number is often significantly lower due to favorable alignment. For example, if the range’s width is a power of two and properly aligned, a single ternary entry suffices. The tGCL configuration from Section V-B which used a period of \qty 400 divided into eight \qty 50 tGCL entries with additional \qty 30 GSIs required 1512 ternary MAT entries. Numerous studies have proposed optimized range-to-ternary conversion algorithms aimed at reducing ternary entry counts [ 49, 50, 51, 52 ], and these may be explored in future work.

The Intel Tofino™ 2 can generate up to 16 different periodic streams. Since one of those is required for the continuous TAS control traffic, P4-TAS can configure 15 streams for period-completion frames. Therefore, 15 different GCL periods can be configured which can be shared between PSFP and TAS.

The tGCL MAT in P4-TAS can hold 39,000 MAT entries which is a result of the available hardware resources. The MAT is therefore large enough to accommodate multiple tGCLs. We increased the size of the stream gate MAT of PSFP from 2048 in P4-PSFP [ 6 ] to 6000 MAT entries. This is possible because the implementation is ported to the Tofino™ 2 ASIC which has more resources available.

The ternary match operates on a \qty 48bit timestamp enabling resolutions of up to \qty 78h. While such a range exceeds practical requirements, reducing the number of matched bits has no impact due to internal hardware alignment.

These resource limits show that P4-TAS can support multiple tGCLs and sGCLs, ensuring deployability of realistic TSN schedules.

To evaluate the scalability of stream identification in our implementation, we analyze the structure and capacity of the MAT used for DetNet and TSN streams.

A single MAT handles both DetNet and TSN stream identification. It uses ternary keys consisting of the S-Label for DetNet streams and Ethernet destination address, VLAN ID, and IPv4 source and destination address for TSN streams [ 4 ]. The use of ternary matches enables wildcarding and aggregation. For example, an entry matching only on the S-Label enables DetNet-to-TSN translation while another matching on MAC destination and VLAN ID supports TSN-to-DetNet translation or TSN stream identification.

The MAT supports 8196 entries which allows at least 8196 DetNet or TSN streams to be identified. In cases where IP-based identification is used, ternary aggregation can further increase the number of identifiable streams. A survey by Stüber et al. [ 10 ] reports deployments with up to 10,812 streams, indicating that our implementation can support realistic industrial-scale scenarios with appropriate use of wildcarding. These results show that the design is scalable and capable of supporting a number of streams typical in TSN/DetNet deployments.

In this section, we summarize and compare capabilities of several TAS-capable platforms, including our P4-TAS prototype on a P4-programmable ASIC. The overview is shown in Table II.

Similar to P4-TAS, the Predict6G open-source platform provides TAS and DetNet integration, but its documentation does not specify configurable time resolution, internal delay behavior, or scalability [ 25 ]. Commercial platforms such as NXP’s SJA1105TEL [ 33, 34 ], Microchip’s SparX-5i family [ 35 ] and PD-IES008 [ 36, 37 ], and Relyum’s RELY-TSN12 [ 48 ] provide hardware support for TAS and PSFP. However, publicly available specifications typically stop at time granularity, queue counts, or GCL sizes while omitting internal delay sources that ultimately determine schedule precision. Although these devices advertise nanosecond-level configuration granularity, our evaluation with P4-TAS shows that practical gate updates are constrained by internal delays in the range of tens of nanoseconds. This phenomenon is further supported by Eppler et al. [ 9 ] who report internal TAS delays of approximately \qty 2.6 \micro in Relyum switches. This demonstrates that internal TAS timing effects are inherent to the mechanism itself and not specific to P4-based implementations, and can be significantly larger in proprietary devices. Since such delays are rarely documented, the effective precision of commercial solutions is difficult to assess from datasheets alone. Further, those delays are internal and cannot be measured in commercial black-box switches.

Our P4-TAS prototype achieves a comparable time configuration granularity of \qty 1 while also documenting measured internal delays. Specifically, we observed a worst-case internal delay for a tGCL entry of Δ internal,max = \qty ​ 86 \Delta_{\text{internal,max}}=\qty{86}{} in the evaluation. In contrast, vendor platforms either do not document such values (e.g., NXP SJA1105TEL, Microchip PD-IES008) or only disclose partial information (e.g., SparX-5i which specifies a queue opening delay of δ queue = \qty ​ 512 \delta_{\text{queue}}=\qty{512}{}). The transparency in P4-TAS allows a more realistic assessment of achievable schedule precision. In terms of scalability, P4-TAS supports a larger number of flows (≥ \geq 8196) and larger GCLs (39k for TAS and 6k for PSFP) compared to the commercial platforms. For GCL entries, the range-to-ternary conversion overhead must be considered which we evaluated in Section V-C1.

A further distinction is line-rate throughput. While most commercial TSN-capable switch ASICs target 1–25 Gb/s per port in automotive and industrial domains, P4-TAS operates at up to 400 Gb/s per port. This enables its use not only in TSN deployments but also in high-speed data center environments where integration with DetNet becomes relevant. Hence, P4-TAS extends the design space beyond today’s embedded and industrial use cases.

Overall, the comparison shows that commodity hardware already supports TAS and PSFP functionality, but vendors disclose little about their internal timing behavior. This lack of transparency makes it difficult to design schedules with nanosecond accuracy. P4-TAS fills this gap by explicitly characterizing internal delays, enabling more predictable and transparent use of TSN.

We presented P4-TAS, a P4-based implementation of the Time-Aware Shaper (TAS) for TSN on the Intel Tofino™ 2. To achieve periodicity of tGCLs, we leveraged a mechanism for periodic behavior in P4 switches using the internal packet generator as a clock source. Building on this foundation, we introduced a mechanism for precise queue state control for the TAS using an internally generated, continuous stream of TAS control traffic. P4-TAS also incorporates PSFP, where we improved our earlier P4-PSFP design by eliminating recirculation and increasing the GCL time resolution to the nanosecond scale using a range-to-ternary algorithm. Additionally, P4-TAS includes an MPLS/ TSN translation layer enabling TSN traffic shaping and policing to be applied to DetNet flows at line rate up to \qty 400. Beyond functional capabilities, our implementation provides transparent insights into internal timing behavior which is rarely documented in commercial platforms.

Our evaluation covered three aspects. First, we identified and quantified undocumented internal delay sources, including traffic generator inaccuracy, queue opening delay, and TAS control frame delays. We identified a theoretical worst-case accumulated delay of about \qty 86 for a tGCL entry, which is orders of magnitude smaller than the microsecond-scale gate transition delays reported for some commercial TSN switches [ 9 ]. Second, we externally measured the duration of tGCL entries and compared it to the configured duration. In this process, we identified that the internal queue opening delay leads to transitional behavior where queues of a tGCL entry are not yet closed while queues of the next tGCL entry have already begun forwarding. Therefore, we introduced gate switching intervals (GSIs), short explicit tGCL entries in which all queues are closed, to mitigate this effect. Third, we analyzed scalability, demonstrating support for 39,000 tGCL entries and more than 8,196 flows, covering the requirements of current industrial deployments.

Compared with existing ASIC- and FPGA-based TSN platforms, P4-TAS offers similar configurability in terms of time granularity, but additionally exposes internal delays that directly affect scheduling precision. This transparency allows schedules to be designed with awareness of hardware-induced deviations, something not possible with today’s black-box hardware. Moreover, P4-TAS supports line rates up to \qty 400Gb/s per port and seamless DetNet / TSN translation, extending applicability from industrial and automotive networks to high-throughput environments such as data centers and carrier backbones

Future work will focus on improving scalability, for example by optimizing range-to-ternary usage, and on investigating how delay characterization can be incorporated into scheduling algorithms to increase robustness against hardware-level variability. Further, we will explore the integration of P4-TAS into a PTP -synchronized multi-hop TSN testbed to validate gate scheduling and latency guarantees under realistic TSN -specific traffic patterns.