To comply with the respective video and audio standards (SMPTE ST 2110 series & AES67) for packet-based media transfer over IP, all devices have to be synchronized with each other to less than 1µs precision. This can be accomplished reliably using the Precision Time Protocol (PTP), which is specified in the IEEE1588-2008 standard. It specifies a mechanism for accurate and efficient time transfer over Ethernet networks.

Basic Principles Of PTP

One PTP device known as an Ordinary Clock provides the reference time for the network. It is referred to as the PTP Grandmaster (GM). It continuously distributes its time information via Sync messages to all other Ordinary Clocks (PTP Slaves), which timestamp these as accurately as possible. In return, every Slave sends Delay_Request messages to the GM (usually at the same message rate), drawing a timestamp while sending them. The GM returns the received timestamp as part of a corresponding Delay_Response message. The basic PTP message flow and the four distinct timestamps drawn by the GM and the Slaves respectively is shown in Figure 1. They are used by every node to calculate the offset of its local clock, while accounting for the transmission delay of the messages over the network using the formulae given in diagram 1.

Every device is now able to adjust its clock. To prevent discontinuities, this is done adjusting the rate of the clock via appropriate control loops rather than periodically modifying the absolute time.

PTP Master Election Process

A PTP GM is elected autonomously without any user interaction. This is done by exchanging information about the clock “quality”. Every GM sends out Announce messages containing parameters describing the quality of its local time source. All devices thus know, for example, whether the GM is deriving its time information from a traceable external reference such as a Global Navigation Satellite System (GNSS). If the nodes receive no Announce messages for a given period of time, they assume the GM has failed and select a new GM by initiating the BMCA (Best Master Clock Algorithm). To do so, all nodes eligible to become the new GM will send Announce messages. Every node will execute the BMCA (Best Master Clock Algorithm) by comparing the values contained in the Announce message by precedence. This guarantees that all nodes reach the same conclusion. Whenever a node is attached to the network with a clock that is better than the one of the current GM, it can become the new GM. If such a device concludes that its clock is better, it will start sending Announce messages eventually forcing the current GM to back-off and all other nodes to revert to it.

Although the BMCA requires no user interaction, a PTP network has to be uniformly configured for the BMCA to work as expected. All nodes have to be configured with the same Announce message rate. Furthermore, the timeout period has to be identical on all nodes; it is designated by the number of consecutively missing Announce messages. 

In general, every node within a PTP network can become the GM. This is particularly useful for applications where a common notion of time is far more important to maintain than the link to an external time reference. If, on the other hand the network has to rely on precise absolute time, the network should be provisioned with several GMs linked to GNSS. These would be configured in a way whereby one becomes the active GM while the others are set to stand-by i.e. are Passive with respect to PTP. If the active GM fails, they all will actively participate in the BMCA and one of the remaining devices will assume the GM role. Such configurations imply that all other nodes shall not be able to assume the Master role.

PTP Accuracy Considerations

PTP assumes implicitly that the transmission delay is constant and equal in both directions. Unfortunately, this applies only for the transfer of data over the physical medium between two adjacent nodes. To consistently reach accuracies of significantly less than 1 microsecond, all factors deteriorating the time transfer must be taken into account. To this end, PTP nodes are generally equipped with hardware enhancements to eliminate any node related issues i.e. varying latencies from receiving a packet to actually drawing a time stamp. This leaves the interconnecting network as the main contributing source of variation.

Modern switched networks are not well equipped to ensure highly constant forwarding times for a specific class of messages due to the defined queuing models. They are rather optimized for maximum throughput. Consequently, the forwarding time will vary with the network load causing PDVs – packet delay variations. They can be mitigated to a considerable extent by applying enhanced filtering techniques or by prioritizing PTP messages allowing them to jump the output queue of a network device (expedited forwarding). If the network is overloaded even for a short period of time, these methods tend to fail altogether.

To remedy this situation IEEE 1588-2008 introduced two different types of PTP aware network devices: Transparent Clocks (TCs) and Boundary Clocks (BCs). Both devices process all network traffic according to the applicable forwarding rules except for PTP packets.

PTP Transparent Clocks

These devices actually measure the forwarding (residence) time: Upon receiving a PTP message the TC draws a timestamp associating it with the packet. The packet is forwarded according to the respective rules; while it is sent out via the designated egress port a second timestamp is drawn. The difference of the two timestamps, which equals the residence time is inserted in the Correction Field of the message. The time is actually added to the value stored in the correction field thereby allowing for TC cascades. The Slave is now able to account for the overall residence time of all TCs. The residual transmission time via the chain of physical channels is constant. The requirement for constant transmission delay is accurately met.

PTP Boundary Clocks

Rather than forwarding PTP messages as TCs do, Boundary Clocks are active PTP devices acting as PTP devices (Ordinary Clocks) on every port. They process PTP messages according to their respective PTP state. However, they are linked to one common local clock and interact which each other with respect to the BMCA. They share the data of all Announce messages received from their respective ports among each other and conclude jointly to which port the Best Master is connected to. This port will assume a Slave role and use the time information gathered from its Master to synchronize the common local clock. All other ports will assume a Master role and propagate the local time information to the devices attached to them. As PTP supports network topologies with cascaded BCs, these devices can be used to build a hierarchical time transfer system with multiple tiers. As PTP messages are exchanged locally between two adjacent devices, the overall PTP traffic can be greatly reduced, especially for large networks with multiple end devices.

BC vs TC?

Both devices supress of the effects of PDVs and are equally well suited for deployment in broadcasting applications. If designed with the same level of hardware support (i.e. time stamping resolution, quality of local oscillator etc.) they yield identical results with respect to overall accuracy. TCs have the undisputable advantage of being the simpler devices with respect to PTP, thus they are far easier to deploy and monitor. BCs have the advantage of reducing the overall PTP traffic considerably, because PTP messages are exchanged between adjacent devices rather than being distributed over the whole network. On the other hand, they are more complex, thus require considerably more attention during deployment and daily operation, especially if cascaded. Typically, dedicated acceptance procedures are called for to analyze the behavior of BCs under various operating and fault conditions.

PTP Profiles

To comply with varying and sometimes even mutually exclusive requirements of different application domains, PTP has been defined as a highly generic time transfer protocol rather than taking a one-size-fits-all approach. It can be customized via PTP profiles which are usually defined by the respective standard bodies. For the broadcasting industry PTP time transfer protocols for Audio (AES67) and Video (SMPTE ST2059-2) been specified, whose ranges of all relevant parameters overlap sufficiently well to build deploy a common reference for both device classes.

Conclusion

PTP is well capable of accurately synchronizing devices in Ethernet networks at the level of accuracy required for media transport over IP. In subsequent articles we will cover specific aspects of PTP related to the broadcasting industry domain ranging from reliability and redundancy considerations, operational supervision and finally PTP requirements for virtualized infrastructure.