QUESTION:
What should you watch out for when using multicast connections and how are they configured?

ANSWER:
Multicast is a special connection option that with Industrial Ethernet CPs is only supported or can only be configured with UDP connections (UDP = User Datagram Protocol). There is often the wish to send a message from one station to multiple partner stations. The important thing here is that the messages are sent simultaneously and are received almost simultaneously by the partner stations. Sending and receiving of broadcast messages is therefore always demanded. In the case of a broadcast message, the message is really received by all the stations on the network. Broadcast messages are also needed, for example, for finding an MAC address to an IP address (ARP request). Therefore a communications module must always accept broadcast telegrams and evaluate them with an appropriate software. If there are too many broadcast messages in the network, the network performance drops. This is because the individual modules have to process all the broadcast telegrams to ascertain whether or not they are meant for them.

The following 2 points are to be noted for Industrial Ethernet CPs with regard to broadcast:

• In all Industrial Ethernet CPs the broadcast messages are filtered out as high priority upon receipt. All messages that are not messages that can be used (e.g. ARP Request) are discarded immediately. This prevents the negative influence of broadcast messages on the other connections.
• Modules that cannot receive any broadcast messages, can however be used to send broadcast messages into the network.

To ensure a synchronous sending of a message to multiple station, the connection option "Multicast" has been introduced. By means of a definition (via configuration as of SIMATIC STEP7/ NCM V5.1 + SP2), reserved Multicast partners are enabled to send a message directed to a certain number of communication partners.

Behavior of the communications processor:

The communications processor is usually also locked for multicast messages. One exception is the time. If a multicast group is now activated in the configuration, it is also activated in the LAN controller. Only this one particular group is activated and the communications processor continues to be impervious to broadcast messages from the network. Each multicast group configured must be noted in the LAN controller.
This is why multicast is always the better solution when messages are to be sent to groups of partner stations.

• You can configure up to 48 multicast groups in one communications processor.
• The data length is limited to 2048 bytes as for UDP.
• The communications processor continues to be impervious to broadcast loads.
• Requirement is of course that all partner stations also support multicast.
• The messages are sent without any security mechanism (acknowledgment).

The messages are sent without acknowledgment, because there is no provision for acknowledgments in the UDP protocol. An acknowledgment could cause problems if, for example, a message is sent to 100 partners, then 100 acknowledgments (one per partner) would arrive at the same time. Such a surge of data could not be evaluated by the sender module.

Configuring multicast connections:

1. Creating a connection in NETPRO:
   As usual the multicast connection can be created using the standard dialog. A UDP connection is selected as Connection Type and "All multicast stations" as Connection Partner (see figure below):

Figure 1: Integration of a new connection

2. Filling in the "Addresses" dialog:
   In this dialog, the multicast range is chosen whereby the IP addresses 224.0.1.0 through 239.255.255.255 are reserved for multicast circuits. This address range is recognized by every block as a multicast frame and is not used for communication via standard communication connections.
   The local and remote ports can be assigned unlimitedly, as small port numbers are reserved for special tasks (well known ports). When the first multicast circuit is created, as a default the circuit 224.0.1.0 is offered.

Fig. 2: Properties of the UDP connection

3. What a connection created in NETPRO should look like:
   In NETPRO, a connection is displayed with the common procedure. It can be distinguished from a common transport connection by the field "Partner". If it is a multicast connection, "All Multicast Nodes" is entered.

  IE-CPs_Multicast_03_e.gif ( 17 KB )  

Recommendations for project development:

To ensure smooth communication, the following develompent instructions must be observed:

• Local and remote port of a multicast connection must be identical.
  The multicast circuits that are configured are registered in the LAN controller. This way, the incoming telegrams are not ignored, but processed by the CP.
  As soon as the telegrams have passed the LAN controller, the only relevant information left is the number of the port in use!
  
  Example: 
  Between two stations, exactly one multicast connection is configured.
  
  
  

  	Station: 1	Station: 2
  IP address	140.90.36.1	140.90.37.1
  MC circuit	224.0.1.0	224.0.1.0
  local port	2000	8000
  remote port	8000	8000

  Case 1: Station 1 sends data from the multicast circuit 224.0.1.0.
  This works, as the remote port 8000 of station 1 corresponds to the local port 8000 of Station 2
  
  Case 2: Station 2 sends data to the multicast circuit 224.0.1.0.
  The telegram cannot be received by Station 1, although it is a node in the multicast circuit, because the local port 2000 of Station 2 is not identical to the remote port 8000 of Station 1.
  
  To manage both cases, remote and local ports must always be identical.

   

• Special issue about the choice of multicast addresses
  In this example, a multicast telegram is to be sent from Station 1 to Station 2 as well.
  
  
  

  	Station: 1	Station: 2	Station: 3
  IP-address	140.90.36.1	140.90.37.1	140.90.38.1
  MC circuit	224.0.1.0	224.0.1.0	225.0.1.0
  local port	8000	8000	8000
  remote port	8000	8000	8000

  As all port numbers are identical in this case, a bidirectional data transfer between these two stations is possible without restrictions.
  But, interesting enough, this telegram is also received by Station 3. At first sight, this is not supposed to work, as Station 3 is no node in circuit 224.0.1.0.
  To understand this, you have to look at the mechanism of building the multicast MAC addresses:
  
  Display of the multicast addresses on the LAN:
  
  For multicast, the last 3 bytes of the IP address are copied to the last 3 bytes of the MAC address 01.00.5E.00.00.00. This is the MAC address which is registered for the various circuits in the LAN controllers. This way you ensure that the telegrams can pass the respective LAN controller. Additionally, the highest bit of the first copied byte of the address is ignored and is always 0.
  The MAC address that has been created is also visible as destination address in the telegrams in the LAN.
  
  Result:
  The following three multicast circuits all lead to the same entry in the LAN controller, resp. to the same MAC address:
  224.0.1.0
  225.0.1.0
  226.128.1.0
  MAC address = 01.00.5E.00.01.00

  This shows that different multicast IP addresses actually represent the same multicast circuit. You should observe this when assigning multicast circuits to avoid unwanted messages on unaddressed stations.
  This is an instruction that follows valid RFC (internet standard).

Blocks that support multicast connections:

No.	First delivery	Block	Type of block	Firmware version
1	Dec. 2002	6GK7 343-1EX10-0XE0	CP 343-1	starting from Version V2.1
2	Apr. 2002	6GK7 343-1EX11-0XE0	CP 343-1	starting from Version V2.0.x
3	Dec. 2002	6GK7 343-1EX20-0XE0	CP 343-1	starting from Version V1.0
4	Aug. 2001	6GK7 443-1EX10-0XE0	CP 443-1	starting from Version V2.0.31
5	Aug. 2001	6GK7 443-1EX11-0XE0	CP 443-1	starting from Version V2.0.31
6	May 2004	6GK7 443-1EX40-0XE0	CP 443-1 Advanced	starting from Version V1.0
7	Dec. 2001	6GK7 343-1GX00-0XE0	CP 343-1 IT	starting from Version V2.0.x
8	March 2002	6GK7 343-1GX11-0XE0	CP 343-1 IT	starting from Version V2.0.x
9	Feb. 2004	6GK7 343-1GX20-0XE0	CP 343-1 IT	starting from Version V1.0
10	Dec. 2001	6GK7 443-1GX10-0XE0	CP 443-1 IT	starting from Version V2.0.x
11	Dec. 2001	6GK7 443-1GX11-0XE0	CP 443-1 IT	starting from Version V2.0.x
12	Nov. 2001	6GK7 343-1HX00-0XE0	CP 343-1 PN	starting from Version V1.0.x

Table 1: Blocks overview

Keywords:
network protocol, Gateway, TCP/IP, Frame