Large AV over IP deployments using IEEE 1588, Precision Timing Protocol, often necessitates the use of Boundary Clocks.

Early-stage Audio-over-IP or AV-over-IP deployments are usually architected with a simple Transparent clocking framework.  Ethernet Switches are selected that support IEEE 1588 and Transparent Clock.    Transparent clocks are easy to use.   They simply allow PTP packets to flow through a device.

Ethernet Switches for ProAV and Media Broadcast over IP markets should be selected based on full adherence to the IEEE 1588 standard, including support for multiple Boundary clocking modes.  Boundary clocks act as a client to an upstream PTP timing server and as a timing server for downstream clients/devices.  Boundary clocks are needed to take loads off the upstream timing server, preventing constant timing requests from various clients from causing an overload condition.

Once the right Ethernet Switches are deployed, there are other things to consider, and it is important to ensure the network elements can support these considerations.

Set Consistent PTP Profiles and BMCA Settings

All devices that could potentially become the PTP timing server must execute a common Best Master Clock Algorithm (defined in IEEE 1588) to identify the best choice. Once a particular clock is selected, all other potential clocks receive timing from it. If something happens on the network that bumps that preferred or best clock, and it’s no longer available, then the next best clock on the network automatically becomes the reference.

Every clock on the network, whether a boundary clock or end device (client), has a user-provisioned priority field that defines their place in the hierarchy. The lower the number, the higher the priority, with high priority indicating that a particular clock is the best one to use and low priority essentially saying, “Don’t use this clock.” If two or more clocks share the same high priority value, then other criteria related to clock quality are compared to determine which clock should be selected as the PTP reference.

To keep this model running smoothly, it’s important to set consistent PTP profiles while provisioning variables for each element participating in the PTP network. Because different industries have different PTP profiles for the different variables, you want to make sure that all the elements have the same profile — that they are all speaking the same language — and that the same (and correct) selection criteria are applied across all clocks so that every endpoint (client) will shift to the appropriate common source for PTP clock signals in the event of an interruption.

Leverage Your PTP Hierarchy Correctly

While both boundary and transparent clocks deliver the signal from the timing server to various clients, or end devices, the two generally serve different purposes.  Transparent clocks are easy to use. They simply allow PTP packets to flow through a device, adding a correction factor to each packet to account for the time it took the packet to flow through the device. With this information, the destination device can calculate the network delay and determine an accurate PTP time.  For larger, more complex networks, a mix of transparent and boundary clocks helps to manage the larger PTP message load effectively. (More endpoints = more PTP messages.)

A boundary clock can act as a client device to an upstream PTP timing server and as a timing server for downstream clients/devices, it can be used to take some of the load off of that upstream timing server.  The output of the upstream timing server thus can be shared with multiple downstream devices, preventing constant timing requests from various clients from causing an overload.

You can use boundary clocks to partition traffic — to create boundaries that keep the flows of PTP messages manageable and prevent an error on one endpoint from propagating and causing havoc across the network. It’s an extreme case, but not impossible, and could result from a simple mistake that causes an overload on the timing server, or a more malicious denial of service attack. In either case, you can use boundary clocks to contain this kind of threat and add a layer of security to the network.

Correlate Clock Accuracy to the Applications

When everything is going well, you can trace timing through the PTP timing server, which presumably has a very good clock, all the way to the ultimate reference, an atomic clock. But sometimes things go wrong, and there is a break in the timing chain. At this point, your switch goes into holdover, capturing the latest and most accurate timing data and maintaining it as long as possible.

To prepare for this moment, you need to know what your endpoints can handle in terms of drift, which inevitably will occur when clocks are no longer traceable through a GPS or similar time source. Depending on the quality of crystal used in your clock, the rate of drift will be slower or faster. High-quality crystal is costly, and so vendors must make a choice about cost of performance and correlation to a particular application. You too must make a choice about the level of performance — and clock accuracy — required for your application and the endpoints across your network.

Other Timing Reference Options

PTP messages are just one source of timing information. While they are less common, there are other ways to communicate this data. Physical connections, for example, can carry timing in a different form, such as a waveform. Depending on the industry and application, you may find that you’re working with endpoints or other devices that don’t support PTP. In this case, you want to be sure that you have the means to synchronize with other timing reference modes.

Full Support for IEEE 1588

It’s always good to know that your systems support all the variables specified in key industry standards and specifications, and in the broadcast realm, IEEE 1588 is one of those specifications. You’ll likely need to be connecting end points that come from different vendors, each with their own interpretation of PTP and how to work with it. Full support for IEEE 1588 will ensure that you have the flexibility to accommodate deviations that might still be within the specification. With robust support for PTP, you can be confident that every aspect of PTP-based synchronization translates well across your network and devices.