Broadcasters use distribution amplifiers (DA) to deliver multiple baseband signals in “one to many” systems. Multicasting is operationally equivalent to the DA but works by duplicating packets so that we do not have to add extra cabling to a system.

To begin multicasting, network administrators define a set of IP-multicast addresses for the network they are operating with. Devices such as microphones are allocated one of the IP-multicast addresses and use them to stream packets to the network. The IPv4 multicast range spans from 224.0.0.0 to 239.255.255.255, providing over 248 million possible groups. Each group is divided into scopes defining different usage. For Audio over IP, the scope freely available to network administrators ranges from 239.0.0.0 to 239.255.255.255, just over 16 million addresses.

Multicasting is provided at layer-2 to keep latency and jitter low and is referred to as IGMP-Snooping. A mapping between layer-3 IP multicast addresses and layer-2 Ethernet MAC addresses is defined allowing a unique MAC addresses to be created for each IP-multicast stream.

Without IGMP-Snooping, any multicast traffic received by the switch will be flooded to all ports on that switch, resulting in a network broadcast. This is a consequence of a switch not knowing which port to send a frame to, so it defaults by sending the frame to all ports. In the extreme, this causes excessive network congestion.

IGMP hosts, such as IP-Audio-Monitoring stations, will issue an “IGMP Membership report” encapsulated in an IP-datagram. The report, often referred to as a “join” message, requests one specific multicast group and an IGMP-snooping enabled switch will forward all frames to that receiver.

To stop receiving a multicast stream, the receiving host will issue an “IGMP leave” message.

During forwarding, the IGMP Querier (typically the switch) will issue IGMP Queries to all hosts (perhaps audio desks or monitoring stations) to check whether the hosts are still interested in the stream. If they report do not, or the query times out, the switch will stop sending the stream to the unverified port.

Hosts on different subnets can exchange multicast traffic if routers between them support a multicast routing protocol, such as Protocol Independent Multicast (PIM). The routers will then forward the IGMP Messages to the subnet where the streams originate.

Using a recording studio as an example, each of the microphones would be configured to have its own multicast address. It is possible to use direct mapping from each microphone to each input on the desk but this would restrict operation since no other device would be able to listen to the microphones and configuration would be extremely complex. Multicasting allows multiple destinations, such as the audio desk input and a monitoring station, to receive the same microphone output.

Multiple microphones could be configured by the network administrator to each have their own multicast stream. For example, if studio-1 is using twelve microphones, mic-1 would have IP-multicast address 239.255.0.1, mic-2 would have 239.255.0.2, all the way up to mic-12 which would have IP-multicast address 239.255.0.12.

To keep jitter and latency low, each microphone, audio console channel, and monitoring station for studio-1 would connect to a port on the same layer-2 switch to form a LAN. However, to control network congestion and maintain security, studio-1 would use VLAN-1 and studio-2 would get its own VLAN-2. Any devices connected on VLAN-1 would not be able to access devices on VLAN-2 and vice versa. There may be many VLAN’s in use depending on the granularity of security required.

As well as configuring the IP multicast address of each microphone, the source and destination MAC addresses of the frame must also be configured. The source MAC is set by the manufacturer of the microphone. But the destination MAC address is derived from a combination of the reserved MAC prefix 01.00.5E and the IP address of its multicast stream, this is usually set by the operating system or implemented by the vendor of the microphone. This forms the next three numbers of the MAC address derived from the IP address.

To receive a feed of the microphone outputs, each audio channel on the audio console must subscribe to its associated IP-multicast stream.

The audio console would have a unique IP address and each channel would subscribe to one of the IP-multicast addresses. The audio console would send a “report” message for each channel to the switch to request a copy of the microphones multicast stream and hence its output. In this scenario, each microphone would issue a mono audio stream on a specific multicast address.

Source Specific Multicast is used to stop the possibility of multicast duplication. Supporting switches and routers will only forward multicast traffic if, the receiving host issues “IGMPv3” messages, specifying not only the multicast address it wants to receive, but also the source IP of the sending device.

A device can only connect to one layer-3 router to exchange messages as the “Time to Live” of its IP header is set to one, thus stopping the datagram from moving on to another router. IGMP facilitates communication between routers to allow streams to be accessed outside of a devices LAN.

Although IP-multicasting is incredibly powerful and extensively used, its limitations soon become apparent. IGMP is a program running on a CPU on the router and is constantly fighting for CPU time along with all the other protocols running on the router. As multicast streams increase and the number of devices wanting to connect to them also increases, so does the demand on the switches CPU. The streamed data reliability of the actual microphone output is not affected by the protocol but the speed and response with which devices can opt to switch to and from different streams is.

Switches and routers state maximum numbers of multicast addresses to be used on the device for that reason. Typical values are between 1,024 and up to 10,000 addresses. But some devices exist that can only manage 128 addresses.

This is another reason software defined networking (SDN) is gathering momentum. SDN has a hierarchical view of the underlying hardware network and controls switchers and routers directly to overcome the speed limitations of protocols such as IGMP.

Vendors use different methods of remote control. Cisco use the command line interface (CLI) and REST (Representational State Transfer). Arista uses REST but it’s different from Cisco’s version. AMWAs IS-06 is looking to resolve these differences by providing a common interface for SDN’s.

Multicasting works well when a connection needs to be occasionally made but can become slow to respond when there is heavy demand on the routers’ CPU. These limitations will be overcome as SDN develops.