The Sync Monitor reverse PTP mechanism

Five Minute Facts About Packet Timing

By Doug Arnold

Since timing is a critical component of many networked systems, there is a desire among network operators to measure the time distribution performance in their networks. This includes logging time compliance for regulations such as MiFID II, as well as well as for general performance monitoring.

To this end Meinberg has developed Sync Monitor. Since the initial development of Sync Monitor other equipment manufacturers and open source projects have added support for this tool as well, allowing it be used in networks which include network appliances with precise timing from a variety of vendors. Sync Monitor is a software application which allows a time server or monitoring node to gather timing error information from time clients/slaves to monitor their compliance to target accuracies. Sync Monitor can use data from 1PPS signals, NTP or PTP. For monitoring PTP the tool uses self reported information from PTP slave ports, as well as measuring those ports through the network.

To measure the accuracy of the time at a PTP slave port, Sync Monitor includes a mechanism for transferring time from the slave to a monitoring port. A mechanism sometimes referred to as “reverse PTP.” Figure 1 shows the sequence of messages used for the reverse time transfer.

The monitoring node sends a Delay Request message to the slave port with a special TLV attached. A slave port, which is modified to support this function, responds with a Delay Response message, with a different TLV. Then the slave port sends a Sync message, and if it is a two step port, a Follow Up messages. So the slave is transferring its time to the monitoring node, rather than receiving time from a master port, which is why this is often referred to as reverse PTP. Note that although a supporting slave port is sending messages it normally receives, and receiving messages it normally sends, they are all messages which the slave port is familiar with. This was thought to be preferable to defining new PTP messages. The frequency with which this message exchange occurs can be much less than that which is used for time transfer, since this is only for monitoring, rather than for feeding a servo loop which is steering a clock.

The structure of the TLV attached to the Delay Request message is shown in Figure 2.

Let’s look at the fields in the TLV. The TLV type in this case simply says this is an organization specific TLV, that is 0x0003, as opposed to one of the TLVs defined in the IEEE 1588 standard itself. The lengthField informs the receiving node as to how many more octets of TLV to expect. The OrganizationID (0xEC4670) identifies Meinberg as the organization which defined this TLV. Finally the OrganizationSubType contains a number (0x000003) which means “yo slave port, this TLV is initiating a Sync Monitor reverse PTP exchange.”

Older versions of Sync Monitor attached a different TLV to the Delay Request messages. That TLV is shown in Figure 3.

This TLV is still supported by Sync Monitor, but is deprecated. In the legacy version the tlvType, the OrganizationID, and the OrganizationSubType were all combined into one number, 0x21FE. Unfortunately that number is defined in IEEE 1588 as from the range of “experimental” tlvType values. The experimental tlvTypes are set aside for people to use playing around in the lab, in other words site local use. So another organization might use 0x21FE for a different purpose. Now that Sync Monitor is used in commercial networks the format of Figure 2 is preferred.

The TLV attached to the Delay Response message is shown in Figure 4.

The organizationSubType for this messages is 0x000002. This TLV includes a field for portState. Wait, what? I thought we knew that we were monitoring a port in the slave state. Well, usually, but it could be a port on a boundary clock in the passive state. Or the port could be in a state we don’t expect, which would be a good for the monitoring node to know. The parentDataSet, currentDataSet, and timePropertiesDataset are all defined in IEEE 1588. They contain information about where a port gets its time from and what it knows about that time. I loved to tell you more about these data sets, but then I would break my promise of taking only five minutes of your time.

Just as with the Delay Request TLV, SyncMonitor originally used a TLV which did not have a OrganizationID, or a OrganizationSubType, and instead sets the experimental tvlType to 0x21FF. Again, this structure is still supported, but is deprecated. The structure of Figure 4 is preferred.

I want to thank my colleague, Thomas Behn, for help with the details of Sync Monitor.

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