Time-Sensitive Networking: 802.1Qbv Scheduling Explained

Standard Ethernet is best-effort: whatever arrives first is forwarded first, and a burst of bulk traffic will make a latency-sensitive flow wait. Time-Sensitive Networking is a family of IEEE 802.1 amendments that turn Ethernet into a medium with bounded, predictable latency for designated traffic, while still carrying ordinary traffic on the same links. If you have ever been told "you need a fieldbus for that", TSN is the reason that statement is becoming less true.

The TSN Toolbox

Most deployments start with 802.1AS plus 802.1Qbv. The rest is added when the problem demands it: preemption when a high-priority frame cannot wait for a large lower-priority frame in flight, FRER when a single link failure cannot be tolerated even for a few milliseconds.

The Core Idea: Gates and a Schedule

Each egress port has eight (or more) traffic classes and a set of queues. 802.1Qbv adds a gate in front of each queue, and the gates are driven by a schedule. The schedule is a list of entries, each specifying which gates are open and for how long. That list repeats on a cycle, and the cycle is synchronised across the whole TSN domain by 802.1AS.

cycle = 1 ms, period 0..1000 us

entry 0:  t=0    t=200us   gates = 10000000  (scheduled class only, exclusive window)
entry 1:  t=200  t=400us   gates = 01000000  (second class window)
entry 2:  t=400  t=1000us  gates = 00111111  (best effort gets the rest)

resulting behaviour for the scheduled stream:
  - its frames enter the wire only inside its 200 us window
  - maximum queuing delay is bounded by the cycle, not by congestion
  - worst case latency = f(cycle length, hop count, propagation)

Because the window is exclusive, a scheduled frame is never behind a best-effort frame in the same queue, which is what removes the unbounded jitter you get from priority queuing alone. Priority (PCP/DSCP) decides which queue a frame enters; the gate schedule decides when that queue may transmit.

Timing First, Always

A schedule is meaningless without synchronised clocks. gPTP (802.1AS) propagates time from a grandmaster through the bridges, compensating for residency time hop by hop. Requirements in practice:

• A grandmaster source with a stable, accurate clock, and ideally redundant ones with BMCA.
• Every bridge in the path must be TSN-aware. A non-TSN switch in the middle breaks the residency-time compensation, and the schedule silently drifts.
• Typical accuracy targets: sub-microsecond for motion control, single-digit microseconds for most industrial applications, and low tens of microseconds for audio-video.
• Verify continuously, not once. The commands and clock-class expectations are largely the same as any PTP deployment, described in this IEEE 1588 boundary clock guide, and the difference between PTP and NTP in this context is quantified in this PTP vs NTP comparison.

A Configurable Example on Linux

The taprio qdisc implements 802.1Qbv on supported NICs, and ethtool exposes the per-queue timestamping necessary for gPTP. A lab setup on an Intel i210/i225 class NIC:

# 1. verify hardware support
ethtool -T enp3s0 | grep -E "PTP|SOF_TIMESTAMPING_TX_HARDWARE"
sudo ethtool -K enp3s0 hw-tc-offload on

# 2. map traffic to queues: VLAN PCP 5 -> queue 5
sudo tc qdisc replace dev enp3s0 handle 100: parent root mqprio num_tc 8 \
  map 0 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 1

# 3. install the schedule: 1 ms cycle, exclusive window for queue 5
sudo tc qdisc replace dev enp3s0 parent 100:5 handle 200: taprio num_tc 8 \
  map 0 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
  base-time 0 sched-entry S 20 200000 sched-entry S 7f 800000 \
  flags 0x2 clockid CLOCK_TAI

# 4. confirm what got programmed
sudo tc qdisc show dev enp3s0
sudo tc -s qdisc show dev enp3s0

The hex mask identifies which queues are open: 0x20 is queue 5 only, 0x7f is queues 0-6. The base-time must be aligned to the synchronised clock, and the LED on the NIC, if present, is the fastest sanity check that gPTP is using hardware timestamps rather than software ones.

Frame Preemption

Even inside its window, a scheduled frame may have to wait for a lower-priority frame already in transmission - up to 1518 bytes, which at 100 Mbps is over 120 microseconds. Preemption solves this by allowing a preemptible frame to be interrupted mid-transmission and resumed later. Frames are tagged with an mCRC so the receiver can reassemble them. The practical consequences: the smallest preemptible fragment adds a few bytes of overhead to every best-effort frame, and every device in the path must support preemption or it is silently disabled.

Configuration Model

Two options, and the choice has long-term consequences:

• Fully centralised (CNC). A controller computes the schedule for the whole domain from stream requirements. Consistent, auditable, and the only approach that scales past a handful of switches - but it is a controller to run and a model to maintain.
• Fully distributed. Each device is configured by hand. Workable in a small ring; a change-management problem anywhere else, because schedules must be aligned across every device.

Several vendors expose TSN configuration through YANG models, which means an existing network automation practice can carry it. The same model-driven workflow used for ordinary interface and QoS configuration - such as the one in this OpenConfig and YANG workflow guide - is the right place to manage the gate lists, because a hand-edited schedule in a maintenance window is exactly the kind of configuration that drifts.

Deployment Constraints

• TSN is a LAN technology. It does not extend across a routed WAN. Keep the TSN domain bounded and treat it as a single administrative unit.
• Non-TSN traffic still shares the links. The schedule reserves capacity for scheduled streams; if best-effort traffic is starved, users notice even though the controlled traffic is perfect.
• Every bridge must participate. A single non-TSN device in the path invalidates the latency guarantee for traffic crossing it.
• Cycle time is a design parameter, not a default. A short cycle bounds latency but wastes bandwidth on guard bands; a long cycle is efficient but unusable for fast control loops.
• Segment the domain. Mixing an office VLAN with a control TSN domain on the same switches is technically possible and operationally fragile. Keeping them separate is consistent with the zone model described in this OT/SCADA segmentation guide.

Is TSN the Right Answer?

Use TSN when you have a genuine bounded-latency requirement on Ethernet, several traffic classes that must coexist, and the ability to control every device in the path. Do not use it when the requirement is merely "high priority" - ordinary QoS with proper DSCP marking at the trust boundary, as described in this QoS trust boundary guide, solves that with far less operational cost. TSN earns its complexity when a missed deadline is a physical failure rather than a slow web page.

原文链接：https://1.ieee802.org/tsn/