Legacy Is Secured With PTPV2.1
Any legacy V2 downstream equipment will still receive the same PTP message with the authentication TLV (indicating an ICV is present), but as it will not recognize the TLV type identifier, then it will simply ignore the TLV and ICV value. This means the V2 equipment will not be able to determine whether the PTP message has been maliciously interfered with or not, but it can still use the PTP timestamp information and all the other associated data to synchronize to the Grand Master, thus maintaining backwards compatibility.

Crucial to this system is maintaining the confidentiality of the secret-key. Although the IEEE 1588 working group does not mandate any particular key management system, the V2.1 specification does provide examples of systems such as Key Distribution Centers and the Group Domain of Interpretation (GDOI) method of maintaining and distributing keys to authorized devices.

As the secret-key is so important to maintaining the integrity of V2.1 PTP messages, the actual key may change daily, or even hourly. This security policy and the maintenance of the keys is outside the scope of the V2.1 protocol but is a system that should be operated in conjunction with the broadcast facility’s IT Director.

Robustness
As well as providing better security, the IEEE 1588 working group also wanted to improve PTPs operability and robustness and they achieved this through profile isolation and monitoring.

To maintain maximum flexibility across many industries, PTP uses a system of profiles to quantify many of the parameters that can be configured in the system. For example, although IEEE 1588 specifies the use of the Announce message, it only specifies a generic time interval with which it is sent using the default-profile. This is a base profile common to all PTP devices so they can be tested and measured to the same specification. It’s possible to use the default profile but industries such as broadcasting have their own standard; SMPTE’s ST 2059-2.

Other industries also have their own profiles such as the IEEE 802.1AS for synchronizing audio and video on bridged networks based on IEEE 802.1. If both these profiles are running on the same network, which is entirely possible, then any receiving device could be confused by the two profiles, especially when resolving master clock status in the Best Master Clock algorithm.

The new profile isolation from V2.1 provides a unique identifier in the PTP header that allows downstream PTP nodes to only process messages with the identifier it recognizes and ignore the other messages. The idea is that a Standards Development Organization (SDO), such as SMPTE, IEC or ITU can request a unique identifier, the SdoID, and use this in the PTP message header.

Backwards compatibility is maintained as the sections of the header that the SdoID uses are either reserved in V2 or a forward extension of the information already in there. SDOs can apply for one of the unique SdoIDs, however, these identifiers are only issued to SDOs and not individual manufacturers or broadcasters. The key advantage is that every SDO can still make use of the full range of domain numbers and other parameters without interfering with other profiles from different SDOs in the same network.

V2.1 also facilitates the use of multiple masters that all send their timing messages to slaves simultaneously. V2 only provided a single master and if it sent out the wrong time message, then all slaves would try and sync accordingly. With the multiple master approach, the slaves can choose a group of masters and dismiss any master that they consider has sent the incorrect time.

Monitoring
Another major addition to V2.1 is that of standardized time accuracy monitoring. Although it was possible to gather the necessary timing data to determine the health of the network time, V2 didn’t standardize this. Consequently, any vendor building a monitoring tool had to write specific interfaces for every manufacturers PTP processing equipment.

Time analysis is critical to any network and being able to measure and log the timing data from each PTP enabled device in the network is an absolute necessity. V2.1 provides four new timing statistics integrated over 15 minutes and 24 hours. The basic timing measurements are the average, minimum, maximum and standard deviation.

PTP nodes which contain slave ports such as ordinary (in the slave state) and boundary clocks provide information about their offset from the master. Digging deeper into the network is now achievable to help determine the accuracy of the time within the network.

The data storage format for the timing data is also specified to interleave the 15 minute and 24-hour measurements. This provides a consistent data format making analysis and hence diagnosis, much simpler.

SMPTE’s ST 2110 has freed us from the shackles of analogue television. Due to the time invariant sampling nature of video and audio, we still rely heavily on an accurate and reliable time source. PTP V2 provided this for us. But PTP V2.1 has not only improved on V2 to provide security, robustness and improved accuracy, but has made all these new features backwards compatible.

We can easily migrate to the new version to take advantage of the new features and be assured that backwards compatibility to existing PTP V2 equipment will be maintained.