Abstract: Industrial control networks widely adopt a producer-consumer communication model, resulting in a large amount of multicast data. Traditional switches' broadcast-style processing of multicast data significantly degrades the performance of switched Ethernet. This paper compares and analyzes several existing multicast methods in switched Ethernet and outlines their respective applications in switched industrial Ethernet. Keywords: Switched Industrial Ethernet; Multicast; Virtual LAN; IGM Snooping; Cisco Multicast Management Protocol; GARP Multicast Registration Protocol [align=center] Multicast Methods in Switched Industrial Ethernet ZHANG Qi-zhi, CAO Chun-sheng, ZHANG Wei-dong Department of Automation, Shanghai Jiao Tong University, Shanghai, 200030, China[/align] Abstract : Because the “producer-consumer” communication mode is widely adopted in industrial control networks, there is a large amount of multicast data in the network. Traditional switches broadcast multicast frames to all ports, which can significantly degrade the performance of switched Ethernet. This article compares several existing multicast methods and points out their respective applicable scopes in switched industrial Ethernet. Keywords : switched industrial Ethernet; multicast; VLAN; IGMP Snooping; CGMP; GMRP 1. Introduction In industrial control networks, large amounts of real-time data are often transmitted using a "producer-consumer" communication model. The producer is the workstation that sends the real-time data, and the data it generates can be used by multiple consumers simultaneously. This communication model ensures spatial consistency of the same real-time data and saves bandwidth, as each newly generated piece of real-time data only needs to be sent once. This "one-to-many" data transmission in industrial networks corresponds to multicast frames in Ethernet. However, multicast data is sent in a broadcast manner in traditional Ethernet switches because switches typically learn the MAC addresses of workstations connected to each port by examining the source addresses of received Ethernet frames. Multicast MAC addresses are never used in the source address of an Ethernet frame, and switches have no way to dynamically learn them. When there is a large amount of multicast data in the network, the broadcast data caused by multicast frames consumes a significant amount of bandwidth and can even cause "broadcast storms," ​​leading to network instability. The most obvious method is to statically configure multicast addresses for each port of the switch. This method is feasible, but its scalability and dynamic adaptability are poor. Sections 2 to 5 of this paper introduce four commonly used multicast methods in switched Ethernet. Section 6 compares and analyzes them and points out their respective applicable scope in industrial Ethernet. 2. Virtual LAN (VLAN) VLAN refers to an end-to-end logical network that can span different network segments and different networks, built on the basis of a switched LAN using network management software. A VLAN forms a logical subnet, that is, a logical broadcast domain, which can cover multiple network devices and allow network users in different geographical locations to join a logical subnet. One of the main advantages of VLAN is that it can suppress network broadcast storms. A VLAN is a logical broadcast domain. By creating a VLAN, broadcasts are isolated and the broadcast range is reduced, and the generation of broadcast storms can be controlled [1]. Thus, it can be envisioned that workstations belonging to each "producer-consumer" data group are grouped into a VLAN. When the producer in the group sends multicast data, only the data group members belonging to the VLAN can receive the corresponding multicast data. As long as there is a "producer-consumer" data group in the control network, it corresponds to a VLAN. Clearly, the number of VLANs that should be allocated in a control network is directly proportional to the number of "producer-consumer" data groups. Since controllers at the control layer often participate in multiple control loops to perform optimized control calculations, they should simultaneously reside in multiple VLANs to exchange data with workstations in multiple control loops. For small control networks, this multicast method may be feasible, but for medium and large-scale control networks, a large number of VLANs will inevitably significantly reduce the performance of the control network and bring great difficulties to VLAN management and maintenance. In large control networks, the number of "producer-consumer" data groups may even exceed the number of available VLANs (4096). Due to the security mechanism of VLANs, communication between members belonging to different VLANs must be forwarded through a router. As shown in Figure 1, when workstation A in VLAN 1 has data to send to workstation B in VLAN 2, workstation A must first forward its data to the router in the network, and then the router forwards it to workstation B. The router's intervention will inevitably increase the data transmission latency, and for real-time messages, it may even cause them to lose their real-time performance. Although Layer 3 switches with hardware routing capabilities can enhance the real-time performance of data that needs to be routed, they increase the overall cost of the network and the complexity of network management. [align=center] Figure 1 Workstations in different VLANs forward data through a router[/align] 3. IGMP Snooping The Internet Group Management Protocol (IGMP) defines how workstations register with routers to receive specific IP multicast data. When an Ethernet switch receives an IGMP message transmitted between a workstation and a router, it intercepts and analyzes the information carried in the IGMP message, establishes and maintains a MAC multicast address forwarding table, and then forwards multicast messages sent from the router according to the "multicast group-port" correspondence in the table[2][3]. 3.1 Joining a Multicast Group via IGMP Eavesdropping [align=center] Figure 2 Joining a Multicast Group via IGMP Eavesdropping[/align] When a workstation is the first in a switching group to join a multicast group, as shown by workstation A in Figure 2, the joining process is as follows: Workstation A first actively sends an IGMP membership report to the router. The switch intercepts and analyzes the membership report to determine the multicast group the workstation wants to join. Then, it creates a multicast project group for it and links it to the port where workstation A is located and all router ports. Finally, the switch forwards the IGMP membership report to the router port so that the router can receive the IGMP report and update its multicast routing table accordingly. When a workstation wants to join an existing multicast group, as shown by workstation B in Figure 2 wanting to join a multicast group that workstation A has already joined. The switch simply links the port where the workstation is located to an existing multicast group and no longer forwards IGMP reports to the router. Instead, it uses a proxy reporting mechanism to forward an IGMP report to the router for each multicast group every 10 seconds. This proxy reporting mechanism can reduce the bandwidth consumed by the IGMP eavesdropping multicast mechanism [3]. 3.2 Using IGMP eavesdropping to leave a multicast group When a workstation wants to leave a multicast group, it can simply ignore the periodic IGMP query messages or send an IGMP Leave message. When the switch receives an IGMP Leave message for a multicast group, it will send a specific group query message for the group to be left to the port that received the message to confirm whether there are any other members of the multicast group in the workstation connected to this port, and start a query response timer. If the report message of the multicast group is not received after the timer expires, the port will be removed from the corresponding MAC multicast group. If the MAC multicast group has no members on any port of the switch, the switch will notify the multicast router to delete the branch from the multicast tree [2]. 4. Cisco Group Management Protocol (CGMP) is a proprietary group management protocol of Cisco. It is a communication protocol used between multicast routers and switches. The main working method is that the multicast router notifies the switch of the CGMP information it has received through CGMP messages. The CGMP module on the switch converts the "multicast group-workstation" correspondence in the received CGMP frame into a "multicast group-port" pair, and establishes a local multicast address forwarding table based on this, and then forwards multicast data according to this relationship [3][4]. 4.1 CGMP Data Frame Format CGMP is an Ethernet data frame with a destination address of 0x01-00-0C-DD-DD-DD. It mainly contains the following fields [4]: ​​(1) Version number, 1 or 2. (2) Message type, Join or Leave. (3) Count value, multicast/unicast address pairs contained in the message frame. (4) GDA (Group Destination Address), a 48-bit multicast MAC address. (5) USA (Unicast Source Address), a 48-bit unicast MAC address to be joined to a multicast group. 4.2 Joining a Multicast Group Using CGMP When a workstation wants to join a multicast group, it sends an IGMP Membership Report. After receiving the IGMP report, the router copies the multicast MAC address declared in the IGMP frame to the GDA field of the CGMP Join data frame, copies the source MAC address of the sending station to the USA field of the CGMP Join data frame, and then sends the constructed CGMP data frame to the switch. When a switch with CGMP multicast functionality listens for a data frame with a destination address of 0x01-00-0C-DD-DD-DD, its processor looks up the corresponding USA in its "address-port" table. Once USA is found in the table, the switch knows which port the USA is located on, and then it performs one of the following operations: (1) Creates a new multicast group for the GDA and links the port corresponding to USA and all router ports to the GDA. (2) If the multicast group belonging to the GDA already exists, the switch simply adds the port corresponding to the USA to the port list of the existing GDA. 4.3 Leaving a Multicast Group Using CGMP When using IGMPv1, if a workstation wants to leave a multicast group, it does not send an IGMP leave message. The router sends an IGMP leave message after receiving no response after two consecutive IGMP queries. If there are still users interested in a multicast group, the port belonging to that multicast group will not be removed from the multicast tree. When using IGMPv2, if a workstation wants to leave a multicast group, it can send an IGMP leave message. CGMPv2 enables workstations to leave a group quickly using this mechanism (CGMP Fast-Leave). The CGMP Fast-Leave processing method allows the switch to listen for IGMPv2 Leave messages sent by workstations to all router multicast addresses (224.0.0.2) in the port monitoring engine module (a hardware module with IGMP resolution function). When it detects a Leave message, it starts a query response timer and sends a query message to the port that received the Leave message to confirm whether there are any workstations on that port that want to receive data from this multicast group. If no CGMP Join message is received by the timer expires, the port is removed from the multicast tree of the multicast group indicated by the IGMP Leave message. If it is the last port in the multicast group, the switch forwards the IGMP Leave message to the router port. The router then initiates the normal deletion process by sending a query message for a specific group. Since no response message is received, the router deletes the corresponding port in the multicast routing table. At the same time, the router also sends a CGMP Leave message to the switch to delete the multicast group from the forwarding table [3]. 5. GARP Multicast Registration Protocol GMRP is defined in the IEEE 802.1D standard. It uses the GARP (generic attribute registration protocol) mechanism to declare and register the need for workstations and switches to listen for and receive multicast data. 5.1 GMRP Frame Format The GMRP data frame format is shown in Figure 3. The meanings of each field are as follows: (1) GMRP application address, which is the multicast address 0x01-80-C2-00-00-20. (2) Source address, which is the unicast address of the device that generated the GMRP data frame. (3) Length, indicating the length of the entire GMRP data frame. (4) LLC header, all GARP applications use the LLC service access point with source and destination addresses of 0x42. The control field value is 0x03, indicating a connectionless service. (5) Protocol ID: All GARP applications use a protocol ID of 0x0001 to distinguish it from other LLC services (such as Spanning Tree Protocol). [align=center] Figure 3 GMRP Frame Protocol Format[/align] (6) GMRP Attribute Category: GMRP data frames can contain multiple GMRP information fields, with the value 0x00 indicating the end of the GMRP information. GMRP information has two attribute categories: when the attribute type is 0x01, it indicates that the following is a list of group membership attributes, used to declare the need to receive specific multicast data; when the attribute type is 0x02, it is to ensure compatibility with devices that do not support GARP. (7) GMRP Attribute List: The attribute list can contain multiple attribute values, each of which contains three elements: attribute length; attribute event, indicating the action to be taken for the attribute value, such as joining or leaving a multicast group; attribute value, which is a 48-bit MAC multicast address when the attribute category is a group membership attribute[5][6]. 5.2 GMRP Multicast Principles GMRP is implemented based on the GARP working mechanism and is used to maintain dynamic multicast registration information in switches. All switches that support GMRP can receive multicast registration information from other switches and dynamically update their local multicast registration information. They can also propagate their local multicast registration information to other switches so that the multicast information of all devices that support GMRP in the same switching network can reach a consensus. GMRP operates according to the following principles [5]: (1) Devices declare their desire to join a multicast group through the Join command. This declaration can be revoked by the Leave command. (2) When an existing device in the same network segment declares its interest in a multicast group, if another device that is interested in the multicast group hears the declaration, it does not need to make an explicit declaration. (3) When a switch hears a declaration for a multicast group on a port, it adds a registration information for the multicast group on that port. When all devices that have declared the service of a multicast group have left, the switch will deregister the declaration for the multicast group from other switches. (4) The switch will broadcast the registration information of one port to other ports, and the multicast registration information will be broadcast along the spanning tree. 6. Comparative Analysis of Four Multicast Methods Table 1 compares the four multicast communication methods mentioned above. Except for VLAN, the other multicast methods are multicast solutions designed for the characteristics of multicast communication. They are essentially multicast solutions that build a Layer 2 multicast tree and reduce unnecessary data transmission on the network. Although many scholars in the control field have proposed using VLAN to solve the multicast problem in switched industrial Ethernet, as can be seen from the analysis in Section 2, VLAN is not an ideal solution for multicast communication. It is only suitable for control networks with a small number of "producer-consumer" data group members, and the communication between different VLANs should be limited to a certain traffic volume because they must be forwarded through the router. When the communication traffic between different VLANs is large, the router will become the communication bottleneck in the control network. Therefore, the use of VLAN to implement multicast should be limited to small control networks. [align=center]Table 1 Comparison of Four Multicast Methods[/align] When using the CGMP protocol, the router constructs CGMP messages based on the received IGMP messages and then sends them to the switch for Layer 2 multicast configuration. Therefore, a multicast router is a necessary device when using the CGMP protocol. When using IP eavesdropping, since the switch can replace the multicast router in parsing IGMP information, with proper configuration, multicast configuration can be performed without the router's intervention, with the switch acting as the router's agent. Both the IGMP eavesdropping method and the CGMP protocol originated from the need for rapidly growing multimedia communication on the Internet. They both utilize IGMP message information on the Layer 3 network when constructing the Layer 2 multicast tree. The Layer 2 multicast address is derived from the Layer 3 IP multicast address; therefore, workstations participating in Layer 2 multicast must also be configured with a Layer 3 IP multicast address. On the other hand, both CGMP and IP eavesdropping are proprietary multicast solutions. CGMP is only supported by Cisco switches and routers, while IP eavesdropping methods are supported by multiple switch manufacturers, but there is no unified standard for their implementation. GMRP was proposed partly due to the rapid growth of multimedia multicast communication on the Internet, and partly due to the widespread adoption of switched Ethernet (where multicast communication does not consume large amounts of bandwidth). GMRP is a pure Layer 2 protocol, and the GARP registration protocol it uses is also used by VLANs to register the VLAN attributes of each workstation (GVRP, GARP VLAN Registration Protocol). Therefore, GMRP will gain increasingly widespread support in Ethernet switches. When using GMRP, the workstation's network interface card and protocol stack must also provide GMRP support, but the protocol stacks of existing devices and systems do not provide sufficient support for GMRP. Therefore, in industrial switched Ethernet, CGMP or IP eavesdropping can currently be considered to solve the multicast problem of real-time data. After the workstation interface cards and system protocol stack make corresponding improvements to GMRP, the transition to using GMRP to solve the multicast problem in Layer 2 control networks can be gradually achieved. 7. Summary This paper analyzes the characteristics of data communication in industrial control networks: namely, the existence of a large amount of multicast data. It introduces four commonly used multicast methods in switched Ethernet: VLAN, IGMP eavesdropping, CGMP, and GMRP, comparing and analyzing their characteristics and indicating their respective application scopes. On the other hand, since the switch's learning and registration process takes time, if data is transmitted during this period, the switch will still broadcast data to unknown multicast addresses, leading to broadcast storms and instability in the control network. Therefore, it is necessary to introduce a learning period before each workstation officially communicates, allowing each station sufficient time to register its multicast address. During this period, the switch can also learn the unicast addresses of each workstation, thereby minimizing broadcast data on the network when officially transmitting control data. References [1] IEEE Std 802.1Q. IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Network [S]. 1999 [2] Wang Jun, Wu Zhimei. Multicast Protocol on Switched Ethernet [J]. Journal of Software, 2003, 14 (3): 496-502 [3] Cisco Systems Inc. Multicast in a Campus Network: CGMP and IGMP Snooping [J/OL]. URL: http://www.cisco.com/. 2003 [4] Kennedy C. and Kevin H. Cisco LAN Switching [M]. Cisco Press, 1999, 773-598 [5] IEEE Std 802.1D, 1998 Edition. Media Access Control (MAC) Bridges [S] [6] Rich Seifert. The Switch Book [M]. Wiley Computer Publishing, 2000, 422-429