BMCA Archives – The Broadcast Knowledge

Part II in this Cisco series on PTP, Precision Time Protocol, focuses on Boundary Clocks and Transparent Clocks. Last week we heard how PTP maintains accurate time by calculating the delay between clocks and the grandmaster clock which is the source of time for the network. This video summarises how to distribute that source of time to all your devices and how to choose between the two methods.

Albert Mitchell from Cisco explains that transparent clocks are just that, they transparently let the timing data flow through. All they do is update the timestamps on the outgoing packets to compensate for the extra time getting through the switch. A boundary clock (BC), however, is a source of time of itself but gets its time from the grandmaster like any other clock. Acting in this dual way, it creates the boundary it’s named after. It’s a boundary because it provides time to other end devices on the network, These devices never see the grandmaster, they only see the BC. Likewise, the grandmaster only sees the BC acting like any ordinary clock sending delay requests. This means that the boundary clock can shield the grandmaster from the rest of the devices on the network. A grandmaster with 10 boundary clocks can deliver time to over a thousand endpoints without a problem. Without the boundary clocks, the grandmaster may not be able to handle the two-way conversations necessary with so many clocks.

For broadcast networks, boundary clocks are preferred as they enable easier diagnosis and can reduce the blast radius of problems. Importantly they can span multiple VLANs. Other benefits are that they filter packet delay variation and shields the downstream/following clocks from any transient changes in the grandmasters. The downside of BCs is that they do add small errors to the timing which can add up if multiple BCs are concatenated.

Transparent clocks, on the other hand, don’t help with scalability like BCs and are limited to single VLANs. On the plus side, they require no configuration and provide faster convergence.

Lastly, Albert looks at the Best Master Clock Algorithm (BMCA) which is the method used to determine which grandmaster is providing timing to the whole network. For a deeper dive into the BMCA, have a look at this Arista video on PTP timing. Albert gives a good starting overview of how the algorithm works, the data it needs to operate and advice on settings to make sure you know which clock will win in each instance.

Watch now!
Speakers

Albert Mitichell
Technical Marketing Engineer,
Cisco

When it comes to IP, audio has always been ahead of video. Whilst audio often makes up for it in scale, its relatively low bandwidth requirements meant computing was up to the task of audio-over-IP long before uncompressed video-over-IP. Despite the early lead, audio-over-IP isn’t necessarily trivial. However, this talk aims to give you a heads up to the main hurdles so you can address them right from the beginning.

Matt Ward, Head of Video for UK-based Jigsaw24, starts this talk revising the reasons to go audio over IP (AoIP). The benefits vary for each company. For some, reducing cabling is a benefit, many are hoping it will be cheaper, for others achievable scale is key. Matt’s quick to point out the drawbacks we should be cautious of, not least of which are complexity and skill gaps.

Matt fast-tracks us to better installations by hitting a list of easy wins some of which are basic, but a disproportionately important as the project continues i.e. naming paths and devices and having IP addresses in logical groups. Others are more nuanced like ensuring cable performance. For CAT6 cabling, it’s easy to get companies to test each of your cables to ensure the cable and all terminations are still working at peak performance.

Planning your timing system is highlighted as next on the road to success with smaller facilities more susceptible to problems if they only have one clock. But any facility has to be carefully considered and Matt points out that the Best Master Clock Algorithm (BMCA).

Network considerations are the final stop on the tour, underlining that audio doesn’t have to run in its own network as long as QoS is used to maintain performance. Matt details his reasons to keep Spanning Tree Protocol off, unless you explicitly know that you need it on. The talk finishes by discussing multicast distribution and IGMP snooping.

Watch now!
Speaker