Which Switch for AoIP?

V6N4 5.20.15
IP audio networks are very different from standard enterprise or office networks in almost every way, but none more spectacular than the nature and volume of traffic they handle.

Switches in these networks need to be able to handle large, continuous streams of data.

SwitchesCharts 2560Consider these two graphs that were taken over a one-minute period on two different networks. On the left is a simple office network of 18 PCs doing what PCs usually do – browsing the web, accessing printers, moving files around, and sending and receiving e-mail. You can see that the traffic peaks out at about 144 packets per second, and that the traffic is very “bursty.” Sometimes the network’s very busy, and sometimes it’s relatively quiet. This is typical of most computer networks.

On the right is a graph taken after three audio-over-IP channels were added to that same network. Note that the scale of the graph is different. We have gone from 144 to 25,000 packets per second, which is 173 times the peak traffic we had before. In addition, note that this traffic is steady, not bursty. That high packet rate stays high, and would go even higher if we added more channels. This is what traffic looks like on an AoIP network – very high bandwidth, all the time.

So, when we’re choosing switches for use in our IP audio networks, we look for some definite features and qualities that can handle this traffic load.

First off, the switch has to have a high-capacity fabric, which is the actual mechanism inside the switch that allows it to pass data among its ports. There are a lot of different ways that switches handle traffic – store and forward, cut-through, fragment-free, adaptive switching – but no matter what type of fabric is used, it’s got to be of sufficient capacity to handle full bandwidth traffic without blocking.

Read More...

Second, the switch has to be able to snoop IGMP packets and switch them appropriately. Otherwise, multicast traffic is going to flood everywhere and poorly impact traffic.

Third, the switch has to be managed. We can’t set up, monitor, or control the switch correctly without this crucial feature.

And finally, the switch has to have enough ports to support our intended use of the switch, preferably with a reasonable amount of room for expansion.

Switches as Audio Routers

Ethernet switches do just what it sounds like they do. They operate at OSI Layer 2, which is the data link layer, and they look at the MAC (Media Access Control) address in every packet's header. The switch builds a table of what MAC addresses exist on what ports, and sends packets to the right ports. This means that even during heavy traffic conditions, each port only gets traffic it's supposed to get and nothing else.

Switches communicate in "full duplex" mode, meaning each port can send and receive at the same time. Each machine on the network can effectively “hear” while it's “talking,” which really speeds things up.

Under the control of the AoIP protocol such as WheatNet-IP, the switch carries out the actual routing and distribution of audio throughout the network. That work might be handled by a combination of core and/or edge switches, in which case they collectively act as your audio router and distribution system.

Which Switch is Which?

There are two basic types of switches: managed and unmanaged. Unmanaged switches are the off-the-shelf, sold-in-a-colorful-box switches that you find at the office supply store. They're generally used for building small, basic networks. These switches don't have the most powerful switch "fabric" (the guts that do the switching), which means they could eventually crash, flood the network with garbage, or both. For this reason, and others, unmanaged switches are not suitable for AoIP networks.

Managed switches come in two flavors: Layer 2, which are the sort of switches you’ll find in the IP audio network world; and Layer 3 switches, which are highly sophisticated IP routers in and of themselves.

Managed switches are professional-grade switches. They have a configuration interface so you can get inside the switch and set various operating parameters. They're designed for environments where reliability and high availability matter. They have advanced features like Spanning Tree Protocol, and Link Aggregation built in. And you can usually monitor them in real-time to see how traffic patterns are shaping up and where your bottlenecks, if any, might be. Plus, they support (at one level or another) IGMP, which is essential in the AoIP world.

IGMP Required

IGMP is the Internet Group Management Protocol, also known as multicast. It's designed for applications like AoIP that send a lot of data across the network. It allows a source to send a stream (an audio channel, for example) out just once, and for receivers or "subscribers" to tap into that stream and receive it.

When a source is needed, a "group" is created and the source is streamed. When a destination needs that source, it sends out a special message and "subscribes" to that group, and it then receives the stream.

The switch remembers these subscriptions and routes packets accordingly, so only ports that have subscribers on them receive the stream.

How does it do this? IGMP snooping. Most Layer 2 managed switches have IGMP snooping, a feature that lets the switch “look” inside packets that are coming from an IGMP group. It "knows" when a subscriber signs up to receive a stream, and stores this information in a table. The switch then allows those multicast packets to go only to ports that are supposed to get them, so that the streams don't flood the network. When the last subscriber on a port drops out of a group, the switch "prunes" that port's traffic. This optimizes traffic on the network and keeps bandwidth usage as low as possible.

Scotts-Illustration WO_MULTICASTHere is why multicasting is such a good idea for AoIP networks. Shown are three PCs that are set up to receive audio from a server. Without multicast, the server creates three streams, one to go to each PC, and sends them out onto the switch. The switch dutifully sends each stream to its intended receiver. But the switch is now handling a lot of packets -- the whole stream, times three. This isn't efficient, and if we multiplied this out, it would become unworkable.

Scotts-Illustration W_MULTICASTMulticast is a much better way to deliver packets in the AoIP network. With multicasting, a single stream of packets leaves the server, carrying the audio. At the switch, the group table says that ports 1, 3, and 5 have subscribed to the group, so the packets are sent to those three ports in parallel. The switch is handling a third of the traffic through its switch fabric, and if another port subscribes, there's really not much of an impact on the traffic overall.

Switch Configurations

In AoIP, as in other kinds of networking, we use switches in two roles – edge and core. Edge switches are generally small, lower-capacity switches. We still want them to have all the features we discussed before, but they’re meant to be placed on the periphery of the network, like in a studio or other area within the facility. We might, for example, bring the control surface, the audio access point, and perhaps a remote button panel into an edge switch in the studio.

We don’t need many ports on an edge switch – just what’s local, plus one or two ports to connect it to the core switch. This has two advantages: one, it concentrates traffic so we only need one or two runs back to the core switch, rather than one for each device; and second, it gives us the ability to operate the studio as an independent “island” in the event that there’s a problem with the core switch.

Core switches are big and centrally located, and represent the nexus of the facility. All of the edge switches connect back to the core switch, which generally lives in a rack room or central machine room. Devices local to that area are also often brought directly into the core switch. Core switches are often made very large by stacking multiple switch units – with Cisco, this proprietary cabling system is called Stackwise®. Core switches can also be designed in such a way that they offer redundancy.

Scotts-Illustration EDGE_v_CORE_SWITCHsHere we see a facility of edge and core switches. You can see the edge switches located in each studio, with all local devices connected to them.

From each edge switch, there’s a run back to the core switch. As you can see, if the core switch were to fail, each studio would still be able to function as an “island.”

Other Switch Considerations

We suggest keeping AoIP networks separated and isolated from normal office / enterprise networks. If the networks are not isolated, each network has the potential to adversely impact the other – the guy down the hall streaming video can occupy bandwidth that the AoIP network needs, and the AoIP network can generate enough traffic to make web browsing and other activities somewhat slow.

You can do this by using a large, managed switch to create a separate VLAN for the AoIP network; provided the switch fabric has the capacity, this is fairly safe. However, since you might not have full control of that switch if it’s “owned” by the IT department, we generally prefer to see physical separation of the networks, i.e. not sharing any hardware or infrastructure at all with an office network.

Overall, switches are integral to a larger AoIP ecosystem that includes WheatNet-IP I/O BLADEs, control surfaces, NAVIGATOR software and scripting, talent stations, and processing.

Site Navigations