Take a look at the Documentation page on the Artel website, and you’ll find dozens of PDF files describing our products and explaining how best to configure them for your operations. One of the most popular downloads is our Quarra Configuration Guide for AES67, which walks through critical areas of PTP Ethernet switch configuration.
Page through the guide, and you’ll learn exactly what to do to get your Quarra system up and running. We make it simple and provide helpful screenshots so that you can get through setup quickly and successfully without necessarily understanding every switch feature. Once you get the switch configured that first time, you’re pretty much good to go.
But maybe you’re interested in the “why” as well as the “how”? Read on for a closer look at three key features — IGMP snooping, QoS, and IEEE 1588 PTP — and why they are important in supporting a stable AES67 network.
IGMP stands for Internet Group Management Protocol, and IGMP snooping is the process of metering network traffic to control delivery of IP multicasts so that traffic is being delivered only where it is requested. Naturally, this is especially important for bandwidth-intensive applications.
Most off-the-shelf switches feature IGMP snooping because it plays a critical role in regulating traffic and preventing the flooding of all ports on a switch. The scenario is problematic because it can cause a complete bottleneck, with nothing at all getting through the switch.
The snooping table shown here illustrates how multicast groups can be associated with specific “memberships” to ensure that data packets are forwarded only to the appropriate destinations rather than to all hosts.
When you register a request for a multicast and leave one feed for another — like dropping one audio channel and picking up another — it can take a while to actually leave that first feed. As a result, there typically will be a short period of time during which you have both feeds coming in.
You can establish VLANs to partition and prioritize IGMP traffic. VLANs are a tool that allows to prioritize different types of traffic, create primary and secondary networks, and distribute PTP and network management messages. By creating logical groupings of related messages and flows, you can categorize and more effectively protect traffic, and especially mission-critical flows, across the switch.
Quality of Service (QoS)
Like IGMP snooping, QoS is a standard feature on most IP switches, and for good reason. When you set up QoS, you’re essentially equipping the switch to direct traffic, putting higher-priority (time-sensitive) packets at the front of the line.
The media industry uses differentiated services (DiffServ, or DS) fields to classify and manage different types of network traffic, and this model allows for eight priority levels, or classes, ranging from Class 0 to Class 7. When configuring your switch, you’ll apply a different QoS class to audio or video essence where low latency really matters than you would to a non-critical file transfer or similar request where a best-effort service (and perhaps a 5- or 10-second delay) is acceptable. Class 7, the highest priority, is generally reserved for PTP only.
Default tags are already established in AES67 for Precision Time Protocol (PTP) data and audio, and Quarra can translate between different implementations, such as AES67 and Dante. Nevertheless, it is wise to confirm that you’ve used the correct tags in assigning classes to different flows. As with many settings for IP traffic management, the right setup can enable very effective management of traffic even in complex environments. Errors in configuration can cause huge headaches, immediately or down the road.
Quarra settings for QoS also give you the option of specifying bandwidth limits for different types of traffic. This is a convenient way to make sure that unexpected traffic — someone streaming HD video on the management network, for example — doesn’t wind up compromising critical time-sensitive flows.
IEEE 1588 Precision Time Protocol (PTP)
Quarra switches stand above the competition for many reasons, of course, but a key differentiator is that the Artel switch is PTP-aware.
PTP specifies a methodology for synchronizing devices, including timing servers and clients, to one shared clock across packet-based networks. The protocol is fundamental to IP video/audio signal transport using SMPTE ST 2110 and AES67 because it creates a common timebase that facilitates synchronization of video and audio devices to a uniform clock (time code).
When switches are not PTP-aware, the transit time for PTP messages can vary. Each time a PTP sync or delay request message is delayed, it can contribute to an offset that ultimately can disrupt the stability of the PTP distribution system and cause packet drops (and audible pips) in the audio. A PTP-aware switch like Quarra offers a safety net by guaranteeing timing and ensuring that PTP is stable even as you approach capacity.
The Quarra switch enables vital segmentation of PTP messages by allowing users to opt for boundary clock mode, transparent clock mode, or a mix of the two in the same network. Both boundary and transparent clocks deliver the signal from the timing server to various clients, or end devices.
A transparent clock adds to each PTP packet a correction factor representing the time it took the packet to flow through the device. The destination device can use this value to calculate the network delay between the device input and the timing server output and thereby determine an accurate PTP time.
A boundary clock acts as a client device to an upstream timing server, and also as a timing server for downstream clients/devices. This model allows the output of the upstream timing server to be shared with multiple downstream devices without overloading the timing server, and timing is nearly as accurate as with a transparent clock.
In the Quarra Configuration Guide, you’ll see that the default setting is a transparent clock. This is more of a plug-and-play option, as it requires relatively little knowledge of PTP. It’s a straightforward solution for smaller networks, and the same basic settings will work just fine across 99% of networks. In the end, whether you go with transparent or boundary clocks, you’ll know that you’re taking a critical step in ensuring signal integrity.
The move from SDI toward IP brings with it a great deal more power and flexibility, and countless new opportunities for error. Due to interaction and interdependence among devices across the network, issues in IP-based media and data transport tend are rarely black and white problems. They might be time- or event-based. Everything might work just fine one day and fail the next.
The good news is that if you follow our basic configuration guidelines for Quarra, you should be in good shape. And if you’ve read this far, you understand why!
If ever you have further questions about IP, PTP, and other elements of IP-based media workflows, just get in touch! Or take a look at our blog, where we regularly post on topics related to modern media transport.