Designing Multicast Networks: A Primer

Designing Multicast Networks: A Primer

We’ve been talking about some of the networking issues that can impact A/V systems. First, we took a look at some of the issues that can arise when A/V requirements aren’t considered while designing the network. Next, we explained the importance of the Audio Video Bridging (AVB) standard in successful A/V deployments. In this post we will discuss the use of IP multicast to support audio and video conferencing and other use cases.

IP networks are designed for unicast transmissions, which means that a device transmits data to one recipient. With multicast, a device streams data to a group of designated recipients, while broadcast involves the transmission of data from one device to all the devices on a subnetwork.

Multicast is valuable for A/V because it reduces server loads and redundant network traffic. This helps to increase efficiency and performance. It’s important to remember, however, that UDP packets still traveling over the IP network, which provides only “best effort” delivery. Jitter, latency, packet loss and other issues should be expected, so the network must be designed to maximize reliability and Quality of Service (QoS).

The Internet Group Management Protocol (IGMP) is used to establish membership in a multicast group. A device will send an IGMP “report” to tell a multicast router (known as a “querier”) that it would like to be part of the group and receive multicast transmissions. If it no longer wants to be a member it sends a “leave” notice. The querier transmits group membership queries at regular intervals, receives reports and keeps the group membership list up to date. It also forwards any multicast data it receives to networks specified in the membership list.

Layer 2 switches look at some of the data in the IGMP packets traveling from the router to the group members (a process known as “snooping”) and “prune” multicast traffic from subnets that don’t include members. This prevents multicast traffic from flooding the network. If the network doesn’t support IGMP, however, multicast traffic will be sent out as a broadcast transmission.

When designing a multicast network, a key consideration is whether the querier will be located in the core, aggregation or access layer. Placing it in the network core can be challenging, particularly in highly virtualized environments with domains that encompass numerous switch and router ports. For that reason, it often makes sense to put the querier in the access layer. If multicast is mission-critical, multiple devices should be deployed for redundancy.

Next comes the configuration of the querier, a process that’s complicated by the fact that there are three versions of IGMP. Each version has unique characteristics, and the choice depends on the operating system and A/V applications it needs to support. Also, the uplinks that receive multicast streams must be sized properly to handle the traffic. There are rules of thumb to help determine whether a 10G, 40G or even larger switch is appropriate.

Multicast isn’t right for every A/V application. Many organizations will need to use broadcast to push A/V streams from headquarters to branch locations for “state of the union” presentations from the CEO, training required for all employees, and similar use cases. Still, multicast is a useful tool for A/V networks, enabling audio and video conferencing, large content transmissions and downloads, and other applications with high bandwidth and performance requirements.

The Audio Video Bridging Standard is Key to Successful A/V Deployment

The Audio Video Bridging Standard is Key to Successful A/V Deployment

In our last post, we explained why A/V requirements should be considered when designing the network infrastructure. A/V has become mission-critical but many networks lack the bandwidth and Quality of Service (QoS) capabilities needed for an optimal user experience. In some instances, there are physical constraints — there aren’t enough IP addresses and Ethernet ports for A/V components. These issues limit an organization’s ability to implement the latest A/V technologies.

Now we’ll take a deeper dive into some of the networking requirements for A/V. A number of these have to do with the IEEE 802.1 Audio Video Bridging (AVB) standard, which was developed to spur the transition from traditional point-to-point link architectures to Ethernet networks. Eliminating legacy A/V cabling in favor of Ethernet simplifies management, reduces costs and enables the integration of A/V applications. AVB provides synchronization, traffic shaping and other functions needed for the reliable delivery of A/V streaming services.

The AVB standard is broken down into four components:

  1. IEEE 802.1BA: Audio Video Bridging Systems is the umbrella standard that “defines profiles that select features, options, configurations, defaults, protocols and procedures” needed to architect a network that supports time-sensitive A/V streams. Network equipment manufacturers use 802.1BA to develop components that are AVB-compatible.
  2. IEEE 802.1AS: Timing and Synchronization for Time-Sensitive Applications synchronizes A/V applications on Layer 2 devices so that, for example, related audio and video streams arrive at the same time. It uses the Precision Time Protocol (PTP), which offers the sub-microsecond accuracy needed for time-sensitive A/V. The Network Time Protocol used for most applications is only accurate down to the millisecond.
  3. IEEE 802.1Qat: Stream Reservation Protocol (SRP) controls traffic so that adequate network resources are available for A/V transmissions. AVB networks have “talkers” (the source of a stream, such as a microphone) and “listeners” (the destination of the stream, such as a speaker). When a talker initiates a stream, SRP reserves the necessary network resources along the path to the listener.
  4. IEEE 802.1Qav: Forwarding and Queuing for Time-Sensitive Streams schedules A/V traffic for delivery over network switches. It also performs traffic shaping so that A/V streams are distributed evenly and prioritizes A/V traffic for QoS.

For these protocols to function properly, every device in the network domain must be AVB-capable. Therefore, the network switches within the domain must support all of these IEEE standards. In addition, one AVB talker must be designated the grandmaster — the reference clock for synchronization — and all devices must communicate using the 802.11AS protocol. That’s because AVB reserves a portion of the available network bandwidth for A/V traffic and all nodes within the AVB network share a virtual clock.

The network must also be designed in such a way that the devices don’t get out of sync. This can be particularly challenging when circuits are link-aggregated to firewalls without proper configuration. The firewalls may drop sessions if they are unable to sync properly.

None of this is especially difficult. In fact, the AVB standard was designed so that someone without networking expertise can set up an A/V network. But if AVB wasn’t considered when the network was originally implemented, you may be looking at replacing some equipment and making configuration changes. Rahi Systems’ A/V and networking teams can review your existing infrastructure and take steps to ensure that it’s ready for your A/V deployment.

Why A/V Requirements Should Be Considered When Deploying Campus Networks

Why A/V Requirements Should Be Considered When Deploying Campus Networks

Video conferencing, digital signage and other A/V components are an increasingly critical part of the IT environment. These components must connect to the data network for content distribution and control. However, few organizations consider A/V when designing the network infrastructure, which creates bottlenecks and performance problems and limits an organization’s ability to support many A/V standards and protocols.

The traditional campus network model consists of three layers. The core layer provides high-performance switching as well as connectivity between sites. The distribution layer uses routing and Layer 3 switching to move data between subnets and VLANs. The access layer provides connectivity for endpoint devices. The network will also include a firewall and other security controls, and a wireless LAN controller for Wi-Fi access.

The cabling plant is the physical backbone that connects these layers and handles the flow of data. Users connect via an Ethernet port or through Wi-Fi. This physical layer is where many fundamental A/V connectivity problems occur. Conference rooms simply don’t have enough ports to support IP-enabled phones, displays, sound systems, screen-casting devices and control systems. A conference room may be allocated just one IP address, when in fact it will need many more. A/V may share the same VLAN with other applications.

Assuming that all of the A/V components are able to connect, network performance problems can result in a poor user experience. Common symptoms include garbled voice calls, jerky video conferences and even dropped connections. The network lacks the Quality of Service capabilities needed to minimize jitter, latency, packet loss and other issues that impact the delivery of real-time, interactive applications. These issues may appear regularly, intermittently or only in certain locations.

Insufficient bandwidth is another major problem. Video consumes a lot of bandwidth, and organizations with multiple conference rooms will have a lot of video data flowing across the network at any given time. Without adequate bandwidth, A/V systems will be unable to transmit or receive content. In a worst-case scenario, the network could fail, especially when users are experiencing significant packet drops.

Bandwidth issues also arise with real-time versus delayed streaming. If a user is watching a YouTube video, it’s OK if the video buffers. But if a company is streaming a presentation by the CEO for an all-hands meeting, it is critical that the video not be delayed. The network pipes must be big enough to ensure a high-quality viewing experience.

Furthermore, it’s important to remember that TCP/IP networks operate on a “best effort” model. There’s nothing inherent in the network to prevent an application from hogging the bandwidth. There must be some mediation between applications and policy-based mechanisms for managing traffic. It’s also important to use the right video codec. The JPEG2000 video codec is used for real-time streaming, whereas the H.264/H.265 codecs are used for delayed streaming.

This is just a high-level look at some of the networking issues that can impact A/V systems. In future posts we’ll discuss the network hardware requirements for various A/V standards and protocols, several A/V use cases, and Rahi Systems approach to A/V network design. In the meantime, we invite you to contact the Rahi Systems networking and A/V teams to discuss your specific needs and challenges.