PROFINET Can Multicast. But Why Do It?

Posted by & filed under Uncategorized.

There was a recent blog post over at Schneider called “It’s all about choice: EtherNet/IP and unicast and multicast traffic.”

You can follow the link to read the whole thing but the gist of it is: “PROFINET people think EtherNet/IP cannot unicast, but it can do both multicast and unicast. PROFINET can only unicast. So choose EtherNet/IP to get a choice.” So rather than leaving you casting about for definitions, here’s a video explanation of unicast and multicast:

multicast_vs_unicast

EtherNet/IP began as a multicast-only protocol and at some point added unicasting. PROFINET IO spec version 1.0 specified both unicasting and multicasting. So I think the correct conclusion should be: “EtherNet/IP can do unicast but most devices support only multicast. PROFINET can do multicast, but most devices support only unicast.”

Now there are many other great reasons to choose PROFINET over EtherNet/IP, but let’s explore the casting difference and the Schneider blog post.

PROFINET is designed to use unicast transmissions because the frames are small and the protocol encoding doesn’t impose significant overhead on the IO data. Furthermore, unicast is by definition the best way to communicate between two endpoints. In contrast, multicast is the logical way for one point to communicate with many others. But that’s not what you really want to do when you only need to transfer cyclic data between two endpoints. So while PROFINET can support multicast IO and does give the system architect a choice to use it, most vendors don’t implement Multicast IO because it’s almost totally useless for day-to-day cyclic I/O tasks.

But let’s talk specifics here. The author of the Schneider blog post brings in a straw man to pose the argument against unicasting, “Multicast traffic over EtherNet/IP delivers benefits that reduce network traffic load as it facilitates the sending of information common to multiple but independent devices in one communication, thus reducing bandwidth.”

I see two problems with this sentence:

1) What information needs to be sent to multiple but independent devices with every IO cycle? Maybe it’s my PROFINET-centric view of the automation universe, but I just don’t see that use case in the field.

2) “Thus reducing bandwidth.” You have 100Mpbs of bandwidth available to you, and you’re going to sweat the difference between sending a single 128 byte frame vs… what, three of them? If the system integrator or end customer doesn’t install a switch with IGMP snooping enabled by default, a multicast transmission would send a single 128 byte frame to, say, thirty end nodes on the same switching domain! How does that reduce bandwidth utilization?

I also disagree with the claim that production networks need to utilize the finest (and most expensive) network topologies and traffic management features. A plant-level network will certainly have flood control mechanisms built-in (like Ethernet switches with IGMP snooping), but at the machine level, you can use a simple switch. Why spend the extra money per switch on a machine network to get a feature that you shouldn’t need in the first place?  (Now there are lots of good reasons to use more expensive managed switches, but not always. See PROFINET on a Big Project or Small – What’s the Difference?)  And as for “protecting from cybersecurity threats by pruning IO data traffic?” PROFINET does that by design – no IP encoding means our IO frames stay where they should be (with the exception of the rarely-used UDP Real Time channel). And you wouldn’t need some of that cybersecurity protection if you weren’t multicasting your IO data to everyone and their cousin!

Finally, why use multicast communication for IO in the first place? Now sometimes it might make sense to multicast to controllers. One use case would be when you have several motion controllers that need to share data. PROFINET can do that, but using it for IO is not common. Because there is seldom a need to send the same IO data to multiple IO modules.

So yes, both protocols give you choice as to whether or not to use multicast communication. But there is really little reason to use multicasting if you have the option to unicast.

–Carl Henning (with contributions from the PROFI Interface Center)

2 Responses to “PROFINET Can Multicast. But Why Do It?”

  1. Wanda Reiss

    Thank you Profinet.com blog for continuing this conversation on “It’s all about choice” http://blog.schneider-electric.com/machine-and-process-management/2014/10/24/choice-ethernetip-unicast-multicast-traffic/#comment-292048.

    Profinet has the capability to deliver multicast communication for their IO traffic in some Profinet-specific way; they call it Multicast Communication Relation (MCR). EtherNet/IP uses standard IT practices for unicast or multicast, according to the customer needs and choices. In general, I agree with those customers who prefer adopting IT protocols whenever feasible, including the standard IT method of unicast or multicast communication.

    Let’s explore the idea that EtherNet/IP forces customers to use expensive managed switches; far from the truth. Managed or unmanaged switches are also a customer’s choice. It is all right to use unmanaged switches in simple networks. Customers may also consider light managed switches, offered at a price point of unmanaged ones. They are simple to use yet with the right functionality.

    Profinet deals with cyber security “by design” by “no IP encoding”…to this point I believe that security involves many aspects, one of which is controlling the flow of packets on a network. That needs to be done but can be implemented in the protocols, the infrastructure and dedicated protection devices. But security is a large separate discussion.

  2. Carl Henning

    We agree that both PROFINET and EtherNet/IP can use unicast or multicast. Where we disagree is a definition of “standard IT practices.” EtherNet/IP sticks to the TCP/UDP/IP stack, but that is not the only “standard IT practice.” The definition of Ethernet includes the EtherType field which allows received Ethernet frames to be directed to their destination. EtherType 0x0800 will direct the frame to IP; other EtherTypes will send it elsewhere, like to the Address Resolution Protocol application. PROFINET Real Time (RT) has a unique EtherType that sends the frame to the PROFINET application. Still standard Ethernet and standard IT practice. And this method provides improved speed and determinism for PROFINET over EtherNet/IP as tested by the University of Michigan and reported here: http://www.iebmedia.com/index.php?id=5430&parentid=63&themeid=255&hft=38&showdetail=true&bb=1

    I am a huge fan of managed switches anyway due to their ability to provide diagnostic information. But in the multicast-only days of EtherNet/IP, the manuals recommended all switches be managed and support IGMP. Perhaps those days are past.

    We can certainly agree that security is a huge separate discussion with many nuances. And we can probably agree that PROFINET, EtherNet/IP, and Modbus TCP should all use the same techniques to achieve security.

« Back to PROFIblog