Artel's lessons learned part 1: Getting IP Right With a PTP-Aware Switch

At a meeting of Artel engineers, they decided to collect some “lessons learned” stories. We figured we’d share these stories — focused around IP-based media workflows — in case they can help you to prevent unwanted downtime or avoid a painful failure.

The first of these lessons learned? Go with a PTP-aware managed switch. Realistically, this choice can solve or prevent a lot of problems for you, but in this first blog post, we’ll start by talking about what PTP-aware means and why it’s so important.

As you know already, Precision Time Protocol (PTP) plays a central role in standards-based IP media transport, typically AES67 audio and SMPTE ST2110 video. PTP data is critical because it provides the timing information needed to synchronize devices to a shared clock across IP (packet-based) networks, including Ethernet switches and IP routers. When switches are not PTP-aware, they don’t participate in the delay corrections called by the protocol, in turn compromising the accuracy of the downstream clocks.

If you work with a small and simple network with few endpoints, you may be able to get by without a PTP-aware managed switch. But as your network gets more complicated and the number of end points increase — as it inevitably will — you will benefit tremendously from the added traffic control/management and PTP functionality that comes with your PTP-aware switch.

In handling PTP messages, a PTP-aware switch should give you the option of using transparent and boundary clocks. Both are used to distribute PTP messages properly to multiple devices, and you’ll often find both at work across different layers of the PTP clock hierarchy when it’s necessary to keep a large number of devices synchronized. Beyond correcting for the transit time of PTP messages across the switch, transparent clocks more or less act as though they are invisible. Boundary clocks, on the other hand, may be synchronized to a PTP timing server on one port and serve as a timing server on all the other ports supporting a large groups of client devices, effectively taking some of the load off of that timing server.

A managed switch will support useful functions such as VLANs that logically separate and prioritize various traffic flows, thereby protecting mission-critical media and data flows. You can even set up multiple boundaries by port, such as when you have two VLANs and two boundary clocks talking to the same timing server. Similarly, support of robust IGMP functionality allows the switch to receive multicast group memberships identifying the traffic that should be forwarded from a specific group to the client.

With quality of service (QoS) functionality, a switch can be configured to direct traffic (packets) with time-sensitive packets taking priority and, if specified, bandwidth constraints preventing unexpected traffic from interfering with the delivery of those packets.

One further thing to consider in choosing a switch is that you can use a common API (e.g., JSON) for control and provisioning. Because the functionality you’ll want and need is already baked into the switch, you’ll find that system presets and configurations go a long way in helping you to optimize audio, video, and data over IP even as your network grows in size and complexity.

If you’re moving toward IP-based media workflows, you really can’t afford not to consider a PTP-aware managed switch. Don’t learn the hard way. Take our word for it! We’re always happy to provide a demo or to chat with you about your switch requirements and options.

• Share: