One of the benefits of adopting IP infrastructures is that we can take advantage of the massive innovation we’ve seen in the IT industry. Finance, manufacturing and power generation need accurate time references and experts in these disciplines have been working to design and perfect timing solutions operating on asynchronous IP networks for over twenty years.

SMPTE’s ST 2110 treats timing differently as it removes the sync pulses and inserts video frames and groups of audio samples with a timestamp formed from the globally recognized PTP standard. By replacing the sync pulses we’ve not only considerably reduced the bandwidth of the overall signal but have made it much easier to process digital video and audio.

As broadcasters continue their IP migration journey, many are starting to think more about security, and it’s become a major area of interest as IP networks expand. Engineering is all about balance and compromise, and as we make our networks more accessible, then we must think more about security.

Operability and robustness are critical for any infrastructure especially when considering the stations timing reference. A system that is used by so many industries soon proves its worth as any anomalies in the specification are quickly found and addressed. But industries such as broadcasting have unique and specific operational needs and so we need the ability to fine tweak generic protocols such as PTP.

Monitoring has always been important to broadcasters due to the complexity of the systems we operate. Television would soon degenerate into chaos if we didn’t integrate monitoring to optimize signal levels and measure synchronization. IP networks, by their very nature are scalable and dynamic further adding another dimension to the system complexity. For these reasons broadcast facilities are designed with monitoring at the core of the infrastructure and this working practice doesn’t look like it’s going to change any time soon.

The IEEE 1588 working group have been listening to broadcasters, especially when considering security, operability and robustness, and monitoring. But what is even more important is the need to maintain backwards compatibility.

IP is still an emerging technology for broadcasters and there will be many changes and challenges along the way. However, it’s imperative that improvements to core systems such as timing are backwards compatible.

The IEEE 1588 working group understand this and have made backwards compatibility central to the new V2.1 PTP protocol. Equipment using the existing V2 PTP will still work with PTP clocks working to the V2.1 protocol. To benefit from the added security then any equipment complying with the V2 protocol will need to upgrade, but any V2.1 upgrades to PTP clocks or PTP aware switches will still be backwards compatible with the existing V2 equipment connected to them.

Timing continues to be central to any ST 2110 broadcast facility and its more important now than ever to understand how PTP works. We no longer have the luxury of pulling out the scope and looking at sine waves and comparing sync pulse edges. The timing signals have changed, and so have the tools to monitor them.

As ST 2110 continues to find its way into broadcast facilities, the Precision Time Protocol (PTP) is gaining greater prominence and with it our understanding of how timing should work in an asynchronous IP environment. The IEEE 1588 working group has been listening to broadcasters during this time and has now released its latest version of the protocol.

SDI and AES have been the mainstay of broadcast infrastructures throughout the world for nearly forty years. They’ve served us well and provided reliability and consistency, we know how they work, and generations of engineers have grown up with these systems. The downside of these systems is that they are static and difficult to change.

IP seeks to bring new flexibility and scalability into our broadcast infrastructures. We can ride on the back of innovation in the IT industry and learn from them. Although SMPTE’s ST 2022-6 was a great stepping-stone for many into the world of IP, the real advance happened when ST 2110 came along.

By abstracting the video, audio and metadata essence from the underlying sync, field, and frame pulse timing information, SMPTE paved the way for moving video and audio from the static SDI and AES systems to the flexible asynchronous IP broadcast infrastructures. Although this system provides us with a great number of opportunities, it also means we have to completely rethink how we do timing.

Fundamentally, television is still a synchronous system based on repetitive evenly gapped video frames and time invariant audio samples. This is a legacy that is yet to be surpassed and is unlikely to change in the near future. Consequently, we need a stable time reference so that the playback speed of the video frames coincides with the record frames of the camera, and the playback samples of the loudspeaker coincide with the record samples of the microphone. In this context, nothing has changed.

PTP has its roots in industry and has proven its ability to deliver a stable time reference to synchronize events. As we progress through our IP integration, instead of thinking of video frames and audio samples in the frequency domain, it might help to consider them as related timed events. This is more intuitive when considering distribution over IP networks as IP is essentially an asynchronous system that facilitates transactional events.

The fundamental reason for using PTP is that devices in a network can share the same time source so that record and playback events can be synchronized. The PTP timestamp is a register that counts the number of nanoseconds from the epoch to the present time, consequently, it provides us with much more than a simple frequency reference.

ST 2110 uses PTP V2, or its formal standard; IEEE 1588-2008. This is version two of the protocol and superseded its predecessor, version one. The latest release, IEEE 1588-2019 is version 2.1. Not only is this backwards compatible with V2 and can be used with ST 2110, but it also provides improved robustness, accuracy and security.

Although V2.1 provides much more functionality than V2.0, the backwards compatibility cannot be over emphasized. Due to the complexity of broadcast systems and the amount of money riding on infrastructures in the way of content, broadcasters like to take small progressive steps. Devices such as cameras, production switchers, sound consoles, etc. using PTP V2, must still work without any anomalies when the network is upgraded to V2.1. The IEEE 1588 working group has achieved this.

Security
Every broadcaster should be concerned with security. For some time, there was a school of thought that suggested security was not really of any concern as broadcaster’s networks were protected. This naïve approach is mostly now debunked, especially if we think about the security challenges within any organization and recent well recorded breaches.

Although the IT industry has progressed well with initiatives such as IPsec to address security in networks, their work with network clocks, specifically NTP (network time protocol) and PTP has taken this to new levels. The IEEE 1588 working group has based many of its security motivations on this work to provide well thought out solutions which address and remedy many of the security challenges.

Time protocol attacks can take on many guises, but the most common underlying themes include packet interception, spoofing and data manipulation. It might seem strange that a malicious actor may want to gain access to the timing function but in doing so, and without the correct safeguards, they can cause timing anomalies that are difficult to detect and can cause havoc in a broadcast facility.

The data within the IP packets of V2.0 are sent in the clear. That is, there is no consideration for encrypting or protecting the data within the packet. To maintain backwards compatibility between V2.1 and V2 it is not possible to add encryption to the whole data packet for V2.1. This is because existing V2 compliant equipment would not be able to decode the timestamps. To address this, V2.1 uses the concept of cryptographic Integrity Check Values (ICV).

If a malicious actor was to access the timing system, then they might want to adjust data such as the timestamp values from the Grand Master in such a way that the internal clock of any downstream equipment, such as a multiviewer, would speed up with respect to the Grand Master. This change might be very subtle, not enough to cause the multiviewer to indicate it has lost sync, but enough for the video and audio to be out of sync with the originator. Resulting problems would be really difficult to detect as there would be no data loss, and the multiviewer would still be showing that it’s synchronized. However, as it’s synchronized to the maliciously modified values, it might start running faster and would run out of video and audio in its input buffers, thus causing video and audio breakup.

This sort of problem can also happen quite innocently and unintentionally if downstream equipment from the GM was incorrectly configured or a user made a mistake.

ICV will help alleviate this kind of issue. In the ideal world we would encrypt the whole PTP message, but this is not viable as we need to maintain backwards compatibility with the existing ubiquitous V2 PTP protocol. Therefore, instead of encrypting the entire data segment of the message, V2.1 provides a mechanism to provide a form of cyclic redundancy check, or complex parity check on selected parts of the datagram so that we would know if an error occurred or somebody has modified the timestamps. To further improve this, the validation word is encrypted using a secret key. The process of calculating the validity word and encrypting it is the ICV.

This mechanism protects not just against altered PTP messages, but also false messages injected into the network by a malicious agent, since the false messages would not contain an AUTHENTICATION TLV with an ICV created with the correct secret key.

A V2.1 enabled Grand Master would create the ICV and append it through the use of the Type-Length-Value (TLV) to the timestamp message. TLVs are an established method of extending the PTP protocol functionality while maintaining backwards compatibility. Any downstream equipment such as a camera or sound console, would expect to see the TLV-ICV.

When the timestamp packet is received, V2.1 compliant equipment such as sound consoles and vision switchers are able to decrypt the ICV (as they will have a copy of the secret-key) and then compare the validity word to its calculated version of the PTP message. If they are the same, then the timestamp and all the associated data is assumed to be valid and is used. If they are different, then either an error has occurred, or the message has been tampered with in transit causing it to be dropped and an alarm issued.

Addition of the ICV allows any V2.1 compatible downstream equipment to determine if the PTP message is valid and whether it has been maliciously modified or not. Any trusted intermediate equipment such as a PTP aware switch that modifies the data values, for example a transparent clock, will need to know the secret-key so it can decode the incoming message, modify the relevant data parameters, recalculate the ICV using the secret-key, and then re-insert the new TLV-ICV into the PTP message.