The Precision Time Protocol (PTP) is a timing standard used to synchronize clocks throughout a computer network. On a local area network, it achieves clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. Versions of PTP are in use throughout many industries. In media, it is essential to keep video and audio IP equipment, such as cameras, vision switchers and graphics kit in synchronicity.

A typical infrastructure will have at least one (usually more) PTP clock generator called the Grandmaster clock. Various slave clocks synchronise to it and can acquire ‘Grandmaster’ status if the Grandmaster fails thus providing a main-backup solution.

The first version of PTP, IEEE 1588-2002, was published in 2002. IEEE 1588-2008, also known as PTPv2 is not backward compatible with the original 2002 version. IEEE 1588-2019 (PTPv2.1) was approved in November 2019 and was published on June 16^th 2020. This version includes backward-compatibility to the 2008 publication.

Indeed, the designation PTPv2.1 rather than v3 is chosen to emphasise that maximum backwards compatibility is assured.

“PTPv2 has worked very well until now but the new features can enhance the robustness and accuracy of PTP,” explains Daniel Boldt, Head of Software Development, Meinberg, which makes timing equipment such as clocks for IP infrastructure. “Importantly, the new features in v2.1 are optional and entirely interoperable with v2.0.

“This was not the case with version 2.0 which was not backward compatible with the existing 1.0 standard. It meant that a v1.0 device couldn’t talk to a V2.0 device and vice versa. This is addressed in this version and means that a 2.1 master can synchronize with every 2.0 slave and vice versa.”

Among the new features introduced in the new version is the ability to use isolated profiles. If two or more PTP Profiles, which use multicast messages, are in the same network, then the PTP nodes will see PTP messages from profiles which are not of interest. That could wreak havoc with the Best Master Clock Algorithm, for example. The current way to solve this is to configure each profile to operate in a different PTP domain.

“That works if the network operator has time to pay attention to the PTP domains of profile running on their network,” explains Douglas Arnold, Meinberg’s Principle Technologist and also chair of the PNCS - Precise Networked Clock Synchronization Working Group – which led the specification design. “If you are a network operator, then you are so busy that you barely have five minutes, so you know that it is dangerous for equipment vendors to assume that you will track PTP profile domain numbers.”

If you want to be sure that profiles of PTPv2.1 do not interact you can use the new profile isolation feature.

The idea is this: A Standards Development Organization, or SDO such as SMPTE the IEC or ITU, can apply for a globally unique number, the SdoID, which appears in the common header of all PTP messages. PTP nodes can then ignore all messages which do not have the SdoID they want. You get these numbers from the IEEE Registration Authority. These are the folks which are in charge of parcelling out certain globally unique numbers such as Ethernet MAC addresses. The idea is that each SDO can get a SdoID, then protect its own various profiles from each other using rules on domains. Before you rush to the Registration Authority to get your number be advised that they will only give you one if they judge that you represent a standards development organization. So organizations (like the IETF, ITU, SMPTE) would be able to get one, but not equipment manufacturers, or network operators.

Also new in PTPv2.1 is the ability to use multiple masters at the same time in order to send messages to slaves simultaneously.

“This feature has been built into profiles of PTP for use in other industries, such as the enterprise profile for the financial industry, but is new to the media world,” Boldt says. “One of the drawbacks of the old PTP version was that there was only one master present and everybody had to follow this one single master. If that sent out a wrong time every slave would follow that master.

With a multiple PTP approach, the slave can now choose a group of masters with the accurate time so they can kick out a false master automatically.”

Other features are focussed on monitoring and collecting of metrics from the slave. With network conditions constantly changing, operators need precise and relevant information. “These metrics provide statistical information about a certain PTP node such as the average offset in the last 24 hours; the number of packets exchanged; the minimum or maximum delay measured in the last 24 hours.”

Again, none of these have to be added, they are user optional.

Perhaps the most important new feature pertains to security. This has been introduced around TLV which stands for “type, length, value.” It is a general means to extend a PTP message with some extra information for some optional features – in this case enhanced security.

“In PTPv2.1 this security appendage can be attached to any PTP message and allows for the authentication of a master,” Boldt says. “It ensures that only trusted masters can be active and the communication path between slave and master is secure.”

The idea of the AUTHENTICATON TLV (it is customary to name this in caps in the TLV) is that a cryptographic integrity check value (ICV), sometimes called a hash code, can be appended to a PTP message, explains Arnold, “if anything in the message changes, then the receiving node can detect that by recomputing the ICV and comparing it to the one in the TLV. This involves performing mathematical operations on the bits in the message, except the ICV, and the secret key, resulting in the ICV. The trick is that it is practically impossible to get the right answer unless you know the key, so a man in the middle attack will be detected.”

It will take a little time for these features to be added into product, from Meinberg or other reference clock manufacturers, and integration will be done on a step by step basis depending on customer demand.

For further information and a detailed account of the changes in IEEE 1588-2019, please refer to Meinberg’s blog written by Douglas Arnold.