What’s in the 2019 edition of 1588: Slave port monitoring

Five Minute Facts About Packet Timing

By Doug Arnold

Next in the series on What is in the 2019 edition of IEEE 1588 is slave port monitoring, also known as slave event monitoring. Sometimes it is not enough to transfer time accurately from a PTP Grandmaster (GM) to a PTP Slave (slave). Sometimes you also need to prove that you did it. Justifications for proving it include:

• Building an archival log of time synchronization for regulatory purposes.
• Convincing your customers, external or internal, that you are providing good time.
• Because you are experienced enough to be paranoid about the ongoing performance of any networked system

See previous posts on Sync Monitor for discussion on the importance of monitoring in a PTP system.

In the coming revision to IEEE 1588 some TLVs were created to allow PTP Slaves to transfer information to a monitoring node.  This is a different approach to monitoring than the reverse PTP mechanism used by Sync Monitor.

Figure 1. Network with PTP Grandmaster, monitoring node, and monitored PTP Slave.

The monitoring node could also be the grandmaster clock, a backup grandmaster or a dedicated monitoring node.

The way that this works is indicated in Figure 2.

Figure 2. Sequence diagram for time transfer to and monitoring of a PTP Slave.

In this example the messaging is 1-step, and the Delay Request and Response mechanism (end to end) is used. In this case monitoring information is sent after four sync intervals, but the monitoring messages can save information for any number of PTP messages before sending a monitoring message.

The Slave Event Monitoring section of the 1588 revision defines three TLVs, which can be attached to a PTP signaling message which is sent to the monitor. The three TLVs structures are:
• Slave RX Sync Timing Data TLV
• Slave TX Event Timesatamps TLV
• Slave RX Sync Computed Data TLV

Figure 3. Slave RX Sync Timing Data TLV structure.

Figure 3 shows the TLV for sending the received Sync data. For now, you can ignore the scaledCumulativeRateOffset field. This is used in a new optional feature which will be discussed in a future post. Note that the TLV can contain information related a single Sync message or for several Sync messages. The TLV is not limited to the use of Sync messages, but rather can be used for any received timing message such as Delay Response or Peer Delay Response.

The TX Event Timestamps TLV similarly contains information related transmitted event messages, e.g.. Delay Request messages, or Peer Delay Request messages. Lastly the RX Sync Computed Data TLV delivers the slave’s computation of its offset and network delay from its master.
Two critical things are not addressed in the 1588 revision: How to establish a common understanding of which monitoring TLVs will be sent, and how often; and a way to organize the received monitoring data and present it to a user. So the 1588 revision presents only part of a monitoring function. So further development will be required in the 1588 Working Group, or in profile defining organizations.

If you have any questions about packet timing, don’t hesitate to send me an email at doug.arnold@meinberg.de or visit our website at www.meinbergglobal.com.