PTP

Precision Time Protocol (PTP)
See "Eliminating the middle layers" for why PTP is not only found on layer 4, but also 2

Study Plan 2110 Topo

IEEE 1588 defines PTP as a way for all devices on a network to synchronize their clocks with microsecond (or even nanosecond) accuracy.

In SMPTE ST 2110, PTP (Precision Time Protocol, IEEE 1588) is not used just by RTP as we saw in the previous lesson — it is the core system-wide timing and synchronization mechanism for the entire standard.

Besides RTP itself, the following elements and components in a ST 2110 system rely on PTP:

1. All Devices and Nodes in the Network.
Every ST 2110-compliant device (cameras, encoders, switchers, playout servers, monitors, multiviewers, processors, etc.) must be synchronized to a common PTP clock.

PTP provides a shared, high-precision time reference (typically sub-microsecond accuracy) across the entire facility or IP network.

2. Media Clock Generation and Alignment
Media clocks (sample clocks for audio, frame clocks for video) are derived from the PTP-synchronized system clock.

This ensures that audio (ST 2110-30 / AES67), video (ST 2110-20), and ancillary data (ST 2110-40) all run at the correct rate and stay phase-aligned with each other.

3. RTP Timestamps (but not only RTP)
RTP timestamps in every stream (video, audio, ancillary) are generated from the PTP clock.

Receivers use these PTP-derived RTP timestamps to align and synchronize multiple independent streams (e.g., lip-sync between video and audio, frame-accurate switching, seamless transitions).

4. SMPTE ST 2110-10 (System Timing and Definitions)
The entire timing model is defined in ST 2110-10, which mandates PTP (via SMPTE ST 2059-2 profile) as the reference clock source.

This includes:
• Media clock synchronization
• RTP timestamp generation
• Inter-stream alignment
• Legacy timing emulation (virtual genlock, black burst, tri-level sync signals for SDI/AES equipment)

5. AES67 Audio Streams (ST 2110-30)
AES67 compatibility within ST 2110-30 requires PTP synchronization for sample-accurate audio clocking and inter-stream alignment.

PTP ensures audio sample clocks are locked to the system reference, preventing drift or phase offsets.

6. Ancillary Data Streams (ST 2110-40)
Timecode, captions, KLV metadata, and other ancillary data are timestamped and aligned using PTP-derived timing.

This keeps ancillary data perfectly synchronized with video and audio essences.

7. Network-Wide Synchronization (Switches, Routers, etc.)
PTP-aware switches (Boundary Clocks or Transparent Clocks) are required to maintain low jitter and accurate timing distribution across the IP fabric.

Without PTP synchronization throughout the network, timing accuracy degrades, leading to buffer overflows, lip-sync errors, or frame drops.

PTP is the foundation of synchronization in SMPTE ST 2110 — not just for RTP, but for every aspect of the system:

Device clocking
Media clock derivation
RTP timestamping (video, audio, ancillary)
Inter-stream alignment
Network timing distribution
Emulation of legacy genlock signals

Without PTP (and a properly designed PTP profile like ST 2059-2), ST 2110 streams cannot achieve the required sub-microsecond synchronization needed for professional broadcast production. RTP is just one consumer of the PTP timing; the entire ST 2110 ecosystem depends on it.

Grandmaster

The PTP (Precision Time Protocol, IEEE 1588) grandmaster selection process uses the Best Master Clock Algorithm (BMCA) — a distributed, deterministic election mechanism that runs continuously on every PTP-aware device in the domain. The goal is to select one Grandmaster Clock (GMC) as the root timing reference for the entire network (or PTP domain).

How the Grandmaster Is Selected (Step-by-Step)

1. Announce Messages
Every PTP-capable clock periodically multicasts Announce messages containing its own clock properties (quality attributes).

2. Each Clock Compares Received Announce Messages
Every device independently runs the BMCA to compare:
• Its own properties (from its local clock)
• Properties advertised in received Announce messages from other clocks
The clock with the "best" (highest-ranked) set of attributes wins and becomes (or remains) the Grandmaster.

3. BMCA Comparison Order (IEEE 1588-2008 Default Profile)
Clocks are ranked using this strict priority sequence (first differing field decides the winner):
1. Priority 1 (user-configurable, 0–255, lower = better)
  → Highest precedence. Often set to a low value (e.g., 1–10) on preferred grandmasters (GPS/GNSS sources) and high (e.g., 128 or 255) on ordinary clocks.
2. Clock Class (0–255, lower = better)
  → Indicates clock quality/source type.
  Examples:
  • 6 = Primary reference (e.g., GPS-locked)
  • 7 = Holdover (lost reference, using internal oscillator)
  • 248 = Default (no better source)
3. Clock Accuracy (enum value, lower = better)
  → How close the clock is to true time (e.g., <100 ns, <1 µs).
4. Clock Variance (offsetScaledLogVariance)
  → Stability of the clock (lower variance = more stable
5. Priority 2 (user-configurable, 0–255, lower = better)
  → Fine-grained tiebreaker when higher priorities are equal.
6. Clock Identity (tiebreaker)
  → Usually the lowest MAC address (or EUI-64-based identifier) if all else is identical.
  
  The clock that ranks highest (best) across this ordered list is elected Grandmaster
4. Outcome & Behavior
• The winning clock announces itself as Grandmaster and continues sending Sync/Announce messages.

• All other clocks become slaves (or boundary clocks) and synchronize to it.

• If the current Grandmaster fails (loses GPS, power, network connectivity), or a better clock appears, the BMCA re-runs automatically — the new best clock takes over (no manual intervention needed in most cases).

Special Cases in Profiles
• SMPTE ST 2059-2 (used in ST 2110 broadcast environments):
Follows IEEE 1588 BMCA closely but mandates specific defaults (e.g., Priority 1 = 128 for ordinary clocks, low values for grandmasters; often prefers GNSS sources).

Tiebreakers still include lowest MAC or similar unique ID.

• Default profile or Power profile: May tweak priorities or add attributes.

The above diagram illustrates a simplified PTP network with multiple PTP-aware devices (clocks) connected via Layer 2 switches and a Layer 3 router.

Devices send/receive PTP Announce messages. Each device compares attributes (including IP/MAC for tiebreakers).

The device with the lowest IP address (192.168.1.1) in this example wins the election (shown as the elected Grandmaster with a clock icon and arrow pointing to it).

Once elected, it becomes the reference — other clocks synchronize to it.

The Layer 2 switch forwards multicast PTP messages locally; the Layer 3 router handles inter-subnet forwarding if needed.

How It Works: Once a device is elected as the Grandmaster Clock (usually locked to GPS or an atomic source), other devices (e.g., cameras, switchers, servers) act as PTP Clients (Slaves).

They exchange timestamped packets:

Sync message – sent from master to slave.
Follow_Up message – precise send time of Sync.
Delay_Request message – sent from slave to master.
Delay_Response message – gives the master’s receipt time.

By comparing these timestamps, each slave can calculate:
Network delay + time offset
and adjust its local clock accordingly.

PTP (specifically SMPTE 2059-2) provides the common timebase for:

Video, Audio, and Ancillary streams over IP
Frame alignment and lip-sync
Deterministic packet timing (so everything stays in phase)

To determine which device is the Grandmaster a quick rule of thumb in a Broadcast Facility is that the device with the lowest Priority 1 value (user-configured) is almost always the Grandmaster — unless it fails. In SMPTE ST 2110 setups, check the primary GNSS/GPS reference clock first — it's usually configured with Priority 1 = 10–50, while others are 128+.

Clock Types

Network Role

Usually carried on a management VLAN or dedicated PTP domain.
Requires PTP-aware switches that support:

Transparent Clocks (TC): correct for packet delay inside the switch.
Boundary Clocks (BC): regenerate timing for local clients.

Switches can act as Transparent Clocks or Boundary Clocks.

Transparent Clock (TC) Operation
This is where a switch does not participate in the timing exchange directly. Instead, it measures how long the PTP message spends traversing it and adds a correction field to the packet. These offsets add up as more switches are encountered.

This allows the endpoint (camera, server, etc.) to accurately calculate the true network delay relative to the Grandmaster.

Sync and Delay_Request packets still go all the way to the Grandmaster. But each switch adds its own timing correction, so the Grandmaster’s timestamps remain accurate when the client calculates its offset.

Think of it like: Each switch adds a time “receipt” saying, “This packet spent 37 microseconds passing through me.” This method is used when switches can forward PTP packets very precisely but don’t maintain their own clock hierarchy.

Boundary Clock (BC) Operation
Each switch maintains its own synchronized local clock. The switch becomes a PTP Slave to the Grandmaster on one side, and a PTP Master to all devices on its downstream ports.

In this mode: The switch does request time from the Grandmaster. Downstream devices then sync to the switch (not directly to the Grandmaster). This effectively creates a tiered time distribution tree:

This reduces network load and isolates timing errors — ideal for large 2110 installations.

Mode	Who Talks to the Grandmaster?	Role of Switch	Typical Use
Transparent Clock	All endpoints	Adds per-hop delay correction	Simpler networks
Boundary Clock	Each BC switch	Acts as local master for its domain	Complex or large-scale networks

Major Switch Vendors Supporting Both PTP Clock Types

Vendor	Common Models / Series	PTP Clock Modes Supported	Notes
Arista Networks	7050X, 7060X, 7280X, 7500R, 7800R	Boundary Clock, Transparent Clock	Widely used in broadcast; IEEE 1588-2008; strong 2110 deployments.
Cisco Systems	Nexus 3000/9000, Catalyst 9300/9500	Boundary Clock, Transparent Clock	Hardware timestamping; may require PTP license/feature enablement.
NVIDIA (Mellanox)	Spectrum, Spectrum-2, Spectrum-3	Boundary Clock, Transparent Clock	Data-center class; sub-µs precision; common in hybrid media fabrics.
HPE Aruba	Aruba 6300, 8325, 8400	Boundary Clock, Transparent Clock	PTPv2 with SMPTE 2059-2 profiles available.
Juniper Networks	QFX5100, QFX5200, QFX10000	Boundary Clock, Transparent Clock	Hardware assist; used in media data centers.
Extreme Networks	SLX 9540, VSP 7400	Boundary Clock, Transparent Clock	Supports 2059-2 profiles; seen in OB/studio networks.
Netgear Pro AV	M4250, M4300, M4350	Boundary Clock (limited), Transparent Clock	Cost-effective; common in NDI/2110 hybrids; precision varies.
Dell EMC	S5200, S6100 (OS10)	Boundary Clock, Transparent Clock	IEEE 1588v2; requires OS10 Enterprise features.

Implementation Details

Most switches allow you to select PTP mode per interface or globally.
High-end switches (Arista, Cisco, Juniper) use hardware timestamping to achieve sub-microsecond accuracy.
Many vendors provide SMPTE 2059-2 profiles (used in 2110 systems) that preconfigure the correct PTP domain, delay mechanism, and sync interval.

In Practice

Large 2110 facilities: typically use Arista 7280/7500 or Cisco Nexus 9K in Boundary Clock mode.
Smaller systems / OB trucks: often use Transparent Clock mode with fewer hops and simpler topologies.
Mixed deployments: combine both — core switches as Boundary Clocks, access switches as Transparent Clocks.

Vendor	Broadcast Facilities	Enterprise Networks	OB Trucks / Remote Production
Arista Networks	⭐⭐⭐⭐⭐ — Dominant in SMPTE 2110 deployments (GV AMPP, NEP, EVS)	⭐⭐⭐ — Used in high-performance data centers	⭐⭐⭐⭐ — Used in high-end mobile units (e.g., NEP, Game Creek)
Cisco Systems	⭐⭐⭐⭐ — Common in large broadcast hubs and network cores	⭐⭐⭐⭐⭐ — Industry standard for enterprise infrastructure	⭐⭐⭐ — Occasionally used in large OBs, but power draw is high
NVIDIA (Mellanox)	⭐⭐⭐ — Used in hybrid cloud or HDR production systems	⭐⭐⭐⭐ — Popular in HPC and IP media data centers	⭐⭐ — Rare in trucks; higher cost and cooling needs
HPE Aruba	⭐⭐ — Entry-level broadcast or education facilities	⭐⭐⭐⭐ — Very common in enterprise and campus networks	⭐⭐⭐ — Used in smaller OB and remote setups
Juniper Networks	⭐⭐⭐ — Found in hybrid ST 2110 / IT infrastructures	⭐⭐⭐⭐ — Common in telco and cloud backbones	⭐⭐ — Less common in mobile trucks
Extreme Networks	⭐⭐⭐ — Moderate use in mid-tier studios	⭐⭐ — Limited enterprise use	⭐⭐⭐⭐ — Favored in compact OB trucks due to efficiency
Netgear Pro AV	⭐⭐⭐ — Used for NDI / hybrid IP systems	⭐⭐ — Minimal enterprise use	⭐⭐⭐⭐⭐ — Very common in small and mid-size OBs / flypacks
Dell EMC	⭐⭐ — Rare, but sometimes used for file-based workflows	⭐⭐⭐⭐ — Common in enterprise and data centers	⭐ — Uncommon in mobile units

How to Read the Chart
⭐⭐⭐⭐⭐ = Very common
⭐⭐⭐⭐ = Common
⭐⭐⭐ = Moderate presence
⭐⭐ = Occasional use
⭐ = Rare or uncommon

In the above left graphics you see two primary PTP grandmaster (GM)
They are locked to GNSS (GPS) or atomic reference
Acts as the time authority for the entire production
Generates PTP time aligned to ST-2059 (media profile)

The core switches operate as Boundary Clocks (BCs)
PTP terminates on each port

The one on the right shows a WAN bridge.

A WAN edge switch often acts as a Boundary Clock, or a PTP-aware gateway cleans up timing before crossing domains. There is no assumption of perfect symmetry → this is why boundary clocks matter. PTP works correctly only if the network delay from A → B is the same as from B → A. In real networks—especially WANs—that assumption is often false.

PTP synchronizes clocks by measuring round-trip delay and assuming it can be split evenly.

Forward delay ≈ Reverse delay ∴ One-way delay ≈ (round-trip delay) / 2
This assumption is called path delay symmetry.

What breaks symmetry in real networks?
Perfect symmetry is common in:
Short, local, Layer-2 networks, Single switch hops, OB trucks, studios, machine rooms

It is rare in:
WANs, MPLS ( Multi-Protocol Label Switching It is a high-performance, connection-oriented routing technique used in modern telecommunications and enterprise networks to direct data from one node to the next based on short, fixed-length labels rather than long network addresses (like IP addresses).

How it works
• Instead of performing complex IP lookups at every router (which can be slow), MPLS attaches a small label (20-bit value) to each packet at the network edge (ingress router).
• Intermediate routers (called Label Switch Routers or LSRs) forward packets based only on this label (very fast hardware lookup).
At the egress router, the label is removed, and the packet continues as normal IP traffic.

Advantages Over Traditional IP Routing
• Faster forwarding (label lookup is simpler than IP longest-prefix match)
• Traffic Engineering — Explicit paths, load balancing, fast reroute (FRR), QoS enforcement • VPNs — MPLS-based Layer 3 VPNs (L3VPN) and Layer 2 VPNs (L2VPN/VPLS/VPWS) are widely used for secure, private connectivity • Convergence — Sub-50 ms failover with fast reroute • Supports multiple protocols (hence "Multi-Protocol") — IP, Ethernet, ATM, Frame Relay, etc.

Common Uses - Service provider backbone networks (e.g., AT&T, Verizon, Level 3), Enterprise WANs with MPLS VPNs, Metro Ethernet services, SD-WAN overlays often use MPLS underlay for reliability, Broadcast/media contribution (e.g., remote production links with guaranteed bandwidth/QoS)

While MPLS is still dominant in service provider cores, many networks are transitioning toward Segment Routing (SR-MPLS or SRv6), which simplifies MPLS by encoding paths in packet headers, or pure IP-based solutions with EVPN/VXLAN in data centers/cloud. ), Carrier Ethernet Carrier Ethernet is a standardized, high-performance Ethernet-based service offered by telecommunications carriers (service providers) to deliver reliable, scalable, and cost-effective connectivity — essentially "Ethernet in the WAN" for businesses, data centers, mobile backhaul, and broadcast/media applications.

It extends the familiar LAN Ethernet technology (IEEE 802.3) across metropolitan, regional, and wide-area networks using carrier-grade features. , Routed networks, Remote production ( REMI )

PTP Domains

PTP domians are typically local. But let’s say hypothetically you did extend one PTP domain from Tokyo to New York across a WAN:

Every Boundary Clock or Transparent Clock along the route would indeed update or correct the timing offset based on the link delay it measures.
Boundary Clocks terminate one PTP segment and re-generate a new set of Sync/Follow_Up/Delay_Req messages, establishing a new offset at each hop.
Transparent Clocks don’t create a new offset, but they add a correction field to each PTP packet, indicating how long the packet was delayed inside the switch.
Those cumulative correction values let the slave calculate a more accurate one-way delay.

For broadcast engineers transitioning from SDI/genlock thinking:
Transparent Clock ≈ Frame synchronizer correcting path delay
Boundary Clock ≈ New blackburst generator locked to upstream

However, Over a transcontinental IP route, with variable latency, queuing, and asymmetry, those corrections become almost meaningless. PTP can’t accurately account for unpredictable network jitter or routing changes.

So, In global broadcast and data center systems:

Each region (Tokyo, NYC, London, etc.) runs its own stable local PTP island.
All Grandmasters in those islands are disciplined to UTC via GPS, GLONASS, or atomic time.
The resulting timestamps are all within a few hundred nanoseconds globally, without ever sending PTP messages across the ocean.

Then media streams (e.g., SMPTE 2110) carry timestamps already aligned to UTC, so synchronization holds even across sites.

PTP is not designed to span the globe directly. Normally, each region, such as a Tokyo camera network and a New York cluster, operates within its own PTP domain, each synchronized to a local Grandmaster Clock.

Those Grandmasters, in turn, synchronize to a common reference (typically GNSS/GPS, or sometimes another master clock) so that both domains are “in step” globally, even though PTP messages don’t cross oceans.

Bottom line is that long-haul WANs are not PTP aware. They experience variable latency, which breaks accuracy.

Let's see why the WAN portion of our long-haul path breaks the timing chain.

By default, a WAN (Wide Area Network) operates at Layer 3 (the Network Layer) of the OSI model. That means:

It uses IP routing. Packets are forwarded based on IP addresses, not MAC addresses.
Each hop (router) typically terminates Layer 2 frames and creates new ones on the outgoing interface.
Because Layer 2 doesn’t extend end-to-end, Ethernet timing info (like PTP correction fields) is lost.

So: Most WANs are not Layer 2-aware and can’t support PTP transparency or residence-time correction.

There's always exceptions. Some carriers sell “L2 WAN” services, often called Carrier Ethernet, Metro Ethernet, or PTP-transparent links. They can transport timing-sensitive traffic between cities (though latency still varies with fiber path length).

**WAN Types That Can Operate at Layer 2**
WAN Type	Layer 2 Support	Notes
MPLS (L2VPN / E-LINE / E-LAN)	Partial ✅	Carrier uses pseudo-wires or MAC-in-MAC; can carry PTP transparently depending on configuration and equipment.
Ethernet Private Line (EPL)	Yes ✅	True Layer 2 point-to-point; appears as an Ethernet extension between sites.
Ethernet Virtual Private LAN Service (VPLS)	Yes ✅	Multi-site Layer 2 over MPLS; may introduce latency variation.
DWDM / Optical Transport	Yes ✅	Physical Layer 1/2 transport; can support deterministic timing.
Internet VPN (IPSec / GRE)	No 🚫	Encapsulates Layer 3; does not preserve Layer 2 continuity.

Summary:

**PTP Feasibility by WAN Scenario**
Scenario	Layer	PTP Feasibility	Notes
Standard Internet WAN	L3	❌ Poor	High jitter, no timing transparency
MPLS L3 VPN	L3	⚠️ Limited	No clock correction unless explicitly supported
MPLS L2VPN / Carrier Ethernet	L2	✅ Good	PTP Transparent or Boundary mode possible
Private fiber / dark fiber	L1 / L2	✅ Excellent	Often used in broadcast and finance applications

Eliminating the middle layers

There is a method of moving media, without the Network and transport layers. This eliminates a lot of processing and allows for more acurate PTP timestamps. It is called the PTP Stack (also known as PTP over Ethernet packets, Layer 2 PTP packets, PTPv2 Ethernet-encapsulated messages, IEEE 802.3 PTP frames (using EtherType 0x88F7)).

They are not IP packets — there is no IP header, no UDP header, and no TCP. This is the "native" or "direct" Ethernet mode for PTP, distinct from the more common UDP/IPv4 or IPv6 encapsulation (which uses ports 319/320).

What is a PTP Stack? (PTP over Layer 2)
A PTP stack is the complete software layer (or set of components) that implements the Precision Time Protocol (IEEE 1588) on a device using only RTP and the layer 2 Ethernet layer.. It manages:

Sending and receiving PTP messages (Sync, Announce, Delay_Req, Follow_Up, etc.)
Running the Best Master Clock Algorithm (BMCA) to elect the Grandmaster
Maintaining clock state (master, slave, boundary clock)
Performing delay measurements and offset calculations
Adjusting the local hardware/software clock to stay synchronized
Handling different PTP profiles (e.g., default, SMPTE ST 2059-2 for 2110, gPTP/802.1AS)
Supporting both Layer 2 (direct Ethernet) and Layer 3 (UDP/IP) transports

It's essentially the "protocol engine" that turns a generic clock into a PTP-capable clock.

The PTP stack is created and provided by:
Open-Source Projects (most common for Linux/embedded systems):
linuxptp — The de facto standard open-source PTP implementation for Linux (ptp4l, phc2sys, ptp4l, etc.). Widely used in servers, switches, cameras, and broadcast gear.
Zephyr RTOS PTP stack — For embedded/real-time OS devices.
PTPd — Older open-source daemon A daemon is a background process that runs continuously on a computer system to provide a service or perform maintenance tasks without direct user interaction. In practical terms a daemon is a program that runs quietly in the background, waiting to do work when needed. , still used in some systems.

Commercial / Vendor-Specific Stacks:
Oregano Systems syn1588® PTP Stack — Portable, certified for SMPTE/ISPCS plugfests.
SEGGER emNet PTP — For embedded systems with hard real-time needs.
Other vendor-provided stacks from NIC/chip makers (Intel, Broadcom, NXP, Texas Instruments, Mellanox/NVIDIA) — Often integrated into drivers/firmware for hardware timestamping support
Proprietary implementations in broadcast equipment (Evertz, Grass Valley, Ross Video, etc.) for SMPTE 2110 compliance.

Hardware + Software Combination:
The stack runs in user space (e.g., linuxptp ptp4l daemon) or kernel/firmware.
It interacts with hardware timestamping support in NICs/PHYs (via kernel APIs like SO_TIMESTAMPING or PHC — PTP Hardware Clock).
For highest accuracy, the stack configures hardware timestamping; without it, software-only timestamping is used (much less precise).

In short: The PTP stack is the software that makes a device speak and understand PTP — created by open-source projects (like linuxptp), commercial vendors, or embedded OS stacks, and it runs on top of the network driver to synchronize clocks with nanosecond-level precision in networks like SMPTE ST 2110.

The graphic above does not show a standard IP-over-Ethernet frame (which would have EtherType 0x0800 for IPv4, followed by IP header, UDP, etc.).

It shows PTP running natively over Ethernet (Layer 2 PTP encapsulation), as defined in IEEE 1588 Annex F and commonly used in:
SMPTE ST 2110 broadcast environments
IEEE 802.1AS (gPTP for AVB/TSN)
Industrial automation, power utilities, and other precision timing networks

The "Type (2 bytes)" field is labeled as the EtherType 0x88F7, which identifies the payload as PTP (not IPv4, IPv6, ARP, etc.).
The graphic simplifies the full Ethernet frame by omitting:
Preamble + SFD (8 bytes, not part of the header shown)
Optional 802.1Q VLAN tag (4 bytes, often present in real PTP deployments)
The full PTP payload (which varies: 34+ bytes for Sync messages, etc.)

It focuses on the core header + EtherType + FCS to highlight how PTP rides directly on Ethernet for low-latency, hardware-timestamp-friendly transport.

In short: The diagram illustrates a Layer 2 Ethernet frame specifically carrying PTP timing/synchronization traffic (EtherType 0x88F7), commonly seen in professional media, AV-over-IP, and time-sensitive networking (TSN) setups where sub-microsecond accuracy is required without IP overhead.

PTP Packet Distribution

PTP syncs OS time, which is used by apps on the node (More info: see NTS)

Let's look in greater detail how PTP is distributed to where it is needed. PTP packets are their own protocol messages defined by IEEE 1588 (PTPv2).
They are not: RTP, SMPTE ST 2110 media packets, NMOS, NTP, or any generic Ethernet frame.

They are dedicated timing protocol messages used only for clock synchronization.

As we have seen common PTP message types:
Sync, Follow_Up, Delay_Req, Delay_Resp, Announce, Management, and Signaling

PTP packet inside a Ethernet packet

These messages exist specifically for:
Clock alignment, Grandmaster election (BMCA), Delay measurement, and Monitoring

∴ PTP packets are unique protocol packets, not embedded inside ST 2110 media streams. But they are often inserted into Ethernet packets.

This occurs when PTP is distributed via Layer 2 (Ethernet) - Preferred in broadcast (ST 2059 / ST 2110)
Direct Ethernet frames, EtherType: 0x88F7
Thus: No IP, No UDP, No TCP are involved in the network and transport layers above.

This creates: Lower latency, is more deterministic, and there is no IP stack delay
It also allows hardware timestamping at PHY/MAC layers.
When you're synchronizing: Video at 59.94 Hz, Audio at 48 kHz, Across dozens or hundreds of devices you need sub-microsecond precision — ideally <100 ns.

Layer 2 makes that easier and more stable.
Preferred for ST 2110 professional media networks

This is called: PTP over Layer 2

The other option, which is the only stack option we've looked at up until now is to use the normal stack, and not the abbreviated option we just looked at. This is common in:Enterprise networks, Telecom networks, IT environments. It runs on Layer 3, and it is known as the PTP over UDP/IP option.

Here PTP can also run over: UDP, IPv4 or IPv6, Multicast or unicast.
Its uses ports:
319 (Event messages: Sync, Delay_Req)
320 (General messages: Announce, Follow_Up, etc.)

Important: PTP packets are separate from ST 2110 traffic
In a typical ST 2110 network you have:
• PTP traffic (timing)
• ST 2110-20 (video RTP)
• ST 2110-30/31 (audio RTP)
• ST 2110-40 (ANC data RTP)
• NMOS control traffic
PTP is the timing foundation that everything else locks to.

In Conclusion: Why Bypass (Cut Out) IP and TCP/UDP Layers in PTP over Ethernet?
In the graphic you can see the Ethernet frame with PTP directly encapsulated, the IP (Layer 3) and TCP/UDP (Layer 4) layers are bypassed to optimize for precision, low latency, and determinism in timing-critical environments like SMPTE ST 2110 broadcast production, industrial automation, or AVB/TSN networks.

Here's why:
Lower Overhead and Latency: IP adds a 20-byte header (IPv4) or 40-byte (IPv6), and UDP adds 8 bytes. Skipping them reduces packet size and processing time at each hop. PTP needs sub-microsecond accuracy — extra layers introduce variable delay (e.g., from IP routing decisions or UDP checksums).

Hardware Timestamping: PTP relies on precise timestamps at the PHY/MAC level (Layer 1/2). Direct L2 encapsulation allows hardware (NICs, switches) to timestamp packets right at the Ethernet interface, avoiding software/OS stack delays from higher layers.

Deterministic Networks: In real-time systems (e.g., video over IP), predictable packet paths are crucial. IP/UDP can introduce jitter from routing/congestion. L2 PTP uses multicast Ethernet (no routing needed in a flat network), ensuring consistent, low-jitter delivery.

Profile-Specific Requirements: PTP profiles like SMPTE ST 2059-2 or IEEE 802.1AS (gPTP) mandate or prefer L2 transport for highest precision. UDP/IP mode (Layer 3/4) is used for routed/WAN scenarios but sacrifices some accuracy.

This "cutout" is optional — PTP can run over UDP/IP (ports 319/320), but direct Ethernet (EtherType 0x88F7) is preferred in controlled, high-precision LANs.

How Are These Packets Routed/Forwarded?
Since this is Layer 2 PTP (no IP), packets aren't "routed" in the traditional IP sense (no Layer 3 routers involved). Instead, they are switched/forwarded at Layer 2:

Multicast MAC Addressing: PTP messages use reserved multicast MAC addresses (e.g., 01-1B-19-00-00-00 for general multicast, 01-80-C2-00-00-0E for peer delay). The destination MAC in the Ethernet header is multicast, so switches flood them like broadcast unless optimized.

Layer 2 Switching: Basic Switches: Treat PTP as multicast and forward to all ports in the VLAN (potential flooding).

PTP-Aware Switches (Transparent Clocks or Boundary Clocks): Correct for residence time (delay in the switch) by timestamping and adjusting PTP messages. Forward based on MAC tables or multicast pruning.

IGMP Snooping / MLD Snooping:

Across Subnets/VLANs: If the network spans VLANs or subnets, a Layer 3 router (with PTP Boundary Clock support) or VLAN bridging is needed. The router acts as a PTP master/slave, regenerating messages on the other side — but this isn't true "routing" of the original packet; it's more like relaying.

In SMPTE 2110 / Broadcast Scenarios: PTP is confined to a single broadcast domain (flat L2 network) for minimal jitter. Distribution uses a tree-like hierarchy: Grandmaster → Boundary Clocks (in switches) → Ordinary Clocks (end devices).

In summary: Bypassing IP/TCP/UDP prioritizes timing precision; forwarding relies on L2 switching with multicast optimizations, not IP routing. For routed networks, switch to UDP/IP PTP mode.

PRP Packet is essentially the "protocol engine" that turns a generic clock into a PTP-capable clock.

Determining if a media stream (e.g., SMPTE ST 2110 video/audio/ancillary data) is using PTP directly over Ethernet (Layer 2 PTP stack, no IP/UDP) versus the full OSI stack (PTP over UDP/IP)

1. Look at the EtherType in the Ethernet Header (Most Definitive)
Capture packets with Wireshark, tcpdump, or a hardware analyzer.
EtherType = 0x88F7 → PTP is running directly over Ethernet (Layer 2 PTP stack)
→ No IP header, no UDP header. This is the native L2 mode (IEEE 1588 Annex F).
EtherType = 0x0800 (IPv4) or 0x86DD (IPv6) → PTP is running over UDP/IP (full OSI stack up to Layer 3/4)
→ You will see an IP header followed by UDP ports 319 (event messages) or 320 (general messages).

2. Check for UDP Ports 319/320 (Quick Confirmation of Full Stack)
If you see:
UDP source/destination port 319 (PTP event messages: Sync, Delay_Req, Pdelay_Req, etc.)
UDP source/destination port 320 (PTP general messages: Announce, Management, etc.)

→ The stream is using PTP over UDP/IP (full stack).

If there are no UDP headers at all and the payload starts immediately after the Ethernet header with PTP message fields → it's Layer 2 PTP (PTP stack only).

3. Look at Destination MAC Address (Supporting Clue)
Multicast MAC addresses commonly used in L2 PTP:
01-1B-19-00-00-00 (PTP primary multicast)
01-80-C2-00-00-0E (peer delay messages)

If the destination MAC is one of these and EtherType is 0x88F7 → almost certainly L2 PTP.

4. Practical Capture Examples (Wireshark Filter)
Layer 2 PTP only: eth.type == 0x88f7→ You’ll see “PTPv2” directly after Ethernet header.
But if PTP over UDP/IP:udp.port == 319 or udp.port == 320→ You’ll see Ethernet → IP → UDP → PTP.

5. In SMPTE ST 2110 Context
Most modern 2110 deployments prefer or require Layer 2 PTP (ST 2059-2 profile) for sub-microsecond accuracy and hardware timestamping.
If the system is using UDP/IP PTP, you will see IP addresses in the capture and UDP ports 319/320 — this is less common in controlled broadcast LANs but possible in routed/WAN scenarios.

Why PTP at all?

Lets stop at this point and look at a culture clash that shaped SMPTE 2110. There is the claim that “PTP was to keep the computer folks happy.” while it isn’t entirely wrong, it’s also not the whole story. Let’s unpack both perspectives; the broadcaster’s and the computer network engineer’s. Then we'll look at what really happened in the standards rooms.

The Broadcast Engineer’s Perspective (“Why complicate it?”)

From the traditional TV side, the sentiment went something like this:

“We already know how to sync systems. We’ve done it for 50 years with genlock, tri-level sync, and black burst. Why are we reinventing the wheel with this Ethernet-time nonsense?”

Their arguments:

Video doesn’t need nanoseconds

While it did back in the analog color days. with the advent of component video and the elimination of the color subcarrier, that is no longer the case.

Frame boundaries occur every 16.7 ms (59.94 Hz), so sub-microsecond sync sounds like overkill.
A little jitter can be absorbed by the buffers and frame synchronizers already in the chain.

We trust dedicated timing gear

A Tektronix or Evertz sync generator is purpose-built and rock-solid.
The idea of relying on software timestamps and network traffic felt fragile compared to a hard-wired BNC reference.

It complicates simple designs

Suddenly, you need boundary clocks, transparent switches, and grandmasters. Just to do what used to be one BNC cable.
For small local facilities, that seems like needless IP “bloat.”

In short: “PTP adds IT-style overhead to a problem we’d already solved.”

The Computer Networking Perspective (“We need a real timebase”)

Meanwhile, the data-center and IP architects said:
“If we’re going to move media into pure packet land, we can’t rely on analog timing or external wires. We need a digital clocking system that fits the network fabric.”

Their arguments:

Packets don’t arrive evenly

Ethernet and IP are asynchronous by nature — every hop adds random delay.
Without PTP, there’s no way to know when a packet was truly emitted.
A shared digital clock allows deterministic playback without huge buffers.

Scalability

In an all-IP environment (cloud, data center, or remote production), there is no central black burst generator.
Time must travel inside the packets so that distributed systems can stay coherent anywhere in the world.

Multi-domain, multi-format compatibility

Audio (AES67), control (NMOS), and video (2110) all share a unified timing model with PTP.
It’s the only standard that works across software, FPGA, and hardware layers.

In short: “PTP is the backbone of determinism in an asynchronous world.”

Additional Nuance

Why not just count on router and switcher buffers to hide timing issues? While routers and switchers can buffer, but buffers only hide timing errors. They don’t eliminate them.

PTP (Precision Time Protocol) gives the network a common wall clock so that every device knows exactly when each media sample or frame should happen. Which is essential for deterministic, real-time media flow.

Buffers smooth timing, they don’t define time. Every IP switch or router uses FIFO (First-In, First-Out) or circular buffers to handle variable packet arrival times. That’s fine for generic IP traffic like web or file transfers, but in live media, small differences in timing add up fast:

A 1-millisecond offset in video translates to a full line of HD raster misalignment. In audio, 1 ms means about 48 samples — enough to create phase problems or audible clicks. Buffers can’t fix this. They just delay or stretch to compensate until they overflow or underflow.

You could, in theory, make buffers large enough to absorb any jitter but that creates new problems:

Problems and Descriptions

Problem Description

Latency Each buffer adds delay; big buffers = high latency (bad for live switching).

Instability Variable queue depth means variable delay; hard to maintain lip sync.

Non-determinism Each path may have a different total delay, so switching between feeds causes jumps or drifts.

No global alignment You still can’t mix or key video unless all frame boundaries align to a common time base.

PTP doesn’t replace buffers. It defines when data should be presented, so buffers know how long to hold or release data.
In short: Buffers = shock absorbers PTP = speedometer and road map

You need both: one handles micro-level jitter; the other provides macro-level temporal alignment.

PTP is the IP-era descendant of genlock, filling the same conceptual role that black burst or tri-level sync once did in SDI and analog plants. But the reason we can’t just use frame syncs over IP comes down to where in the signal chain synchronization happens, and what you’re trying to synchronize to.

So in the IP World:

There’s no physical timing waveform traveling over coax.
Packets are routed asynchronously, and Ethernet/IP switches introduce variable queuing delay.
Each device must recover timing from packets and network timestamps, not an analog sync pulse.

So we replaced that continuous analog timebase with a digital timebase. The PTP clock.
PTP = distributed digital genlock.

Why not just frame-sync everything?

**Why “Just Frame-Sync Everything” Isn’t the Same**
Method	What It Does	Where It Happens	Consequence
Frame Sync	Buffers and re-clocks each signal	At every input	Adds latency, uses large memory, consumes processing
Genlock / PTP	Prevents drift by aligning clock phases	System-wide	Near-zero latency, deterministic switching

If you try to rely solely on frame syncs in an IP network:

Each feed gets delayed independently.
Timing alignment between cameras/sources is lost.
Crossfades, keys, and cuts happen on different temporal boundaries.
Latency grows with every sync stage.

It works, but you’ve traded simplicity for latency, indeterminism, and sync chaos. Especially in a multi-site or live environment. Frame syncs are still used, but sparingly. Mainly for untrusted sources (like remote contribution feeds). Bottom line - taking the opposite rail: “Frame Syncs Everywhere!” Each input isolated, again it works, but high latency, no global alignment.

So, why does PTP still matter (Even with Buffers or Frame Syncs)?
PTP gives you:

A deterministic reference for all devices (video, audio, intercom, graphics).
RTP timestamp correlation — every stream knows its place in real time.
Phase coherence — essential for keying, multiviewers, and lip-sync.
Low latency — because devices don’t need to “wait and see” if packets align.

So yes, PTP is genlock reborn, but in a way that scales across Ethernet fabrics instead of coaxial distribution amps

So, without a common clock, each device guesses when to “play out” frames. Those guesses drift apart over minutes or hours, creating lip-sync errors, frame drops, or wander.

In Summary

PTP became the compromise between hardware sync tradition and IT realism. The computer folks got their scalable, standards-based network clock (IEEE 1588).

The broadcast folks insisted that it deliver sub-microsecond precision and phase-locking equivalent to black burst.

SMPTE 2059 wrapped PTP with broadcast-specific profiles (epoch alignment, video frame rates, etc.) so that it felt like genlock — but in a packetized way.

PTP wasn’t adopted to please IT engineers. It was adopted because it was the only common timing language both camps could live with.

UPDATED

2/21/26

V260221-1.0