PTP V2.1 – New Security & Monitoring For IP Broadcast Infrastructures - Part 2

In the last article in this series, we looked at how PTP V2.1 has improved security. In this part, we investigate how robustness and monitoring is further improved to provide resilient and accurate network timing.

This article was first published as part of Essential Guide: PTP V2.1 – New Security & Monitoring For IP Broadcast Infrastructures - download the complete Essential Guide HERE.

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.

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.

The default profile provides a basic configuration to specify the frequency of messages such as the announce interval. Sector specific SDOs fine tweak these values to provide their own profile specifications such as SMPTE’s ST 2059-2.

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.

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.

Supported by

Broadcast Bridge Survey

You might also like...

TAG Introduces Realtime Media Platform

TAG Video Systems takes advantage of over 70,000 globally deployed probing points to give users the ability to dive deep into streaming content monitoring. The company anticipates more than 100,000 probing point deployments by the end of 2021.

The World Of OTT (Infrastructure Pt9) - Minimizing OTT Churn Rates Through Viewer Engagement

The basic goal is for consumers of video services to be highly engaged. It is easy to say but hard to do. Yet it is at the core of being a D2C streamer. D2C requires a deep understanding…

The Case For Adopting Both Client And Server Side Ad Insertion

The video streaming tide has been accelerated by the Covid-19 pandemic, but will continue to flow as relative normality returns, driving demand to monetize online content not just through subscriptions but also advertising.

Software IP Enabling Storytelling - Part 2

In the previous article in this two-part series we looked at how cloud systems are empowering storytellers to convey their message and communicate with viewers. In this article we investigate further the advantages for production and creative teams.

Integrating NDI And ST 2110 For Internet Streaming

The focus of much of the latest broadcast TV R&D is the Remote Integration Model (REMI). From millions of Skype meetings over consumer ISPs to the recent Winter Olympics TV broadcasts, REMI is significantly changing the internal dynamics…