Implementation Details of the PTPv2 Time Synchronization Protocol

Introduction

The concept of building a “Digital Substation” in the electric power industry requires synchronization with an accuracy of 1 μs. Financial transactions also require microsecond accuracy. In these applications, NTP time accuracy is no longer sufficient.

The PTPv2 synchronization protocol, described by the IEEE 1588v2 standard, allows synchronization accuracy of several tens of nanoseconds. PTPv2 allows you to send synchronization packets over L2 and L3 networks.

The main areas where PTPv2 is used are:

• power engineering;
• control and measuring equipment;
• military-industrial complex;
• Telecom
• financial sector.

This post looks at how the PTPv2 synchronization protocol works.

We have more industry experience and we often come across this protocol in energy applications. Accordingly, we will do the review with an eye on energy .

Why is it necessary?

Currently, STO 34.01-21-004-2019 of PJSC Rosseti and STO 56947007-29.240.10.302-2020 of PJSC FGC UES contain requirements for organizing a process bus with time synchronization via PTPv2.

This is due to the fact that relay protection terminals and measuring devices are connected to the process bus, which transmit instantaneous values ​​of current and voltage through the process bus using so-called SV streams (multicast streams).

Relay protection terminals use these values ​​to implement connection protection. If the accuracy of measurements over time is small, then some protections may work out falsely.

For example, the protection of absolute selectivity may become a victim of “weak” time synchronization. Often the logic of such defenses is based on a comparison of two values. If the values ​​diverge to a sufficiently large value, then the protection is triggered. If these values ​​are measured with an accuracy of 1 ms, then you can get a big difference where the values ​​are actually normal, if you measure them with an accuracy of 1 μs.

PTP Versions

The PTP protocol was originally described in 2002 in the IEEE 1588-2002 standard and was called “Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”. In 2008, the updated IEEE 1588-2008 standard was released, which describes the PTP Version 2. In this version of the protocol, accuracy and stability were improved, but backward compatibility with the first version of the protocol was not preserved. Also, in 2019, a version of the IEEE 1588-2019 standard was released that describes PTP v2.1. This version adds minor improvements to PTPv2 and is backward compatible with PTPv2.

In other words, we have the following picture with the versions:

	PTPv1 (IEEE 1588-2002)	PTPv2 (IEEE 1588-2008)	PTPv2.1 (IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)	-	Incompatible	Incompatible
PTPv2 (IEEE 1588-2008)		—
PTPv2.1 (IEEE 1588-2019)			—

But, as always, there are nuances.

The incompatibility between PTPv1 and PTPv2 suggests that a device with PTPv1 support will not be able to synchronize from the exact clock running on PTPv2. They use different message formats for synchronization.

But you can still combine devices with PTPv1 and devices with PTPv2 on the same network. To do this, some manufacturers allow you to select the protocol version on the ports of the border clock. That is, the boundary clock can be synchronized via PTPv2 and at the same time synchronize other clocks connected to it both by PTPv1 and PTPv2.

PTP devices. What are and how do they differ?

The IEEE 1588v2 standard describes several types of devices. All of them are given in the table.

Devices communicate with each other via LAN using PTP.

PTP devices are called clocks. All watches take the exact time from the grandmaster watch.

There are 5 types of watches:

Grandmaster clock	The main source of accurate time. Often equipped with an interface for connecting GPS.
Ordinary Clock	A single-port device that can be a master (master clock) or a slave (master clock)
Leading hours (master)	They are the source of the exact time by which other clocks are synchronized
Slave Clock (Slave)	The end device that syncs from the master clock
Boundary Clock	A device with multiple ports, which can be a master or a slave. That is, this watch can synchronize from a higher master clock and synchronize a lower slave clock.
End-to-end Transparent Clock ( , End-to-End)	, , . PTP . PTP-. .
Peer-to-Peer Transparent Clock ( , Peer-to-Peer)	A device with multiple ports that is neither a master clock nor a slave. It transmits PTP data between two hours. When transmitting data, the transparent clock corrects all PTP messages Sync and Follow_Up (more about them is described below). Correction is achieved by adding to the field of the adjustment of the transmitted delay packet on the transmitting device and the delay on the data channel.
Management Node	A device that configures and diagnoses other watches

The master and slave clocks are synchronized using time stamps in PTP messages. There are two types of messages in the PTP protocol:

• Event Messages are synchronized messages that involve the generation of a time stamp at the time a message is sent and at the time it is received.
• General Messages – ,

Event Messages	General Messages
Sync Delay_Req Pdelay_Req Pdelay_Resp	Announce Follow_Up Delay_Resp Pdelay_Resp_Follow_Up Management Signaling

Next, we will consider all types of messages in more detail.

Main problems of synchronization

When transmitting a synchronization packet through a local network, it is delayed on the switch and in the data transmission channel. Any switch will give a delay of about 10 μs, which is unacceptable for PTPv2. After all, we need to get an accuracy of 1 μs on the final device. (This is when it comes to energy. Other applications may require more accuracy.)

IEEE 1588v2 describes several operation algorithms that allow you to record the time delay and adjust it.

Operational algorithm
During normal operation, the protocol operates in two phases.

• Phase 1 - Establishment of the “Leading Clock - Slave Clock” hierarchy.
• Phase 2 - clock synchronization using the End-to-End mechanism or Peer-to-Peer.

Phase 1 - Setting up the Master Slave hierarchy

Each port of a regular or boundary clock has a certain number of states (slave clock and master clock). The standard describes the transition algorithm between these states. In programming, such an algorithm is called a state machine or state machine (more on the Wiki).

This state machine uses the Best Master Clock Algorithm (BMCA) to set the master when two hours are connected.

This algorithm allows the watch to assume the obligations of a grandmaster watch when a superior grandmaster watch loses its GPS signal, disconnects from the network, etc.

State transitions in accordance with BMCA are briefly shown in the following diagram:


Information about the clock on the other end of the “wire” is sent in a special message (Announce message). When this information is received, the state machine algorithm processes and compares which clock is better. The port on the best watches becomes the leading watch.

A simple hierarchy is presented in the diagram below. Paths 1, 2, 3, 4, 5 may contain a transparent clock (Transparent clock), but they do not participate in the establishment of the hierarchy “Leading clock - Slave clock”.



Phase 2 - Synchronization of a normal and a boundary clock

Immediately after the hierarchy “Leading hours - Slave hours” is established, the synchronization phase of a regular and boundary clock begins.

For synchronization, the master clock sends a message containing a time stamp to the slave clock.

Leading hours can be:

• single stage;
• two-stage.

A single-stage clock for synchronization sends one Sync message.

A two-stage clock uses two messages for synchronization - Sync and Follow_Up.

Two mechanisms can be used for the synchronization phase:

• Delay request-response mechanism.
• Peer delay measurement mechanism.

To begin with, we will consider these mechanisms in the simplest case - when transparent watches are not used.

Delay request-response mechanism

The mechanism has two steps:

1. Measurement of the delay in transmitting a message between a master clock and a slave. It is performed using the delay request-response mechanism.
2. Corrects the shift of the exact time.

Delay Measurement


t1 - Sync message sending time by the leading clock; t2 - Sync message reception time by slave clock; t3 - Delay request sending time (Delay_Req) ​​by slave hours; t4 - Delay_Req reception time by the leading clock.

When the slave clock knows the time t1, t2, t3 and t4, they can calculate the average delay in transmitting the synchronization message (tmpd). It is calculated as follows:



When transmitting a Sync and Follow_Up message, the time delay from the master to the slave is calculated - t-ms.

When transmitting Delay_Req and Delay_Resp messages, the time delay from the slave to the master, t-sm, is calculated.

If some asymmetry occurs between these two values, an error appears in the correction of the departure of the exact time. The error is caused by the fact that the calculated delay is the average of the delays t-ms and t-sm. If the delays are not equal to each other, then we will adjust the time inaccurately.

Correcting the offset of the exact time

After the delay between the leading clock and the slave clock is known, the slave clock performs the time correction.



The slave clock uses the Sync message and the optional Follow_Up message to calculate the exact time offset when transmitting the packet from the master clock to the slave. The shift is calculated using the following formula:



Peer delay measurement mechanism

This mechanism also uses two steps to synchronize:

1. . peer delay mechanism.
2. .

Peer-to-Peer

Delay Measurement The delay between peer-to-peer- enabled devices is measured using the following messages:



When port 1 knows the times t1, t2, t3 and t4, it can calculate the average delay (tmld ) It is calculated using the following formula:



Then, the port uses this value to calculate the adjustment field for each Sync message or optional Follow_Up message that pass through this device.

The total delay will be equal to the sum of the delay during transmission through this device, the average delay during transmission through the data channel and the already contained delay in this message, included on the higher devices.

Messages Pdelay_Req, Pdelay_Resp and optional Pdelay_Resp_Follow_Up allow you to get a delay from the master to the slave and from the slave to the master (circular).

Any asymmetry between these two values ​​will introduce an accurate time offset correction error.

Correcting the offset of the exact time The



slave clock uses the Sync message and the optional Follow_Up message to calculate the offset of the exact time when transmitting the packet from the leading clock to the slave. The shift is calculated according to the following formula:



Benefits peer-to-peer adjustment - time delay of each Sync or Follow_Up message is calculated as it is transmitted on the network. Therefore, a change in the transmission path will not affect in any way the accuracy of the adjustment.

When using this mechanism, time synchronization does not require the calculation of the time delay on the path traveled by the synchronization packet, as is done with a basic exchange. Those. Delay_Req and Delay_Resp messages are not sent. In this method, the delay between the master clock and the followers is simply summed in the adjustment field of each Sync or Follow_Up message.

Another advantage is that the driving clock is unloaded from the need to process Delay_Req messages.

Modes of operation of transparent watches

Accordingly, simple examples were examined. Now suppose that switches appear on the synchronization path.

If you use switches without PTPv2 support, then the synchronization packet will be delayed by about 10 μs on the switch.

Switches with PTPv2 support in IEEE 1588v2 terminology are called Transparent clocks. The transparent clock is not synchronized from the leading clock and does not participate in the “Leading clock - Slave clock” hierarchy, but when transmitting synchronization messages, they remember how much the message was delayed by them. This allows you to adjust the time delay.

A transparent watch can work in two modes:

• End-to-end.
• Peer-to-peer.

End-to-End (E2E) The



transparent E2E watch transmits Sync messages and accompanying Follow_Up messages to all ports. Even those that are blocked by any protocols (for example, RSTP).

The switch remembers the time stamp when the Sync packet (Follow_Up) was received on the port and when it was sent from the port. Based on these two timestamps, the switch processing time for the message is calculated. In the standard, this time is called residence time.

Processing time is added to the correctionField field of the Sync message (single-stage clock) or Follow_Up (two-stage clock).



The E2E transparent watch measures processing time for Sync and Delay_Req messages passing through the switch. But it is important to understand that the time delay between the leading clock and the slave clock is calculated using the delay request-response mechanism. If the master clock changes or the path from the master clock to the slave changes, the delay is measured again. This increases the transition time in the event of network changes.



The transparent P2P clock, in addition to measuring the processing time of the message by the switch, measures the delay on the data channel to the nearest neighbor using the delay measurement mechanism of the neighboring node.

The delay is measured on each channel in both directions, including channels that are blocked by a protocol (for example, RSTP). This allows you to immediately calculate a new delay on the synchronization path if the grandmaster clock or network topology has changed.

The switch processing time and delay time are accumulated when transmitting Sync or Follow_Up messages.

Types of Support for PTPv2 Switches

Switches can support PTPv2:

• programmatically;
• hardware.

In the software implementation of the PTPv2 protocol, the switch requests a timestamp from the firmware. The problem is that the firmware works cyclically, and you have to wait until it finishes the current cycle, take the request into processing and after the next cycle expires it will issue a timestamp. All this will also take time, and we will get a delay, albeit not as significant as without PTPv2 software support.

Only the hardware support for PTPv2 allows you to maintain the necessary accuracy. In this case, the issuing of the timestamp is performed by a special ASIC, which is installed on the port.

Message Format

All PTP messages consist of the following fields:

• Header - 34 bytes.
• Body - the size depends on the type of message.
• Suffix - optional.

Header

The Header field is the same for all PTP messages. Its size is 34 bytes.

The format of the Header:



messageType field is the type of the transmitted message, for example, Sync, Delay_Req, PDelay_Req, etc.

messageLength - contains the full size of the PTP message, including header, body and suffix (but excluding fill bytes).

domainNumber — Determines which PTP domain the message belongs to.

A domain is a few different clocks assembled into one logical group and synchronized from one leading clock, but not necessarily synchronized with a clock belonging to another domain.

flags - this field contains various flags to identify the status of the message.

correctionField- contains the delay time in nanoseconds. The delay time includes the transmission delay through the transparent clock, as well as the transmission delay through the channel when using the Peer-to-Peer mode.

sourcePortIdentity - this field contains information about which port this message was originally sent from.

sequenceID - contains the identification number for individual messages.

controlField - artifact field =) It remains from the first version of the standard and contains information about the type of this message. Essentially the same as messageType, but with fewer options.

logMessageInterval - this field is determined by the type of message.

Body

As discussed above, there are several types of messages. These types are described below:

Announce message Announce
message is used to “tell” other watches within the same domain about their settings. This message allows you to set the hierarchy “Leading Clock - Slave Clock”.


Sync
message A synchronization message (Sync) is sent by the master clock and contains the time of the master clock at the time the Sync message was created. If the leading clock is two-step, then the time stamp in the Sync message will be set to 0, and the current time stamp will be sent in the paired Follow_Up message. The Sync message is used for both delay measurement mechanisms.

The message is transmitted using Multicast. You can optionally use Unicast.



Delay_Req

message The format of the Delay_Req message is identical to the Sync message. The slave clock sends Delay_Req. It contains the time that Delay_Req was sent by the slave clock. This message is used only for the delay request-response mechanism.

The message is transmitted using Multicast. You can optionally use Unicast.



Follow_Up message The Follow_Up

message is optionally sent by the master clock and contains the time the master sent the Sync message . The Follow_Up message is sent only by a two-stage driving clock.

The Follow_Up message is used for both delay measurement mechanisms.

The message is transmitted using Multicast. You can optionally use Unicast.



Message Delay_Resp

The Delay_Resp message is sent by the master clock. It contains the time the Delay_Req is received by the master clock. This message is used only for the delay request-response mechanism.

The message is transmitted using Multicast. You can optionally use Unicast.



Pdelay_Req

message A Pdelay_Req message is sent by a device that requests a delay. It contains the time the message was sent from the port of this device. Pdelay_Req is used only for the neighboring node delay measurement mechanism.



Pdelay_Resp message The Pdelay_Resp

message is sent by the device that received the delay request. It contains the time the Pdelay_Req message was received by this device. Pdelay_Resp messages are used only for the neighboring node delay measurement mechanism.



Pdelay_Resp_Follow_Up message The Pdelay_Resp_Follow_Up

message is optionally sent by the device that received the delay request. It contains the time the Pdelay_Req message was received by this device. The Pdelay_Resp_Follow_Up message is sent only by a two-stage master clock.

This message can also be used for runtime instead of a timestamp. The execution time is the time from the moment Pdelay-Req is received until the Pdelay_Resp is sent.

Pdelay_Resp_Follow_Up are used only for the neighboring node delay measurement mechanism.



Control Messages (Management Message)

PTP control messages are required to transfer information between one or more clocks and the control node.



Transfer to LV

A PTP message can be transmitted at two levels:

• Network - as part of IP data.
• Link - as part of an Ethernet frame.

Sending a PTP message over UDP over IP over Ethernet



PTP over UDP over Ethernet PTP



profiles

have many “flexible” parameters that need to be configured. For instance:

• BMCA options.
• The delay measurement mechanism.
• Intervals and initial values ​​of all configurable parameters, etc.

And despite the fact that earlier we said that PTPv2 devices are compatible with each other, in a good way it is not. Devices must have the same settings in order to interact.

Therefore, there are so-called PTPv2 profiles. Profiles are groups of configured settings and certain protocol restrictions so that you can implement time synchronization for a specific application.

The IEEE 1588v2 standard itself describes only one profile - the “Default Profile”. All other profiles are created and described by various organizations and associations.

For example, the Power Profile or PTPv2 Power Profile was created by the Power Systems Relaying Committee and the Substation Committee of the IEEE Power and Energy Society. The profile itself is called IEEE C37.238-2011.

The profile describes that PTP can be transmitted:

• Only through L2 networks (i.e. Ethernet, HSR, PRP, not IP).
• Messages are transmitted only by the Multicast mailing list.
• The Peer delay measurement mechanism is used as a delay measurement mechanism.

The default domain is 0, the recommended domain is 93.

The philosophy of creating C37.238-2011 was the desire to reduce the number of optional features and leave only the necessary functions for reliable interaction between devices and increase system stability.

Also, the frequency of message transmission is determined:



In fact, only one parameter is available for selection - the type of the leading clock (single-stage or two-stage).

Accuracy should be no more than 1 μs. In other words, a maximum of 15 transparent clocks or three boundary hours can be contained in one synchronization path.