Multicast Communication

I’m sometimes envious at how a group of women can be engaged in multiple concurrent conversations and they can all keep track of all the different conversations with ease (multicast communication). That’s always intrigued me because if there is a group of guys, generally only one guy speaks at a time (unicast communication). Apparently, women are blessed with the innate ability to simultaneously manage multiple conversation threads. God bless them because I have trouble managing a single conversation thread most days.

It struck me this week that multiple conversation threads are very similar to how unicast and IP multicast communications operate. Unicast conversations are one-to-one. A sender transmits a message from this IP address to some other IP address where the receiver is. Of course, routers and gateways can get involved to move messages from this subnet to that subnet, but the principle still stands—one sender and one receiver.

That works fine for most communications (you generally don’t want your email being distributed to everyone), but if it’s a sports score, the streaming video of your daughter’s wedding or the price of oil, you want to easily send that information to multiple receivers. That’s where IP multicast comes in. Your message goes to any number of receivers.

There’s a big difference between unicast and multicast in low-level communications. Unicast uses TCP (Transmission Control Protocol) for communications while multicast communication uses UDP (User Datagram Protocol). TCP, as you remember, is an acknowledged protocol. You get a message indicating that your message was received. UDP is smaller, simpler and more efficient, but if some of your receivers don’t get one or more messages, there is no way to know. You don’t know they didn’t get the messages and they don’t know you sent them. Everybody’s oblivious unless it’s obvious from the data.

In general, the router or broker device that manages the multicast delivery has some sort of mechanism where devices interested in the data available have to subscribe to the data stream. Once they subscribe, anything published by the originating device is pushed out to the subscribers by the router or broker. A key concept here is that the multicast device manager doesn’t replicate the stream thousands of times. Instead, it streams messages that are directed to the devices on the network that have subscribed to those messages. This is important because it means that there are no additional resources required to stream a video to as few as two subscribers or as many as 20,000.

Different multicast systems have different ways for devices to subscribe to a stream. IGMP (Internet Group Management Protocol) is one of the ways that routers can establish multicast group memberships. IGMP is used in multicast routing for some of the automation protocols like EtherNet/IP and Profinet IO. Group membership is controlled by the routers and can be very dynamic with subscribers coming and going all the time. Routers continuously process the subscriber list to identify which sub-networks have active clients for each multicast group to minimize transmission across parts of the network for which there are no active clients.

Devices can distinguish multicast traffic from other traffic by the IP address used in the message. Multicast addresses (IPV4) use a leading 1110 in the IP address. This corresponds to the IP address range from 224.0.0.0 to 239.0.0.0. All network cards today understand this multicast address block and if your device is not participating in a multicast stream, they automatically filter out these messages. That wasn’t true years back when it was expected that the application program would perform this task for you.

Over the years there has been some misleading information about this protocol or that protocol supporting multicast communication and that one only supporting unicast. What’s true is that both EtherNet/IP and Profinet IO support both. Multicast is an important feature of these automation technologies because, often, I/O data needs to be shared by multiple controllers. Instead of having one controller read a message and then pass that I/O data to another controller, all controllers can immediately share it. Much like the conversation at the dinner table between a group of women. No need for one woman to tell someone else what was said—they all heard it.