E1.31 Multicast vs Unicast

Right up front its not a Versus thing. Both Multicast and Unicast are valid ways of getting data from a sACN controller to a sACN device. There are situtations where using either is more appropriate or easier to configure. For this sake of this Wiki entry, a 'controller' is the thing sending data, and a 'device' is the thing receiving it. This comes from the ETSA E1.31 standard, - streaming ACN.

A Multicast primer.

Some flows of data are one to many or many to many, where one or multiple sources are sending to multiple receivers. Examples are the sending of bulk messages to employees on a business network, communication of stock prices to brokers, video and audio conferencing, and replicating databases and web site information. Specifically for lighting, many devices can receive the same data ( a universe ) from a source. These flows are multicast.

IP Multicast efficiently supports this type of transmission by enabling the sender to send a single copy of a universe to multiple devices who explicitly want to receive the information. This is far more efficient than requiring the source to send an individual copy of a message to each requester (referred to as point-to-point unicast), in which case the number of receivers is limited by the bandwidth available to the sender. It is also more efficient than broadcasting one copy of the message to all devices (broadcast) on the network, since many devices may not want the message.

Multicast is a receiver-based concept: devices join a particular multicast session group and traffic is delivered to all members of that group by the network infrastructure. In the case of sACN data, there is a mapping between universes and groups. The sender does not need to maintain any information about the receivers either. as only one copy of a multicast message will pass over any link in the network. Each time paths diverges a copy of the message will be made by a router or a multicast aware switch. IP Multicast yields many performance improvements and conserves bandwidth end-to-end, when you have multiple devices wanting to receive the same data, for example, several devices that all want to receive a specific universe. If you have a situation where only one device is receiving the data, there is no advantage on the network to send it in mulitcast, though sometimes it is easier to configure as the sender does not need to know about the receiver.

RFC 1112, Host Extensions for IP Multicasting, describes IP Multicasting as: “the transmission of an IP datagram ( packet ) to a ‘host group’, a set of zero or more hosts identified by a single IP destination address. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time.” Translating that into sACN terms. " the transmission of universe to groups of devices indenitied by a single IP destination address. Devices can join and leave groups at any time, and there is no restriction to the number of devices that can join that group.

An Overview of What’s Needed for IP Multicast.

To (properly) support IP multicast, the infrastructure you are using needs to be multicast enabled/aware. You can also use multicast in a non multicast aware network, as well, but you may run into problems, as it gets bigger or you are sharing a network with other non lighting networks. IP Multicast is enabled to run across the internet, or multi-segmented networks. However for this discussion which is mostly about lighting and sACN, we will stick to a simple network ( single segmented, switched ethernet )..This means that we dont' need to worry about routers.

The requirements for devices
  • Support for IP Multicast transmission and reception in the TCP/IP protocol stack - This normally happens by default.. Window, Linux, Mac's all have it out of the box. Many of the embedded processors that are common in lighting devices do as well. Your control software ( eg xlights, vixen ) needs to be able to send using multicast as well
  • Software on your devices that supports Internet Group Management Protocol (IGMP). ( check this with your blinky equipment vendor, a list will appear below ) . More on IGMP later





In IP networks there are three broad categorys of packets: Unicast, Broadcast and Multicast.
N.B.: for IPv6 networks there is no broadcast category.

Unicast means...
1 sender ( controller ) sending packets to 1 receiver ( device )​
Broadcast means...
1 sender to *everything* else on the network.​
Multicast means...
1 sender to at least 1, but possibly many receivers, who have 'asked' to receive it.​

Tip: Wikipedia offers more thorough information on unicast and multicast.

Unicast

Pros
  • Home Wi-Fi networks won't be affected
Cons
  • A specific DMX universe may only be sent to one controller
  • You need to know the IP address of the controller you want to send a DMX universe to (and to keep it updated if your configuration changes)

Multicast

Pros
  • Multiple controllers can receive the same DMX universe
  • TBA
Cons
  • Interferes and disrupts home Wi-Fi networks (can be avoided by running a separate network or with a network switch/router with IGMP Snooping enabled)
  • TBA

Multicast Compatible Network Equipment

This section is currently empty. If you think you can add relevant details here then please do.

If you know that a particular brand & model of router or switch handles multicast traffic correctly then please list it here - thanks!
  • Juniper EX4550
  • Juniper MX80
  • Juniper MX240
  • Juniper MX480
  • Juniper MX960
  • Cisco ASR1004
Categories: DMX Information pages

This page has been seen 7,058 times.

Recent wiki activity

Icon legend

  • Normal page
  • Color code

    • Content has new updates
    • Content has no updates
Back
Top