|Cisco’s 3850 multi-gigabit switch|
The core element in question here is, of course, the network switch. Networked professional AV systems, particularly those used in real-time production or performance applications, place extraordinary demands on a network’s switching capacity and capabilities. It’s an unforgiving environment that many typical network switches—or switch configurations—cannot handle reliably.
Let’s look at consumer streaming media as a contrasting example. If you click on a YouTube link, you access a compressed media file that arrives with no pre-determined latency and no requirement to synchronize with any other data streams. It doesn’t matter how long ago the data left YouTube’s server. And, if you want to share it with a friend, you don’t need to watch it in exact synchronization. Should it pause to buffer for a few seconds, it’s not the end of the world. So, in this case, any demands on intermediate switches are minimal.
|Extreme X460-certified switches|
Today, many large corporate AV installations are evaluating the move toward converged networks, with all IT and AV applications sharing a common network infrastructure. This places the selection of switches at the forefront of the conversation, and that in turn brings us to the oft-repeated question: “Do I need special switches for professional AV networking?”
This question usually is asked in reference to an AVB-enabled switch designed to accommodate the suite of open-source standards for time-sensitive networking established by an ongoing IEEE work group. We’ll deal specifically with that part in a bit. But first, the simple answer:
Yes, you DO need “special” switches. However, “special” can be defined in several ways.
SWITCHES FOR AV: DEBUNKING THE MYTH
There’s a myth circulating in the industry that AV networks based on the open-source AVB protocols require special switches whereas the proprietary audio networking protocols do not. This is misleading, because it implies that you can use any ordinary, off-the-shelf switch for the proprietary audio networks with easy, plug-and-play compatibility.
Such is far from the truth. The companies that either make or license the proprietary protocols go to great pains to publish lists of acceptable and unacceptable switches for use on their networks. And one point of common agreement—whether employing AVB or proprietary protocols—is that you do need carefully selected switches that are able to handle the size and scope of the job with consideration for the evolving network.
In the simplest terms, a managed switch is an intelligent device that allows user configuration and network diagnostics. These features are essential for any high-level AV network, but they are particularly critical for the proprietary audio networks as custom configuration of the switch is almost always required. This usually involves disabling the Energy Efficient Ethernet (EEE) which can interfere with clocking, and configuring various packet control requirements such as VLANs, QoS and IGMP snooping. If all these configurations are done properly, and the switch has ample capacity to handle the highest data throughput demands, then all should go well. However, there can be no ironclad guarantees.
|A Cisco demonstration at InfoComm 2016|
To handle AVB data streams, switches must incorporate hardware and software capabilities for recognizing and forwarding data tagged with a header containing timing and synchronization information.
A good analogy for understanding how this works is to visualize commuting on a freeway, in rush hour, across a toll bridge and through a half-dozen interchanges. If you have two or more people in your vehicle, you can move along faster in the HOV lane. And when you hit the toll plaza, if you have a FastTrak transponder you can zip through the designated toll collection lanes without stopping.
AVB is like a combination of the two, only better. The AVB header serves as your FastTrak unit. It admits you to the lanes that are reserved exclusively for time-sensitive, deterministic data. Only AVB data can use the lanes, and the number of reserved lanes is adjustable up to the full bandwidth of the switch. In the car analogy, you move at a steady 70 mph through every interchange, and you arrive at your destination precisely on time, every time. As the needed bandwidth is fully reserved, there can be no unexpected collisions with other data “vehicles”.
If you apply the same analogy with non-AVB switches, you would find no capacity for reserving special lanes for AV or other time-sensitive, deterministic data. Instead, the QoS and VLAN features are used to give priority to the AV data, and this works well with audio – which has low bandwidth demands compared to uncompressed video—as long as the switch has adequate bandwidth reserves. The analogy here might be traffic patrolmen who usher non-prioritized data out of the fast lanes when demand is high. But you do have to configure your switch properly to make sure the patrol cars are deployed and doing their job. Still, as the bandwidth is not fully reserved, there are no guarantees and breaks down at high utilization, the digital equivalent of rush hour.
With AVB, it’s a simple proposition. Once AVB is enabled, the fast-track lanes are reserved. You simply decide how many lanes you need based on anticipated traffic. With some switches, such as those from Extreme Networks, it’s a simple two-step process: enable AVB and designate the ports you want to use. Good to go.
In addition to getting the data there “on time,” any devices rendering media require a precise common time for rendering samples accurately and in sync with all devices. In order to keep this common time, the devices use methods (described in IEEE 1588) to exchange time information multiple times per second. AVnu certified switches ensure these messages get through in a smart way, working with features like EEE, not against them. In addition, a certified switch participates in the process by keeping a time relay for devices connected to it, allowing end devices to achieve and maintain precise synchronization quickly and reliably.
CLEAR COMMUNICATION: CERTIFIED
AVnu Alliance, a trade association formed to assure compliance and interoperability of AVB/TSN network components, does have a procedure for certification of switches. It’s a relatively simple process compared to testing interoperability of end points, because the switch need only be tested to make sure the data packets are being forwarded in order and precisely on time. The contents of the packets are irrelevant to the switch, though certainly not to the endpoints. An analogy here would be a telephone conversation. With the endpoints, AVnu certification needs to assure all components are speaking the same language. With the switches, however, certification is instead focused on the continuity and audio quality of the telephone connection to guarantee any conversation can be clearly understood, regardless of the language spoken. This makes switch selection much simpler than maintaining complex lists of features, and compatible and incompatible switches for each manufacturer. Bottom line: certification of switches (and end devices) means that integrators and designers can choose products from multiple manufacturers using the same common foundation technology and they will all work in a system on the same network.
And as the network evolves, so too will certification of the infrastructure. To promise interoperability, backwards and forwards compatibility must be commonplace. This will ensure that system designers don’t end up specifying a network that was outdated before it was even installed, and that the integrator won’t install devices that couldn’t communicate or be managed, or implement a network that couldn’t scale or be properly supported. This scenario too often results in the end user losing their original investment, requiring an unforeseen “Phase II” of the project.
LOOKING FORWARD WITH BACKWARDS COMPATIBILITY
As noted earlier, when specifying any serious AV or converged network infrastructure, managed switches are a given. The question then becomes whether or not AVB or TSN (for Time-Sensitive Networking) switches should be specified for the project.
If the project absolutely, positively will not involve large amounts of time-sensitive deterministic data of any kind for the foreseeable future, and the system will definitely never be expanded, then “special” AVB switches or managed enterprise-grade switches may not be needed. A solid infrastructure of managed switches with sufficient speed and data throughput can do the job.
But if you’re not sure, it’s better to play it safe and specify switches that are AVB (TSN) capable. If your immediate needs call for proprietary audio networks that don’t require AVB capability, it’s not a problem because the AVB-capable managed switches will have all the enabling and disabling features needed to configure for the proprietary networks.
AV DRIVES IT (FOR A CHANGE)
In recent years, the AV industry has been a poor step-child in relation to the burgeoning IT behemoth. Yet the peculiar demands of AV, particularly in real-time production environments with high-resolution content, have pushed past the limits of what prior networking technologies could accommodate, no matter how fast the connection. It doesn’t matter if one data packet arrives with lightning speed if another related packet, one that needs to be in sync, gets there a little too fast. A new approach was needed.
The result was AVB, which is now transitioning into a subset of the larger universe of time-sensitive networking. TSN is already finding new applications in the automotive and industrial control sector, with others likely to follow.
With more switch manufacturers—notably Cisco Systems—now rolling out new lines of AVB/TSN switches, the direction of if the IT industry is clear. This is no longer a developing niche market. If you’re an AV integrator dealing with a corporate IT department, it’s a language they likely will understand. They are much more likely to understand the need for these standard network features, than specialized configuration constraints just for AV data.
Veteran industry journalist Bruce Borgerson has written several articles on audio networking as well as technical manual for AVB-enabled products. [EDITOR’S NOTE: This month, this article is also published with other trusted industry publications, such as inAVate, in an effort to share knowledge about an often misunderstood topic.]