Network Protocols

Protocols are sets of standards and rules for how to communicate, format, and process data in a network.

Many protocols are officially standardized, meaning their rules are ratified by a professional organization or committee.

Specific standards are noted when relevant. Standards organizations include:

• Institute of Electric and Electronics Engineers (IEEE)
• American National Standards Institute (ANSI)
• Telecommunications Industry Association (TIA)
• Entertainment Services and Technology Association (ESTA)
• Internet Engineering Task Force (IETF)

For more information, please visit the linked websites.

Communication Methods

Protocols send data in networks via three common methods: unicast, broadcast, and multicast.

Unicast

Unicast is a protocol communication method where a single sender transmits data to a single receiver in a single IP network.

Unicast is like emailing a colleague, where you write a message and send it to their email address. Similarly, the unicast sender addresses the data to a specific IP address.

While unicast messages can be sent to multiple receivers, each message is sent separately, with individualized packets addressed to each device. This would be like you writing the same email individually for multiple colleagues and sending them all separately. This can make unicast a resource-intensive method of network communication for the sender.

Broadcast

Broadcast is a protocol communication method where a single sender transmits data to every receiver in a network's subnet. The receivers must then process the data and determine whether or not it applies to them.

Broadcast is like emailing an entire department. You send one email that everyone in the department receives, who must then individually decide whether they can ignore the email, or if they need to take action on the received information.

While broadcast is easy on the sender, its lack of sophistication can make it resource-intensive for the rest of the network, especially receivers. If you spent all day reading and sorting through mass email communications not specifically applicable to you, you might not get much work done. Similarly, the required action from a broadcast message can reduce resources needed to keep devices running. This is sometimes referred to as a broadcast storm.

Broadcast is an IPv4-only protocol (see Internet Protocol (IP) > Versions) and is sent between devices with the same Subnet Mask.

Multicast

Multicast is a protocol communication method where data from one or more senders is transmitted to one or more receivers that have requested to receive the data. More specifically, one or more sending devices transmits data to a switch, which forwards the data to a specific virtual IP address, known as the multicast address. Any receiving device that is interested can subscribe to that address to receive any data sent there.

Multicast is like giving up on emails and deciding to post information to an internal blog or website. Some colleagues join you, writing posts of their own. Anyone interested can choose to subscribe to one or more of the authors and their updates, ignoring anything not applicable to them. Anyone not interested can ignore the entire site altogether. This makes multicast a happy middle ground between unicast and broadcast.

The IP address range from 224.0.0.0 through 239.255.255.255 are reserved by the IEEE for multicast addresses, and cannot be used when assigning IP addresses to nodes. A subset from 239.255.0.1 (universe 1) through 239.255.249.255 (universe 63,999) are reserved specifically for use with sACN universe data. See Internet Protocol (IP) and Streaming ACN (sACN).

Why Multicast

Multicast is the backbone of real-time entertainment control. While unicast is easier for receivers, the amount of work it requires of senders makes it an impractical choice for low-latency systems. While broadcast is easier for senders, the amount of extraneous information being sent to and processed by each receiver similarly clutters a network. Multicast allows for selective involvement of the relevant devices for each universe, reducing the redundancy of data on the network to its lowest possible level.

In a multicast system, when sACN data is sent about a universe, it is actually being sent to the reserved multicast IP address of that universe. For example, Eos data for fixtures in universe 1 would be sent to 239.255.0.1. The packets contain information indicating that this is multicast data for any device interested in universe 1. The switch then duplicates the packets and distributes them to any devices subscribed to universe 1.

For example, imagine a 2-universe system divided equally between four DMX gateways. Eos sets addresses 1 through 256 in universe 1 to full, which sends data packets to the multicast address for universe 1, 239.255.0.1. The switch consults its internal list of the group of devices subscribed to that universe and duplicates the Eos data to send to all devices in the group; in this case, the first two gateways. Since all the affected addresses are assigned to the first gateway, it acts on the command and sends the DMX commands to turn on those addresses. The second gateway discards the packets.

The group of devices sending or receiving information about a particular universe is referred to as a multicast group, which are managed by Internet Group Management Protocol (IGMP)-enabled switches. Both a controller providing information about a universe or a subscriber asking about a universe can trigger the creation of a multicast group for that data.

Eos communication in Multi-Console Sessions is built on multicast data distribution, and both Streaming ACN (sACN) and v4 of Art-Net use multicast to transmit address levels. Configuring a control network to manage the efficient distribution of multicast traffic reduces unnecessary data transmission and ensures that data only reaches the appropriate destinations. Networks improperly configured for multicast may not be able to transmit multicast data. In an unconfigured system, multicast is treated as broadcast data.