ELSEIF
Your brief EB
298 stories from 105 feeds 324 clusters Refreshed 3 minutes ago next pull 02:21

LANGUAGES Signal 162

RFC 10030 standardises NTP encapsulation in PTP for hardware timestamping support

RFC 10030 defines a transport method to carry NTP messages within PTP packets, enabling hardware timestamping on NICs limited to PTP filtering

WHY IT MATTERS

This change allows NTP to leverage existing PTP hardware timestamping capabilities in NICs and network devices, improving time synchronisation accuracy without requiring new hardware. It bridges a gap where NTP implementations were previously unable to use PTP-optimised timestamping, particularly in environments with transparent clocks.

Written by elseif from the cluster below · every claim links back to a source

The three things worth knowing

01

NTP messages are encapsulated in PTP packets using a new TLV and extension field

02

Hardware timestamping support is extended to NTP by piggybacking on PTP-compatible NICs

03

The standard enables NTP to work with PTP transparent clocks for delay correction

THE READ

What the cluster adds up to.

ORIGINAL ANALYSIS

RFC 10030 addresses a hardware limitation where NICs can timestamp only PTP packets, not NTP. By encapsulating NTP messages within PTP packets, the standard allows NTP to use existing PTP timestamping hardware. This is particularly useful in environments where NICs filter packets for timestamping at a limited rate, as PTP filtering can be configured to include NTP-over-PTP packets. The change does not require modifications to the NTP protocol itself but introduces a new transport method that coexists with existing NTP modes.

The standard specifies a new PTP type-length-value (TLV) to carry NTP messages and an NTP extension field to handle corrections from PTP transparent clocks. This enables NTP to benefit from one-step end-to-end (E2E) transparent clocks, which measure and correct forwarding delays in network devices. However, the solution is limited to unicast messaging and does not support NTP broadcast mode, which may restrict its applicability in some multicast-heavy environments.

Adopting this transport requires no changes to NTP clients or servers beyond implementing the new encapsulation and extension field. The cost lies in ensuring compatibility with PTP hardware and transparent clocks, which may not be universally available. Where PTP support exists, the standard allows NTP to achieve higher accuracy by leveraging hardware timestamping and delay corrections. However, it does not disrupt existing PTP deployments, as NTP-over-PTP operates independently of other PTP clocks in the network.

The standard is most valuable in networks where PTP hardware is already deployed but NTP is the preferred time synchronisation protocol. It eliminates the need for separate timestamping hardware for NTP, reducing complexity and cost. However, its effectiveness depends on the presence of PTP-compatible NICs and transparent clocks, which may not be standard in all network environments. The solution is a pragmatic workaround rather than a replacement for native PTP or NTP implementations.

Written by elseif from the cluster below · checked for specifics the sources never contained

THE CLUSTER

Same story, 1 feed.

ORDERED BY FIRST SEEN
Recent RFCs RFC 10030: Network Time Protocol (NTP) over the Precision Time Protocol (PTP) Open ↗