Broadcast video, audio, and meta-data is relentless in its thirst for resource. The cyclical nature of media signals, especially with real-time uncompressed video and audio, means they require a constant bit rate with incredibly tight time constraints, especially with SMPTE’s ST2110 where the video packets are evenly gapped with little opportunity for time variance.

Multicast is the preferred method of uncompressed real-time IP distribution within broadcast facilities as it’s low latency and is relatively easy to distribute. A typical broadcast installation may require thousands, if not tens of thousands of multicast streams.

The alternative to multicasting is packet broadcasting. This results in the camera video output being sent to all devices on the network. It’s clear, that as the number of cameras increases and the number of destination devices increases, the network would soon flood, and devices connected to the switch, such as multiviewers and vision switchers, would soon be overwhelmed by the amount of network traffic they would need to process.

Multicast is the IT equivalent of the video and audio distribution amplifier and is characterized as one-to-many and many-to-many mapping. The main difference is that packets are duplicated within a dedicated ethernet switch. The core concept of a multicast operation is that a source device, such as a camera’s video output, will be sent to one of the reserved multicast addresses. Protocols such as the IGMP (Internet Group Management Protocol) are needed to keep a record of the addresses used and which destination devices are connected to it so the appropriate routing can take place.

Using IGMP as an example, a receiver, such as a multiviewer can opt-in to listen to and receive a specific multicast stream on the port of the switch. If a multiviewer was connected to the switch and it was the only device requiring the camera video output, then IGMP would communicate this to the switch to send the camera’s video stream to the multi-viewer port, thus keeping the traffic flow to a minimum and reducing network congestion.

The whole purpose of multicast is to only send the IP media streams to the receivers that require them, thus keeping traffic congestion to a minimum.

A consequence of multicasting is that a packet may be duplicated and sent to multiple ports on a switch. The program output of a sound desk may well be required by many receiving devices such as loudspeakers, encoders, and server-recorders, and these devices may be on different ports on the switch or even different subnets. The switch must then duplicate each of the packets for each switch physical connection and this adds load to the switches processing system.

COTS servers with their roots in Tier-1 datacenters and ISP’s (Internet Service Providers), tend to use TCP/IP as they are generally focused on distributing HTTP internet messages or file transfers. Multicasting is not necessarily their focus.

Real-time broadcast systems can use hundreds, if not thousands of multicast streams in a typical IP infrastructure. Each camera may have six video outputs for HD, SD, HDR and SDR, and two video inputs for teleprompt and the camera operators monitor. Then audio intercom systems may potentially have hundreds of multicast streams before we even get onto audio itself and the complexity of clean feeds and IFB’s.

A further challenge occurs in the prevention of loops. Redundant IP networks provide multiple routes to the same destination so if a link fails then there is a backup connection instantly available. However, if an error occurs or there is a configuration issue, IP datagrams can quickly loop from one router to another causing an IP datagram storm with likely service disruption. A TTL (Time To Live) counter in every packet is decremented every time the packet passes through a switch interface so eventually the packets are dropped. But the storm could easily start up again resulting in random network congestion and latency.

Another effect of multicasting occurs from the use of the PIM (Protocol Independent Multicast) dense mode. It initially floods the network with a multicast stream to all ports and then prunes back any ports that do not have receivers connected to it. Again, adding to the possibility and danger of IP loops.

Instead of using destination addresses to route multicast IP packets, multicasting uses the source address. This is because the destination address contains the multicast address for that stream and not the destination address of any specific device. When a multicast stream appears on a port, the router will look up the route to confirm it has a path out of the router. If it doesn’t, the packet is dropped thus stopping any loops.

In the case of figure 2, we can assume the pruning is complete and the monitor is subscribed to camera’s multicast address 239.10.0.0 via the resilient links L1 and L2. The source address of the camera is 10.10.0.1. Looking at router R1’s table we can see a source address routing exists on port 1 to port 2 and port 3 (for resilience). Router R2 then choses the stream from either port 2 or 3 with the most efficient path based on the link metrics and routes. For this example, we assume R2 has chosen to route port 2 to port 1 so the monitor can receive the video multicast feed from the camera.

However, if, for some reason, router R2 starts to route the cameras multicast stream back down port 3, it will appear on router R1’s port 3 input, potentially creating an IP storm. But router R1 will check the source address of the multicast stream (still 10.10.0.1 from the camera) and determine there is no entry for port 3 on R1 and hence no route. R1 will therefore drop the packet thus preventing a packet storm.

This method of loop prevention is called reverse-path forwarding (RPF) for loop prevention as it’s based on verifying the receiver path back to the root of the multicast distribution.

As networks increase in their resilience and complexity, the processing of multicasting and loop prevention increases exponentially with the number of multicast streams. This is another challenge for COTS switches as multicasting is not used in the internet (although there is currently a great deal of research going on in this field) and COTS switch manufacturers may not always consider multicasting to be a high priority for them.

COTS switches generally use SDN (Software Defined Network) systems such as OpenFlow for their control but the standard version does not calculate the port input (ingress) and output (egress) bandwidths. IGMP does not consider the bandwidth availability of ports when opting in to listen to services, therefore, there is a potential to oversubscribe a port resulting in erratic behavior and lost packets.

Another area of interest for broadcasters is uni-directional IP operation. The wider internet mainly uses HTTP (Hyper Text Transfer Protocol) for its distribution. This is true for web page distribution, OTT, and FTP. HTTP operates on TCP and then IP. TCP is bi-directional as it is designed to provide a reliable data path and mitigate errors through resending packets. This results in bi-directional flow of data at the switches ports.

Broadcasters distributing real-time video and audio use uni-directional UDP packets. These fire-and-forget strategies are essential for maintaining high data rates with low latency. However, COTS switches used in data centers and ISP’s generally assume bi-directional data as they mainly utilize HTTP/TCP/IP connections. Consequently, the switch may be programmed to close a port that does not have adequate bi-directional data.

One solution to these challenges is to use switches that have been specifically tuned for broadcast operations. Equipment such as the Media Links MDX100G Switches use COTS core hardware but then go on to fine-tune it for broadcast operations. For example, they have 8000 multicast entries enabling a significant number of multicast flows (streams) with the associated loop protection. Furthermore, they expect UDP streams and make sure ports are left open even if the traffic is mostly uni-directional real-time video and audio. And OpenFlow has been modified to reduce the possibility of port oversubscription and loss of packets.

COTS has many advantages for broadcasters as it provides greater flexibility and scalability. However, vendors such as Media Links are delivering the best of both worlds by taking established COTS designs and fine-tuning them to the specific needs of broadcasters.