Traditional SDI infrastructures to SMPTE ST 2110

We're now at the on-ramp to SMPTE ST 2110, now that the network plumbing is in place. ST 2110 is an essence-based media system over IP: instead of one SDI “pipe,” it sends separate, time-aligned flows—video (ST 2110-20), audio (ST 2110-30/31), and ancillary data (ST 2110-40)—as RTP multicast over your Ethernet fabric.

Devices maintain perfect phase because PTP per ST 2059 replaces house sync; RTP timestamps are derived from that common clock, so switching, keying, and lip-sync remain deterministic without frame-syncing everything. Routing is no longer a fixed crosspoint. Receivers subscribe to the multicasts you publish, typically via NMOS IS-04/IS-05 (discovery + connection management) instead of patch panels.

Reliability comes from ST 2022-7 seamless protection switching (dual “Red/Blue” networks), plus QoS/DSCP and PTP-aware switches (Boundary/Transparent Clocks) to control jitter and residence delay. Session details ride in SDP; control, tally, events, and audio mapping use NMOS IS-07/08/09/10 as needed.

Practically: if your lower layers provide multicast, QoS, and disciplined PTP, ST 2110 lets you scale from a room to a campus—mixing COTS servers, gateways, cameras, multiviewers, and cloud—while keeping the broadcast timing guarantees you had in SDI, now as software-defined flows.

In the stack to the right we are now at the Media level

A good way to become familar with the pieces that make up 2110 is to look at .the parts that comprise it.

1. Network Fabric: Hard RequirementsTo move from one SDI "pipe" to separate, time-aligned flows (Video, Audio, and Ancillary data), your switches must support specific broadcast-centric protocols.
•  Timing (
  ST2059 SMPTE ST-2059 is the broadcast industry’s timing standard that turns IEEE-1588 PTP into a true “IP genlock.” It comes in two parts: ST-2059-2 defines the PTP profile and behaviors (domains, message intervals, BMCA priorities) so all gear in a facility locks to the same precise time, while ST-2059-1 specifies how to derive traditional media phases—video frame/line boundaries, audio sample ticks, and timecode—from that clock. Using TAI/UTC-aware time with PTP-capable switches (Boundary/Transparent Clocks), it delivers sub-microsecond alignment so 2110 senders/receivers stamp RTP packets against a common epoch. The result is deterministic switching, clean keying, and stable lip-sync across an all-IP plant—without distributing black burst or tri-level over coax.
  ): The switch must act as a Boundary Clock (BC) and/or Transparent Clock (TC) to maintain sub-microsecond alignment.
• Low, deterministic residence delay; stable under load;
  per-port PTP enable Per-port PTP enable means the switch/NIC lets you turn PTP processing on or off for each individual interface (and sometimes for each VLAN on that interface). Only ports with PTP enabled will timestamp/forward PTP messages, participate in BMCA, add TC residence delay, or act as BC masters/slaves on that segment. Ports without it behave like ordinary Ethernet—PTP packets are ignored or just forwarded as data (depending on mode).
• QoS that prioritizes PTP (
  CS6/EF CS6 and EF are QoS markings from the IP DSCP (Differentiated Services Code Point) space:
  
  CS6 (Class Selector 6) → DSCP 48 (binary 110000). Traditionally reserved for network-control traffic (routing, timing). In many 2110 plants, PTP is marked CS6 to give it the absolute highest priority.
  
  EF (Expedited Forwarding) → DSCP 46 (binary 101110, RFC 3246). Designed for low-loss, low-latency, low-jitter traffic (classic example: VoIP). Some shops use EF for critical, latency-sensitive media/control flows—but usually 2110 essence gets CS5/AF41 and PTP stays above them at CS6.
  
  

  Common QoS Markings for 2110

  Traffic	DSCP	Decimal	802.1p CoS (typical)
  PTP (timing)	CS6	48	6
  Voice / “expedited”	EF	46	5
  2110 video/audio	CS5 / AF41	40 / 34	5 / 4
  Control/management	CS3 / CS2	24 / 16	3 / 2

  ) above all else
• Multicast Management: Requires IGMPv3 snooping with
  querier and "fast leave" IGMP Querier = the device that periodically asks “who’s interested in which multicast groups?” so the switch/router can keep pruning/maintaining multicast forwarding state.
  
  Fast Leave = when a host says “I’m done with this group,” the switch immediately stops forwarding that group on that port without sending extra checks—reduces drain time/join-latency.
  support. If routing across subnets,
  PIM-SSM PIM-SSM (Protocol Independent Multicast – Source-Specific Multicast) is the L3 multicast routing mode where receivers join a stream from a specific source S to a group G—written (S,G)—instead of “any source.” Routers build a direct tree to that source (no Rendezvous Point), using the unicast routing table for RPF checks. Benefits: simpler control plane, faster/safer joins, no unwanted senders (great for 2110). Requirements: IGMPv3 at the edge for (S,G) joins, PIM-SSM on the routed links, and an SSM group range (commonly 232.0.0.0/8 in IPv4).
  and source filtering (
  SSM 232/8 SSM 232/8 refers to Source-Specific Multicast using the IPv4 group address block 232.0.0.0/8 (i.e., 232.0.0.0–232.255.255.255). In SSM (per RFC 4607), receivers join multicast as (S,G)—they specify both the Source (S) unicast address and the Group (G) in 232/8—so the network builds a tree directly to that source. Benefits: no Rendezvous Point, simpler control plane, less risk of unwanted sources, and predictable behavior (great for ST 2110).
  
  Quick notes:
  Edge must use IGMPv3 (for (S,G) joins).
  Routers run PIM-SSM; typical config sets the SSM range: ip pim ssm range 232.0.0.0/8.
  Example group: G = 232.1.2.3, with a sender S = 10.110.0.10 → receivers join (10.110.0.10, 232.1.2.3).
  For IPv6, SSM uses FF3x::/32 (not 232/8).
  ) is essential.
  Anycast-Gateway support Anycast-Gateway support (often called distributed default gateway) lets every leaf switch present the same gateway IP/MAC to hosts in a VLAN/VRF. Hosts always use a local first hop—even if they move to a different rack/leaf—so routing is fast, symmetric, and resilient.
  
  How it works: Each leaf is configured with the same SVI IP (e.g., 10.110.10.1/24) and a shared virtual MAC for that VLAN/VRF. Hosts ARP for the gateway; the local leaf answers with the virtual MAC. Inter-VLAN/VRF traffic is routed on the local leaf; if the destination is elsewhere, the leaf uses ECMP to a spine. If a leaf or uplink fails, hosts on other leaves still see the same gateway—no HSRP/VRRP failover events or ARP churn.
  
  Why it’s great in a 2110 fabric: Low, predictable latency: first hop is always local; no hairpin to a “pair” or core. Mobility: move a sender/receiver to another leaf—same gateway, zero re-IP. Scale + resilience: no active/standby FHRP; every leaf is active. Fits Red/Blue: do Anycast GW per VRF (VRF-Red, VRF-Blue) for clean 2022-7 separation.
  
  Design notes / gotchas: Use a consistent virtual MAC and identical SVI IPs on all leaves for that VLAN/VRF. Keep policy parity (ACL/QoS/MTU/DSCP maps) on every leaf; otherwise behavior differs by rack. If you run L3 at the edge, pair with spine-leaf ECMP; consider EVPN (or equivalent) to advertise MAC/IP reachability cleanly. PTP/2110: Anycast GW doesn’t change L2 behavior for PTP; still give PTP strict priority and keep Red/Blue in separate VRFs/VLANs. Watch ARP/ND scale; enable ARP suppression/EVPN proxy where supported to reduce noise. Testing: from a host, ping the gateway; move the host to another leaf and confirm same gateway IP/MAC, same reachability; pull a leaf uplink—traffic should reroute via ECMP without host changes.
  
  Rule of thumb: In spine-leaf plants, use Anycast gateways on every leaf (per VRF) for first-hop routing that’s local, fast, and failure-tolerant—ideal for deterministic ST 2110 media networks.
  (Graphic) at leafs if you do L3 at the edge


• Redundancy: Full support for
  ST 2022-7 SMPTE ST 2022-7 (Seamless Protection Switching, “hitless”)
  It sends two identical RTP streams (legs A and B) over separate network paths. The receiver aligns by RTP sequence/timestamp and merges them, picking the first good packet it sees—so packet loss, jitter, or even a path failure is invisible on output.
  
  Where it’s used: With ST 2110 essences (video-20, audio-30, ANC-40) and other RTP media to keep live signals on-air during link/switch faults.
  
  What you need:
  Two independent networks/NICs (separate failure domains).
  PTP-aligned senders so packets match across legs.
  A receiver buffer sized for differential delay between A and B (adds a little latency).
  Pros: “Hitless” fault masking, no retransmits, simple at endpoints.
  Tradeoffs: 2× bandwidth, careful QoS on both paths, and correct buffer tuning (too small → slips, too big → added delay).
  Rule of thumb: Use 2022-7 for critical program paths; pair with 2110-21 pacing and strict QoS so PTP/control stay priority over jumbo media.
  
  (Seamless Protection Switching) using independent "Red" and "Blue" network paths.
  Why VRF (Virtual Routing and Forwarding) separation for Red/Blue = put your two ST 2022-7 networks (“Red” and “Blue”) into different VRFs (Virtual Routing & Forwarding instances) so they behave like two independent routers/fabrics on the same switches.
  
  Why do it? Hard isolation. Each VRF has its own routing table, ARP/ND, IGMP/PIM state, QoS stats. No accidental traffic “leak” between legs. Duplicate addressing allowed. You can reuse the same subnets in Red and Blue without conflict (handy for simple host configs). Independent control planes. Each VRF has its own IGMP querier, and if you route multicast, its own PIM-SSM domain. Cleaner ops/telemetry. Per-VRF counters and joins make troubleshooting A/B legs trivial.
  
  How it maps to 2110 / 2022-7: Endpoints have two NICs (or 2 ports): one in VRF-Red, one in VRF-Blue. Each leg carries the same RTP flow to a different (S,G) path; the receiver does the hitless merge. PTP: same domain on both legs, but timing packets live in each VRF separately. Keep PTP strict-priority in both. Multicast: run IGMPv3 snooping + querier per VRF; if you must route, enable PIM-SSM per VRF and set SSM ranges in each.
  
  Practical tips: Symmetry: Mirror VLANs, QoS, ACLs, and MTU on both VRFs. Red ≡ Blue (policy parity). Gateways: If you do L3 at the leaf, use anycast gateway per VRF so hosts have a local default GW on each leg. No cross-talk: Don’t leak routes between VRF-Red and VRF-Blue. If an exception is required, use an explicit firewall/route-leak with ACLs. ECMP/paths: Keep independent uplinks/spines per VRF; aim for disjoint physical paths where possible. Testing: Verify join/prune tables and (S,G) counts in each VRF; pull a link on Red and confirm Blue stays hitless.
  use it?

Throughput: Must support
MTU 9000 (or 9216) MTU 9000 (a.k.a. “jumbo frames”) means the IP payload on an interface can be up to ~9,000 bytes instead of the default 1,500. 9216 is a common switch max frame size that leaves headroom for Ethernet/VLAN/MPLS overhead so a 9,000-byte IP MTU won’t get dropped.

Why use it
Lower overhead: fewer packets → less per-packet header/interrupt/CPU cost.
Higher throughput headroom: helpful for 2110-20 UHD streams or 2022-7 dual paths.
Smoother pacing: senders can hit line rate with fewer packets.

Gotchas (important) End-to-end match required: every hop (NICs, switch ports, LAGs, firewalls) must support the same MTU or you’ll see drops/black-holes/frag.
PTP stays small: keep PTP at standard/mini frames with highest QoS (e.g., CS6). Use jumbo only for media flows.
Latency & QoS: big packets can block high-priority traffic if QoS/strict-priority isn’t configured (2110-21 pacing + proper queues).
Tooling/mix issues: tunnels, VLAN stacks, or SPAN ports may need >9000 (hence 9216) to avoid truncation.

Quick rules of thumb
Set media interfaces to MTU 9000 (on hosts) and switches to 9216 max frame (or vendor equivalent).
Verify with ping -f -l 8972 (Windows) or ping -M do -s 8972 (Linux) to test end-to-end (adds ICMP/IP headers ≈ 28 bytes).
Keep PTP/NMOS/control in small-frame classes; ensure QoS prioritizes them above jumbo media.
(Jumbo Frames) end-to-end, and non-blocking fabrics to handle UHD bursts without packet loss.
• Cut-through or low-latency store-and-forward; per-queue shaping/policing Cut-through switching: The switch starts transmitting a frame as soon as it reads the destination MAC (and often VLAN/CoS)—before the full frame is received.
  Pro: Ultra-low latency (tens of nanoseconds to a few µs).
  Con: Can forward errored frames (CRC not yet known), and is more sensitive to congestion because it can’t absorb microbursts with deep buffering.
  
  Store-and-forward: The switch buffers the entire frame, verifies CRC, then forwards.
  Pro: Cleans bad frames, better with speed mismatches and microbursts.
  Con: Adds one frame time of latency (e.g., ~12 µs for a 1500-B frame at 1 GbE; ~1–2 µs at 10/25 GbE; proportionally higher for jumbo).
  Low-latency store-and-forward: Architectures and pipelines that keep store-and-forward but minimize per-hop delay (tight buffers, fast lookups).
  
  Per-queue shaping / policing (QoS)
  Switch ports maintain multiple hardware queues (e.g., Strict Priority for PTP, then Expedited Forwarding for media, then best-effort, etc.).
  Shaping (egress): Smooths traffic to a target rate (CIR/PIR) by queueing and releasing packets at a controlled pace (token bucket). Use: Prevent bursts from overrunning downstream links; keep 2110-21 pacing tidy. Policing (ingress or egress): Enforces a cap—excess packets are dropped or remarked immediately. Use: Protects the fabric from misbehaving senders; keeps PTP/control safe from jumbo floods.
  
  Why this matters for ST 2110. Latency: Cut-through (or very low-latency store-and-forward) keeps hop delay tiny, helping tight PTP and RTP timing.
  Determinism: Per-queue shaping ensures media flows exit at predictable rates; policers stop a single device from clobbering the network.
  
  Design tip: Put PTP in a strict-priority, non-shaped queue; put video/audio in high-priority shaped queues; keep best-effort/control in lower queues. If congestion is possible or you mix speeds, store-and-forward with good QoS is usually safer than pure cut-through.


• Why
  Spine-leaf (Clos); Spine-leaf (Clos) aware ECMP with deterministic pathing = a data-center style fabric and routing approach that gives predictable, balanced paths for your media flows.
  
  Spine-leaf (Clos): Endpoints connect to leaf switches; leaves connect to all spines. No east-west bottlenecks, uniform hop count, easy scale-out.
  ECMP (Equal-Cost Multi-Path): The fabric can use multiple equal-cost routes at once. A per-flow hash (5-tuple, VLAN, etc.) picks one path, so no packet reordering.
  
  Deterministic pathing: The hash/seed and topology are controlled so the same flow always takes the same path, and when a link fails, resilient hashing moves only the affected flows (minimal churn/jitter).
  
  Why it matters for 2110: Stable latency/jitter per flow; no reordering for RTP. Balanced load across spines without surprises. Lets you purposely separate 2022-7 A/B legs onto different ECMP paths/spines (independent failure domains). Keep PTP on strict-priority queues; ECMP is per-flow, not per-packet.
  
  Clos (pronounced “cloh”) refers to a multistage switching topology invented by Charles Clos (1952). Instead of one giant switch, you build a large, scalable, often non-blocking fabric from many small switches arranged in stages:
  Ingress (leaf) → Middle (spine) → Egress (leaf) — classic 3-stage Clos
  Larger fabrics use 5-stage (leaf–spine–core–spine–leaf)
  
  Key benefits: high bisection bandwidth, predictable latency, fault tolerance, and easy scale-out. Modern “spine-leaf” data-center networks are practical IP implementations of a Clos fabric; with ECMP hashing, each flow takes one equal-cost path without reordering—great for RTP/2110 media.
  Matters for 2110 Throughput

•   Non-Blocking Fabric: Spine-leaf ensures that any "leaf" (where your cameras/servers are) can talk to any other leaf with consistent, predictable bandwidth.


• East-West Traffic: Broadcast IP traffic is largely "East-West" (server-to-server or camera-to-switcher). Spine-leaf is optimized for this, whereas older architectures were built for "North-South" (client-to-internet) traffic.


• Equal-Cost Multi-Path (ECMP): This allows the network to load-balance traffic across all available "spines." If you have four 100G links to your spines, the system sees a 400G pipe, maximizing effective throughput.


• Deterministic Latency: Because every leaf is exactly one hop away from any other leaf (via the spine), the packet jitter is kept to an absolute minimum—which is critical for the RTP timestamps used in 2110.


2. Host & NIC Optimization
   The Network Interface Card (NIC) is the bridge between your software and the high-speed fabric.

ConnectX-6 Dx Recommended Settings for SMPTE ST 2110

Component	Recommendation	Key Settings
Hardware	ConnectX-6 Dx  ? The ConnectX-6 Dx is an advanced Ethernet adapter card from NVIDIA (formerly Mellanox) designed for demanding data center and media workloads. It provides: Up to 2 ports of 100GbE or 1 port of 200GbE Ethernet connectivity. PCIe Gen4 x16 host interface (with excellent bandwidth headroom). It is one of the most popular NICs in the broadcast industry for SMPTE ST 2110 deployments because it offers strong hardware offloads specifically beneficial for uncompressed or lightly compressed video, audio, and ancillary data over IP.	Use PCIe Gen4 x8 for maximum headroom
Driver	WinOF-2 (LTS Build)	Match firmware version strictly to the driver
MTU	9014	Must match your network's end-to-end MTU
Offloads	Disabled	Disable LRO/RSC (don't coalesce UDP media packets)
Pacing	Hardware-Assisted	Vital for smooth delivery of uncompressed video



• Pro Tip: Always pin your 2110 application threads to the same NUMA node as the NIC to minimize latency and CPU jitter.
• NIC/Switch ops & lifecycle considerations
• LTS/“gold star” software train; ISSU/GR Pick the stable (gold-star) LTS image (Long-Term Support release stream: fewer new features, hardened & supported longer) and use ISSU/GR-style maintenance (In-Service Software Upgrade: upgrade switch OS without dropping data-plane packets (hitless or near-hitless)) with proper PTP redundancy—so upgrades feel invisible on air.
  or planned maintenance that won’t kill PTP
• Streaming telemetry
  (gNMI/JSON), sFlow/NetFlow Streaming telemetry (gNMI/JSON): Switches/routers push live metrics (interfaces, queues, PTP stats, ACL hits) to a collector via gNMI using JSON (or GPB). Low-latency, high-resolution, vendor-neutral; perfect for dashboards and alerts in a 2110 plant (think offsets, drops, queue depth every 1–2s).
  
  sFlow: packet/header sampling + counters → shows who’s talking to whom, rates, DSCP, burstiness.
  
  NetFlow/IPFIX: flow records (5-tuple, bytes, duration) → great for proving multicast joins and bandwidth per flow/receiver.
  
  Rich counters: Hardware stats beyond “bits and errors”: per-queue/CoS drops, tail-drops, WRED, pause/ PFC, ingress/egress DSCP, microburst/queue-depth, interface errors and discards.
  
  For 2110 you want to see PTP class, media classes, and best-effort separately.
  
  Sane PTP show tooling: Human-readable commands/pages that expose: domain, GM identity, state (MASTER/SLAVE), stepsRemoved, offsetFromMaster, meanPathDelay, announce/ sync intervals, and TC/BC status—ideally with history/graphs.
  
  Why it matters for 2110: Lets you prove timing health and QoS (PTP stable, media not dropping), catch multicast/QoS misconfig, and correlate faults (e.g., queue spikes → RTP gaps).
  
  Rule of thumb: collect gNMI for time-series, add sFlow/NetFlow to see flows, and always enable per-queue counters + readable PTP “show” outputs.
  , rich counters; sane PTP show tooling
• Robust TAC (Technical Assistance Center (vendor support)) + documented 2110/PTP reference designs;
  JT-NM JT-NM = Joint Task Force on Networked Media — a coalition led by EBU, AMWA, SMPTE, and VSF to accelerate IP-based professional media.
  
  Sets common architectures & practices for live/media-over-IP (how discovery, control, timing, and transport fit together).
  
  Bridges standards and specs: aligns SMPTE ST 2110 (transport/timing) with AMWA NMOS (IS-04/05, etc.) and operational guidance.
  
  Publishes key guidance like TR-1001-1 (how 2110/NMOS devices should behave on engineered networks).
  
  Runs the “JT-NM Tested” program (at NAB/IBC): vendors get interoperability badges for 2110/NMOS features so buyers know what plays well together.
  
  Think of JT-NM as the umbrella coordination that turns individual standards into a working, interoperable ecosystem.
  Tested history preferred
• Security
• RBAC/TACACS+/RADIUS, SSH, mTLS/PKI

  • RBAC — Role-Based Access Control: authorize actions based on a user’s role (operator vs admin).
  • TACACS+ — Terminal Access Controller Access-Control System Plus: AAA protocol for device logins/commands (common on switches).
  • RADIUS — Remote Authentication Dial-In User Service: AAA protocol typically for network access (802.1X, Wi-Fi, VPN).
  • SSH — Secure Shell: encrypted remote CLI/management session to devices/servers.
  • mTLS — mutual Transport Layer Security: TLS where both client and server present certificates (two-way auth).
  • PKI — Public Key Infrastructure: the certificate/CA system that issues, validates, and revokes keys/certs used by TLS/mTLS.
  baseline; 802.1X if you need port security
• ACLs/micro-segmentation; MACsec (if mandated) ACLs / micro-segmentation; MACsec (if mandated) — in a 2110 plant this line is about containment and (optionally) encryption on the wire.
  ACLs (Access Control Lists) & micro-segmentation
  What: Narrow “who can talk to whom” using L2/L3/L4 rules,
  (IP/port/protocol), per-VLAN/VRF/port. Micro-segmentation = applying those rules granularly (per device, role, or flow), not just at the perimeter.
  Why: Shrinks blast radius, blocks stray/unwanted traffic (rogue senders, bad joins), protects control/PTP from media floods.
  
  How for 2110: Permit only SSM multicast groups/ports needed; deny the rest.
  Whitelist PTP (IPv4 224.0.1.129 UDP/319/320 or IPv6 equiv) and keep it strict priority.
  Limit NMOS/SDP/management to controllers + endpoints (SSH/HTTPS/API only).
  Enforce per-port ingress ACLs with counters; log minimally to avoid CPU hits.
  Use VRFs/VLANs (or group-based tags/SGT) to separate media, PTP, control, and out-of-band mgmt.
  
  MACsec (802.1AE) — “if mandated”
  What: Link-layer encryption between switches/NICs; protects frames against snooping/tamper on each hop. Keys via MKA/802.1X.
  Why optional: Adds operational overhead (keying, hardware support) and a little latency/MTU overhead; many facilities rely on physical security + segmentation instead.
  Use when: Compliance or customer policy requires encryption on the wire (studio to core, truck to dock, rented dark fiber). Ensure hardware offload, adjust MTU (~+32B), and confirm PTP still meets timing budgets.
  
  Rule of thumb:
  Start with good segmentation (VLAN/VRF + tight ACLs at ingress) and prove with counters/telemetry; add MACsec only where policy or risk demands encryption, verifying timing (PTP) and throughput remain within spec.
3. The PTP Domain Strategy
   In ST 2110, the PTP Domain is a logical timing island. While SMPTE 2059 often defaults to Domain 127, choosing the right ID prevents "timing collisions."
• Production Plant: Stick to a single standard (e.g., 127) to ensure all RTP timestamps align.
• Isolation: Use different domains (e.g., 120, 121) for engineering labs or temporary staging areas to keep test clocks from interfering with the main broadcast.
• BMCA (Best Master Clock Algorithm): This is the "election" process. Ensure your Grandmasters have the correct Priority 1 settings to ensure your most stable clock always wins the leadership role.
• Additional PTP info:
• In PTP (IEEE-1588), the domain is just a small number carried in every PTP message that says, “I belong to this timing group.” Devices only synchronize to Grandmasters (GMs) that advertise the same domain number.
• Different PTP systems can share the same wires but ignore each other if they use different domains.
• Keeps a lab GM or a visiting truck’s GM from accidentally taking over your plant.
• Lets you run separate timing “islands” (e.g., production vs. test) on one fabric.
• Many plants use domain 127 (widely used in SMPTE 2059 deployments). Factory defaults are often domain 0 — easy to collide with, so many engineers change it.
• Red/Blue networks (ST 2022-7) still use the same domain; you get hitless timing via two paths, not two domains.
• Prefer one domain per facility. Use multiple domains only when you truly need hard separation.
• Operational Best Practices
  A successful 2110 deployment relies on visibility and disciplined configuration:
• QoS Prioritization: Assign DSCP CS6 (Network Control) to PTP traffic. Media should follow with CS5/AF41, ensuring timing never starves.
• Telemetry: Use tools like Prometheus or Grafana to monitor PTP offset and multicast group health in real-time.
•   Discovery: Utilize NMOS IS-04 (Discovery) and IS-05 (Connection) to replace physical patch panels with software-defined routing.
•   Acceptance Testing: Before going live, perform a "path pull" test to verify that ST 2022-7 stays hitless when one network path is disconnected.