IEEE 1588 PTP

Note: The IEEE 1588 Working Group has introduced the terms timeTransmitter and timeReceiver as alternatives to the former master/slave terminology. This document uses these new terms.

PTP is a timing-over-packet protocol defined in the IEEE 1588 Version 2 of the standard, published in 2008. The standard was revised to Version 2.1 in 2019.

PTP provides the capability to synchronize network elements to a stratum-1 clock, PRC traceable source, or PRTC traceable source over a network that may or may not be PTP-aware. PTP is a standards-based protocol, has low bandwidth requirements, can transport frequency, time, and phase, and can potentially provide better performance.

Note: Many applications do not need time alignment but only phase alignment. However, phase is derived from time and so, for the remainder of the document, references to time with regards to PTP imply both phase and time.

The following are the basic types of PTP clocks:

ordinary clock
boundary clock
end-to-end transparent clock
peer-to-peer transparent clock

The boundary clock and ordinary clock can be used for frequency and time distribution, depending on the selected profile.

The following table describes PTP clock type support.

Table 1. PTP clock support
Platform	Ordinary clock		Boundary clock	Transparent clock
Platform	timeReceiver	timeTransmitter	Boundary clock	End-to-end	Peer-to-peer
7220 IXR-D5; model 3HE17735AB (w/Timing)	Not supported	Not supported	✓	Not supported	Not supported
7250 IXR-X1b/X3b	Not supported	Not supported	✓	Not supported	Not supported
7730 SXR	Not supported	✓	✓	Not supported	Not supported

Note: To enable ordinary clock timeTransmitter, configure a boundary clock with all PTP ports set to master-only true.

The ordinary clock timeTransmitter, ordinary clock timeReceiver, and boundary clock communicate with neighboring IEEE 1588 clocks. These neighbor clocks can be ordinary clock timeTransmitters, ordinary clock timeReceivers, or boundary clocks. The communication can be based on either unicast IPv4 sessions transported through IP interfaces or multicast Ethernet transported through Ethernet ports.

For unicast IP sessions, the external clocks are labeled ‟peers”. There are two types of peers: configured and discovered. An ordinary clock timeReceiver or a boundary clock should have configured peers for each PTP neighbor clock from which it may accept synchronization information. The router initiates unicast sessions with all configured peers. An ordinary clock timeTransmitter or boundary clock accepts unicast session requests from external peers. If the peer is not a configured peer, it is considered a discovered peer. An ordinary clock timeTransmitter or boundary clock can deliver synchronization information toward discovered peers. The following figure shows the relationship of various neighbor clocks that use unicast IP sessions to communicate with an SR Linux router configured as a boundary clock with two configured peers.

For multicast Ethernet operation, the router listens for and transmits PTP messages using the configured multicast MAC address. Neighbor clocks are discovered when messages are received through an enabled Ethernet port. An ordinary clock timeTransmitter, ordinary clock timeReceiver, and a boundary clock support more than one neighbor PTP clock connecting into a single port. This may be encountered with the deployment of an Ethernet multicast LAN segment between the local clock and the neighbor PTP ports using an end-to-end transparent clock or an Ethernet switch. The Ethernet switch is not recommended because of the introduction of packet delay variation (PDV) and the potential degradation of performance, but it can be used if appropriate for the application.

The following figure shows the relationship of various neighbor clocks using multicast Ethernet sessions to communicate with an SR Linux router configured as a boundary clock. The SR Linux router has three ports configured for multicast Ethernet communications. Port 1/2/1 of the SR Linux router shows a connection where two neighbor clocks connect to a single port of the SR Linux router through an end-to-end transparent clock.

The ordinary clock timeTransmitter, ordinary clock timeReceiver, and boundary clock support PTP operation over either unicast IPv4 or multicast Ethernet at any one time.

The IEEE 1588 standard includes the concept of PTP profiles. These profiles are defined by industry groups or standards bodies that define how IEEE 1588 is used for an application.

The SR Linux routers support the following profiles:

G.8275.1 (itug8275dot1)

This profile is restricted to PTP over Ethernet and restricts PTP ports to be physical interfaces.
G.8275.2 (itug8275dot2)

This profile is restricted to PTP over IP and restricts PTP ports to be PTP peers.

When the SR Linux routers receive an Announce message from one or more configured ports, it executes a Best timeTransmitter Clock Algorithm (BTCA) to determine the state of communication between it and its neighbors. The system uses the BTCA to create a hierarchical topology allowing the flow of synchronization information from the grandmaster clock through the network to all boundary and timeReceiver clocks. Each profile has a dedicated BTCA.

If the profile setting for the clock is itug8275dot1, the precedence order for the best timeTransmitter selection algorithm is very similar to that used with the default profile. It ignores the priority1 parameter, includes a local-priority parameter, and includes the ability to force a port to never enter timeReceiver state (master-only). The precedence is as follows:

clockClass
clockAccuracy
PTP variance (offsetScaledLogVariance)
priority2
localPriority
clockIdentity
stepsRemoved from the grandmaster

Note: If the two clocks being compared have a clockClass of less than 128, the comparison of the clockIdentity is skipped. Skipping the comparison of the clockIdentity is common because the vast majority of clocks used as grandmasters advertise a clockClass of less than 128.

The following table describes the local parameter settings when the profile setting for the clock is itug8275dot1.

Table 2. Local clock parameters: itug8275dot1
Parameter	Value and description
clock-identity	Chassis MAC address following the guidelines of 7.5.2.2.2 of IEEE 1588
clock-class	6 — local clock is using a time reference from a GNSS receiver 7 — local clock is in holdover after losing time reference from the local GNSS receiver for no more than ten minutes 135 - local clock is configured as a boundary clock and in holdover; the boundary clock was previously locked to a grandmaster clock with a clock class of 6 and is still considered to be within the holdover specification 165 — local clock is configured as a boundary clock and in holdover; the boundary clock was previously locked to a grandmaster clock with a clock class of 6 and is considered to be outside of the holdover specification 248 — local clock is configured as boundary clock
clock-accuracy	0xFE — unknown 0x21 — when using a time reference from a GNSS receiver
offset-scaled-log-variance	0xFFFF — not computed 0x4e5d (1.8E-15) — when using a time reference from a GNSS receiver

If the profile setting for the clock is itug8275dot2, the precedence order for the best timeTransmitter selection algorithm is very similar to that used with the itug8275dot1 profile. It ignores the priority1 parameter, includes a localPriority parameter, and includes the ability to force a port to never enter timeReceiver state (master-only). The precedence is as follows:

clockClass
clockAccuracy
PTP variance (offsetScaledLogVariance)
priority2
localPriority
clockIdentity
stepsRemoved from the grandmaster

Note:

If the two clocks being compared have a clockClass of less than 128, the comparison of the clockIdentity is skipped. Skipping the comparison of the clockIdentity is the normal case because the vast majority of clocks used as grandmasters advertise a clockClass of less than 128.

The following table describes the 7220 IXR local parameter settings when the profile setting for the clock is itug8275dot2.

Table 3. Local clock parameters: itug8275dot2
Parameter	Value and description
clockIdentity	Chassis MAC address following the guidelines of 7.5.2.2.2 of IEEE 1588
clockClass	6 — local clock is using a time reference from a GNSS receiver 7 — local clock is configured as a grandmaster clock and in holdover after losing time reference from the local GNSS receiver for no more than ten minutes 135 - local clock is configured as a boundary clock in holdover; the boundary clock was previously locked to a grandmaster clock with a clock class of 6 and is still considered to be within the holdover specification 165 — local clock is configured as a boundary clock in holdover; the boundary clock was previously locked to a grandmaster clock with a clock class of 6 and is considered to be outside of the holdover specification 248 — local clock is configured as a grandmaster clock or boundary clock in free-run mode 255 — local clock is configured as an ordinary clock timeReceiver
clockAccuracy	0xFE — unknown 0x21 — when using a time reference from a GNSS receiver
offsetScaledLogVariance	0xFFFF — not computed 0x4e5d (1.8E-15) — when using a time reference from a GNSS receiver

See ITU-T G.8275.2 profile for more information about the G.8275.2 profile.

There is a limit to the number of external PTP clocks from which the ordinary clock timeReceiver or boundary clock requests unicast service. There is also a limit to the number of external PTP clocks to which the ordinary clock timeTransmitter or boundary clock grants unicast service. An association where the boundary clock has a symmetric relationship with another boundary clock (they both have the other as a configured peer) consumes a request and a grant unicast service in each router.

There are limits to the maximum transmitted and received event message rates supported in the router. Each unicast IP service established consumes a portion of one of the unicast message limits. When either limit is reached, additional unicast service requests are refused by sending a grant response with zero in the duration field. See the scaling guide for the appropriate release for the specific unicast message limits related to PTP.

Multicast messages are not considered when validating the unicast message limit. When multicast messaging on Ethernet ports is enabled, you need to monitor the PTP load to ensure that the load does not exceed the limits. The show platform control detail command identifies the load of the PTP software process. If the capacity usage reaches 100%, the PTP software process on the router is at its limit of transmitting and receiving PTP packets.

Because you cannot control the amount of PTP messaging that is being received over the Ethernet ports, use the following statistics commands to identify the source of the message load. Statistics shown for PTP ports are associated with Ethernet-encapulated PTP (G.8275.1 profile) and statistics for PTP peers are associated with IP-encapulated PTP (G.8275.2 profile).

info from state system sync ptp instance <instance> default-ds statistics to display aggregate statistics
info from state system sync ptp instance <instance> port-ds-interface-list <port-index> statistics to display total messages for a specific PTP port
info from state system sync ptp instance <instance> port-ds-cfg-ip-list <port-index> statistics to display statistics for configured IP peers
info from state system sync ptp instance <instance> port-ds-dsc-ip-list <port-index> statistics to display statistics for discovered IP peers

The following figure shows the unicast negotiation procedure performed between a timeReceiver and a peer clock that is selected to be the timeTransmitter clock. The timeReceiver clock requests Announce messages from all peer clocks but only requests Sync and Delay_Resp messages from the clock selected to be the timeTransmitter clock.

Figure 3. Message sequence between the PTP timeReceiver clock and PTP timeTransmitter clock

PTP clock synchronization

The IEEE 1588 standard synchronizes the frequency and time from a timeTransmitter clock to one or more timeReceiver clocks over a packet stream. This packet-based synchronization standard defines transport to use UDP/IP with unicast or Ethernet with multicast. See PTP capabilities for information about supported PTP encapsulation types.

As part of the basic synchronization timing computation, several event messages are defined for synchronization messaging between the PTP timeReceiver clock and PTP timeTransmitter clock. A one-step or two-step synchronization operation can be used, with the two-step operation requiring a follow-up message after each synchronization message.

Note: The SR Linux routers support only one-step timeTransmitter port operation. SR Linux routers can operate timeReceiver ports that receive from a one-step or two-step timeTransmitter port.

During startup, the PTP timeReceiver clock receives the synchronization messages from the PTP timeTransmitter clock before a network delay calculation is made. Before any delay calculation, the delay is assumed to be zero. A drift compensation is activated after several synchronization message intervals occur. The expected interval between the reception of synchronization messages is configurable.

The following figure shows the basic synchronization timing computation between the PTP timeReceiver clock and PTP best timeTransmitter. This figure illustrates the offset of the timeReceiver clock referenced to the best timeTransmitter signal during startup.

Figure 4. PTP timeReceiver clock and timeTransmitter clock synchronization timing computation

When using IEEE 1588 for distribution of a frequency reference, the timeReceiver calculates a message delay from the timeTransmitter to the timeReceiver based on the timestamps exchanged. A sequence of these calculated delays contain information of the relative frequencies of the timeTransmitter clock and timeReceiver clock but has a noise component related to the PDV experienced across the network. The timeReceiver must filter the PDV effects to extract the relative frequency data, then adjust the timeReceiver frequency to align with the timeTransmitter frequency.

When using IEEE 1588 for distribution of time, SR Linux uses the four timestamps exchanged using the IEEE 1588 messages to determine the offset between the SR Linux time base and the external timeTransmitter clock time base. SR Linux determines the offset adjustment and, in between these adjustments, maintains the progression of time using the frequency from the central clock of the node. This allows time to be maintained using a Synchronous Ethernet input source even if the IEEE 1588 communications fail. When using IEEE 1588 for time distribution, the central clock should at a minimum have the PTP input reference enabled.

The following figure shows a logical model for using PTP/1588 for network synchronization.

Figure 5. Logical model for using PTP/1588 for network synchronization

Performance considerations

Although IEEE 1588 can be used on a network that is not PTP-aware, the use of PTP-aware network elements (boundary clocks) within the packet switched network improves synchronization performance by reducing the impact of PDV between the grandmaster clock and the timeReceiver clock. When IEEE 1588 is used to distribute high accuracy time, such as for mobile base station phase requirements, the network architecture requires the deployment of PTP awareness in every device between the grandmaster clock and the mobile base station timeReceiver.

In addition, performance is improved by the removal of any PDV caused by internal queuing within the boundary clock or timeReceiver clock. This is accomplished with hardware that can detect and time stamp the IEEE 1588 packets at the Ethernet interface. This capability is referred to as port-based time stamping. The SR Linux platforms that are 1588-capable support port-based time stamping (see IEEE 1588 PTP).

Note: 7730 SXR platforms equipped with a GNSS receiver can function as a grandmaster clock.

Port-based timestamping of PTP messages

To meet the stringent performance requirements of PTP mobile network applications, the 1588 packets must be time-stamped at the ingress and egress ports. This requires the use of 1588 port-based timestamping on the ports handling the PTP messages. This avoids any possible PDV that may be introduced between the port and the CPM. The ability to timestamp in the interface hardware is critical to achieve optimal performance. All PTP-capable ports support port-based timestamping.

PTP capabilities

The following table describes PTP encapsulation type and PTP profile support.

Table 4. PTP encapsulation type and PTP profile support
Platform	PTP encapsulation type		PTP profile
Platform	IPv4	Ethernet	G.8275.1 (Ethernet only)	G.8275.2 (IPv4 only)
7220 IXR-D5	✓	✓	✓	✓
7250 IXR-X1b/X3b	✓	✓	✓	✓
7730 SXR	✓	✓	✓	✓

With the G.8275.2 profile, every PTP message exchange between the router and an external 1588 clock must be established using the Unicast Negotiation procedures. The router allows the configuration of the message rate to be requested from external 1588 clocks. The router also supports a range of message rates that it grants to requests received from the external 1588 clocks.

The following table describes the ranges for the request and grant rates.

Table 5. Message rates ranges
Message type	Rates requested by SR Linux		Rates granted by SR Linux
Message type	Min	Max	Min	Max
Announce	1 packet per 16 seconds	8 packets per second	1 packet per 16 seconds	8 packets per second
Sync	1 packet per second	64 packets per second	1 packet per second	64 packets per second
Delay_Resp	1 packet per second	64 packets per second	1 packet per second	64 packets per second

State and statistics data for each timeTransmitter clock are available to assist in the detection of failures or unusual situations.

PTP boundary clock

IEEE 1588 can function across a packet network that is not PTP-aware. However, the performance may be unpredictable. PDV across the packet network varies with the number of hops, link speeds, utilization rates, and the inherent behavior of the routers. By using routers with boundary clock functionality in the path between the grandmaster clock and the timeReceiver clock, one long path over many hops is split into multiple shorter segments, allowing better PDV control and improved timeReceiver performance. This allows PTP to function as a valid timing option in more network deployments and allows for better scalability and increased robustness in specific topologies, such as rings.

Boundary clocks can simultaneously function as a PTP timeReceiver of an upstream grandmaster (ordinary clock) or boundary clock, and as a PTP timeTransmitter of downstream timeReceivers (ordinary clock) and boundary clocks, as shown in the following figure. The time scale recovered in the timeReceiver side of the boundary clock is used by the timeTransmitter side of the boundary clock. This allows time to be distributed across the boundary clock.

When a 7730 SXR router with an enabled GNSS port is configured with boundary clock functionality, the boundary clock acts as a grandmaster clock. The timeReceiver function stops and the timeTransmitter ports use frequency and time recovered from the GNSS port.

ITU-T G.8275.2 profile

SR Linux supports Recommendation ITU-T G.8275.2, which, similar to Recommendation ITU-T G.8275.1, specifies the architecture that allows the distribution of time and phasing. ITU-T G.8275.1 supports full timing support from the network and ITU-T G.8275.2 supports partial timing support (PTS).

When the SR Linux router is configured to use the G.8275.1 or G.8275.2 profile, it uses an alternate BTCA for best timeTransmitter clock selection. This BTCA includes a PTP dataset comparison that is defined in IEEE 1588-2008, but with the following differences:

the priority1 attribute value is removed from the dataset comparison
the master-only parameter value must be considered
multiple active grandmaster clocks are allowed; therefore, the BTCA selects the nearest clock of equal quality
a port-level local-priority attribute value is used to select a timeReceiver port if two ports receive an Announce message. This attribute is used as a tiebreaker in the dataset comparison algorithm if all other previous attributes of the datasets being compared are equal.
the local-priority parameter value is considered for the default dataset

When the PTP clock is configured to use the G.8275.2 profile without GNSS configured, the clock operates using PTS.

The following table describes the mapping between ITU-T G.8275.2 and PTP clock types.

Table 6. Mapping between ITU-T G.8275.2 and PTP clock types
Clock type from ITU-T G.8275.2	Description	Clock type from IEEE 1588
T-GM	timeTransmitter ordinary clock (clock with a single PTP port; cannot be a timeReceiver from another PTP clock)	Ordinary clock
T-GM	timeTransmitter boundary clock (clock with multiple PTP ports; cannot be a timeReceiver from another PTP clock)	Boundary clock^¹
T-BC-P (partial)	Boundary clock (may become a grandmaster clock, or may be a timeReceiver from another PTP clock)	Boundary clock

¹ As defined by IEEE 1588, a clock with multiple PTP ports is a boundary clock.

PTP message encapsulations

The SR Linux implementation of PTP over Ethernet provides support for PTP within raw Ethernet (no VLAN header) encapsulation.

SR Linux platforms that support PTP over IPv4 support the following encapsulations:

PTP within UDP/IPv4 within raw Ethernet (no VLAN header)

No other encapsulations are supported.

1PPS interfaces

The 1PPS interfaces are supported in SR Linux. These interfaces output the recovered signal from the system clock when PTP is enabled. 1PPS interfaces are supported on 7730 SXR and 7220 IXR-D5 platforms.

Note: 1PPS signals must not be used when PTP is not enabled. Additionally, these interfaces are output interfaces.

Configuration guidelines and restrictions for PTP

The PTP timeReceiver and timeTransmitter capabilities are available on all Ethernet ports, except the management port and 7220 IXR-D5 SFP+ ports 33 and 34
1PPS interface signals are enabled when both PTP and the 1 PPS interface are enabled. 1PPS interface signals can be used after the system is configured to use PTP as a reference and is locked to PTP.