Precision Time Protocol (PTP)

Precision Time Protocol (PTP) is defined in the IEEE 1588 standard (Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems). PTP synchronizes clocks in packet-based networks that include distributed device clocks of varying precision and stability. On a local area network, it achieves clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. PTP is currently employed to synchronize financial transactions, mobile phone tower transmissions, and networks that require precise timing but lack access to satellite navigation signals.

PTP is not supported on EVPN/VXLAN tunnels.

PTP clocks

A PTP network consists of PTP-enabled devices and devices that are not using PTP. The PTP-enabled devices typically consist of clock-aware devices such as ordinary clocks (which are usually single-port end-stations) and one or more grandsource clocks, transparent clocks, and boundary clocks (multi‑port L2/L3 time‑aware devices).

The basic clock node types include:

Grandsource clock - A grandsource clock is the primary source of time for the downstream devices. This is a device with greater clock quality which may have direct access to a reference clock.

Ordinary clock - An ordinary clock is a single port end-station (which can include a GM as the originating PTP time-aware device).

Transparent clock (8360 Switch Series only) - A transparent clock can have multiple network port connections but it does not act as either a clock-source or a clock-sink. Rather, it updates the correction field within the PTP event messages (SYNC/FOLLOW_UP, DELAY_REQUEST) to compensate for the transit time delay. Transparent clocks compensate for switch latency and jitter, making network devices appear transparent to other PTP time-aware devices. They help in reducing the end-station time errors and improving synchronization quality. But a transparent clock itself does not synchronize its time.

There are two types of transparent clocks:

• End-to-End (E2E) transparent clock—Updates the correctionField field in the PTP messages with the total time the PTP packet was resident in the network device. This is called resident time correction.
• Peer-to-Peer (P2P) transparent clock—Updates the correctionField field in the PTP messages with the sum of upstream link delay and the resident time. The upstream link delay is the estimated packet propagation delay between the upstream neighbor P2P clock and the local transparent clock.

Boundary clock—The boundary clock implements a local PTP clock where one port will act as clock-sink which synchronizes itself with the clock-source while other ports act as clock-source ports to its downstream clock-aware devices. The clock-source port is used to redistribute the clock to another set of clock-sinks. The best master clock algorithm (BMCA) is used by the boundary clock to select the best configured acceptable clock-source clock.

Best master clock algorithm

The BMCA behavior changes per profile, but is usually similar to the specified in IEEE 1588-2008 section 9.3.

The clocks broadcast information about their properties (the datasets), which is then used as an input to the selection process. These are the values used in the BMCA, sorted by descending order of preference, as in IEEE 1588-2008:

1. grandmasterIdentity: If two datasets suggest the same GM, the one with the least hops, the lower clockIdentity or the lower portIdentity will be chosen. This shall return an error if using a loopback connection.
2. priority1: An absolute priority that can be configured by the user (this value is fixed to 128 in G.8275.1 and G.8275.2).
3. clockClass: Attribute defining a clock's TAI traceability, synchronization state and expected performance.
4. clockAccuracy: Attribute defining the local accuracy of a clock.
5. offsetScaledLogVariance: An attribute defining the stability of a clock.
6. priority2: User-configurable priority that can be used as a tiebreaker when the other attributes match.
7. clockIdentity: A final tiebreaker consisting of the MAC address of the clock.

In all the inputs, the lower number is preferred, e.g. a clock with a priorty1 value of 90 is better than 100. The algorithm runs periodically, so that the device reacts quickly to any attribute changes.

The IEEE 1588 standard allows for an alternate BMCA, which can be used in cases where the default algorithm presents problems or would not suffice the requirements of the network.

The ITU-T G.8275.1-2022 section 6.3.7 and G.8275.2-2022 section 6.7.9 specify their own alternate BMCA, considering a localPriority value, which is currently non-configurable, therefore it is set to the recommended default of 128. The way the grandmasterIdentity and clock class are used as tiebreakers differs against IEEE 1588 too.

PTP network diagram

The following diagram illustrates how the various PTP clock nodes are connected and how the timing information flows from the origin to the end-stations to achieve the time synchronization. This diagram depicts the PTP clocks in a source-sink hierarchy.

Figure 1  Example PTP network with clocks in a source-sink hierarchy

Configuration examples

Configuring an end-to-end transparent clock (TC E2E)

Follow these steps to configure the E2E transparent clock:

1. Configure the mandatory commands:
1. Configure the PTP mode and the delay mechanism.
2. Configure the PTP clock-step mode.
3. Configure the transport protocol.
4. Configure PTP globally.

Switch config:

switch(config)# ptp profile aes67

switch(config-ptp)# mode transparent end-to-end

switch(config-ptp)# clock-step one-step

switch(config-ptp)# transport-protocol ip

switch(config-ptp)# enable

2. Enable PTP on the connected interfaces :

switch(config)# int 1/1/1

switch(config-if)# ptp enable

switch(config-if)# int 1/1/2

switch(config-if)# ptp enable

Configuring an end-to-end boundary clock (BC E2E)

Follow these steps to configure the end-to-end boundary clock:

1. Create the PTP context using the specified profile.

switch(config)# ptp profile aes67

2. Configure the mandatory commands:
1. Configure the PTP mode.
2. Configure the PTP clock-step mode.
3. Configure the transport protocol.
4. Configure PTP globally.

switch(config-ptp)# mode boundary end-to-end

switch(config-ptp)# clock-step one-step

switch(config-ptp)# transport-protocol ip

switch(config-ptp)# enable

3. Configure the optional commands which participate in the best clock source algorithm:
1. Configure priority1 value.
2. Configure priority2 value.

switch(config-ptp)# priority1 1

switch(config-ptp)# priority2 10

4. Enable PTP on the connected interfaces:

switch(config)# int 1/1/1

switch(config-if)# ptp enable

switch(config-if)# int 1/1/2

switch(config-if)# ptp enable

5. Optional: changing packet interval rate for various PTP parameters:

switch(config-if)# ptp sync-interval 1588v2 1 switch(config-if)# ptp announce-interval 1588v2 -5 switch(config-if)# ptp announce-timeout 1588v2 4 switch(config-if)# ptp delay-req-interval 1588v2 -3

PTPv1 passthrough

As part of the PTPv1 passthrough feature, PTPv1 packets are allowed to pass through both PTP and non-PTP aware devices. PTPv1 traffic is forwarded based on the destination MAC address and the switches do not process or route the PTPv1 traffic.

PTP support over VSX

PTP Transparent Clock is supported on VSX and supports both P2P and E2E delay mechanisms. The PTP-TC clock configuration is synchronized between VSX peers.

• PTP must be enabled and configured on the Inter Switch Link (ISL) so that the PTP packets bridged through the ISL have the correction field (CF) updated. In case of peer-to-peer (P2P) delay mechanism, the link-delay for the ISL is also determined by the PTP protocol and compensated in the CF.
• PTP for a keepalive (KA) link depends on L3 configuration. If the routing protocol is configured to forward PTP packets through a KA link, then PTP must be enabled on the KA link. In general, it is not recommended to send L3 routed packets through a keepalive link.

Missing SyncE clock source

When a device loses connection with a SyncE clock source there will be a transitional period while the algorithm selects a new clock source from the available options. During this period (typically not more than a few seconds) the QL of the device and devices synchronized downstream may change to an unexpected value. If new clock source is selected, then the final state will show the QL of the new selected source. If there are no other suitable sources the device will move to holdover state and track the internal clock or local oscillator.

Limitations, conflicts, and exclusions

On the 8325P and 9300 Switch Series:

• Unicast and multicast configurations conflict. In the case where both are configured on the system, unicast will be used and multicast will be ignored.

• To use multicast transmission, all unicast configuration must be removed. If Unicast and multicast are configured together, all Multicast ports will have their states set to Disabled, with the PTP fault reason "Unicast - Multicast configuration conflict". An WARN event log will also be displayed:

• When conflicting configurations are entered via CLI, the user will be warned via a printed message. In the case of a unicast port being configured when there are multicast ports configured, the following message will be displayed:

• In the case of a multicast port being configured when there are Unicast ports configured, the following message will be displayed:

• Transparent mode and two-step clock can be configured via REST but are not supported.

The following are not supported on the 8325P, 8360, and 9300 Switch Series:

• IPv6 support
• SMPTE mixed mode

The following are not supported on the 8325P and 9300 Switch Series:

• Peer-to-peer mode
• Transparent clock mode
• Two step option for Clock step.
• VSX/VSF is not supported along with PTP on this platform.
• Only default VRF is supported.
• Multicast and Unicast ports in the same configuration.

On the 8325P and 9300 Switch Series:

• PTP configurations require restarting the PTP service to apply, which can affect the PTP operation at system level and the PTP setting at port level.The following PTP configurations are the only exceptions:
  • Priority1 and Priority2 setting for profile
  • PTP VLAN setting at port level.

On the 8325P Switch Series:

• SyncE configurations require restarting the SyncE service to apply, which can affect the SyncE operation to reconverage based on the wait-to-restore timer configured. The downstream device can also be affected until the system is fully converged.
• LAG membership reconfiguration with SyncE configuration also requires the SyncE service to restart. If a port without any SyncE configuration is assigned to a LAG, it doesn't affect the SyncE service.

On the 8325P Switch Series:

• Disable RS-FEC on the PTP enabled 25G port to maintain Class C performance. The 25GbE port with RS-FEC enabled may cause a higher PTP timestamp error. Additionally, enabling and disabling adjacent ports (with RS-FEC) increases the timestamp error and may generate a latency change.
• RS-FEC must be disabled on peer device also to establish link. Configuring the RS-FEC setting will bounce the port.
• Mirroring on egress is not supported for any packets transmitted for CPU. Do not use mirror to capture PTP protocol packets on egress. Mirror PTP protocol packets on ingress is supported.

Hardware considerations

PTP is supported on breakout cables. PTP connections through a QSA28 (QSFP28 to SFP adapter) transceivers are not supported. DACs are not supported for use through QSA28 adapters. (Refer to the Transceiver Guide for further information.)

PTP Clients connected to 1 Gbps XCVRs on an 8360 Switch acting as the PTP boundary clock or PTP transparent clock will have a slightly higher offset when there is background data traffic between clients. This is a known limitation specifically to Clients connected only on 1 Gbps links on the HPE Aruba Networking8360 Switch Series. Clients connected on higher speed links (10/25/40/50/100) Gbps will not be impacted.