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—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—A boundary clock implements a local PTP clock where one port acts 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. Boundary clocks can also use E2E or P2P delay-mechanism, and can be configured based on the selected PTP profile. The best clock source algorithm is used by the boundary clock to select the best or most precise configured acceptable clock-source clock.

Based on hardware capability, the switch supports either boundary clock, transparent clock, or both modes.

Best clock-source algorithm

The best clock-source algorithm helps in choosing the source of timing on your network. It runs independently on each clock in a domain. This algorithm specifies the way that a local clock can determine which of all the clocks (including itself) is the best. Since it runs continuously, it continually re-adapts to changes in the network or the clocks.

Each clock sends a message to the network describing its own properties. The best clock-source algorithm running in the clock compares these properties to determine the best clock.

The comparisons of attributes happens with the following precedence :

• Priority1: user configurable absolute priority
• ClockClass: Attribute defining a clock’s TAI traceability
• Time Source: Attribute defining the accuracy of a clock
• Variance: An attribute defining the precision of a clock
• Priority2: This is a user configurable designation that provides finer grained ordering among otherwise equivalent clocks
• Clock Identity : A tiebreaker consisting of the MAC address of the clock

In addition to this precedence order, the distance measured by the number of boundary clocks between the local clock and the best clock is used when two Announce messages reflect the same best clock. The distance is indicated in the stepsRemoved field of announce messages.

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 1588v2

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

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

switch(config-ptp)# transport-protocol ethernet

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 1588v2

switch(config-ptp)#

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 ethernet

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.

Limitations, conflicts and exclusions

• Peer-to-peer transparent clock requires the clock-domain configuration for the peer-delay packets exchange, whereas the end-to-end transparent clock operates across domains. The clock-domain configuration is not considered for end-to-end transparent clock.

• Boundary clock and peer-to-peer transparent clock are not supported with VSF. Only end-to-end transparent clock is supported with VSF.

• With peer-to-peer delay-mechanism (especially two-step), having more than one end client on the same link is not a valid configuration. It is recommended to have only 1:1 peer-to-peer communication.

• If peer-delay packets are made to transit any intermediate nodes (e. g. through unicast config or intermediate L2 node, etc.) they have higher noise due to non-compensated resident time.

• Boundary clock is not supported with VSX. Only one-step transparent clock with both end-to-end and peer-to-peer mechanism is supported with VSX.

• With IPv4, ECMP is not supported on PTP BC.

• 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:

• IPv6 support
• SMPTE mixed mode

• - Boundary clock 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.

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.

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 Aruba 8360 Switch Series. Clients connected on higher speed links (10/25/40/50/100) Gbps will not be impacted.