Problems with Unicast PTP

Five Minute Facts about Packet Timing

When PTPv2 was defined the IEEE 1588 working group recognized that some networks, which could benefit from precise network timing, would not support multicast protocols.  So, a unicast version of PTP was defined in IEEE 1588-2008.  The ITU-T defined two PTP Profiles using unicast PTP, which have been used successfully in the field.  These are G.8265.1 and G.8275.2. 

While support for multicast protocols is more pervasive now than it was in 2008, some network operators outlaw it in their networks to reduce traffic.  This can be important in very large networks such as data centers.  Figure 1 shows an example block diagram of the timing system in a data center, from the Open Compute Project’s Data Center PTP Profile.  One assumption is that all of the PTP messages will be unicast.

Most unicast PTP implementations, all of them that I am aware of, use unicast negotiation.  Unicast negotiation allows PTP Nodes to negotiate time limited contracts among each other for PTP messages.  This allows grandmasters to manage their capacity, which is especially important since unicast PTP is often when there is no or only partial support in the network, so high message rates needed to reduce queuing noise. 

This brings us to our first problem.  The management of these contracts requires the Grandmaster to keep state information on all the PTP Ports that are requesting contracts for PTP messages.  In a data center with millions of servers needing time, the state management can be the limiting factor in how many timeReceivers a Grandmaster can synchronize.  Note also that high capacity PTP implementations have recently become available so that capacity management is less important.

What we really want for data centers is a simple, stateless time transfer protocol.  Something like NTP, see Figure 2.

Here is another problem: If PTP becomes available on the public internet in the future, like NTP is now, then it will likely be unicast.  Increasing support for PTP in the switches and routers will facilitate this.  Perhaps this will be useful for IoT applications that need time accuracy better that can be achieved with NTP. Unfortunately, unicast PTP with negotiation is an almost perfect Directed DOS attack amplifier, see Figure 3. 

What we need is a simple, stateless protocol, like NTP, but with PTP like hardware support.  This is why some of us in the timing standards world are discussing adding a Transparent Clock like Correction Field to NTP, and possibly creating a client-server mode of PTP.  More on these initiatives as they develop.

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.