Greetings -
I wanted to take a few minutes and set down some information on Unicast vs. Multicast and how an ECG implements Multicast in the current versions and plans for upgrades.
Most people are aware of the difference between Unicast and Broadcast. Even though you don't think about Broadcast you use it everyday. But 98% of the time you use Unicast. Broadcast is being used behind the scenes by your computer to do Address Resolution Protocol (ARP) and other similar protocols. Your computer uses Unicast to talk to Name Servers, Web Servers, Mail Servers, printers and so forth. If you talk to a computer by name (www.j1sys.com) your computer first resolves it to an IP Address. If that IP Address is on your LAN the system will then use ARP to translate the IP Address to a MAC Address. Then the Ethernet packets are sent using Unicast to the destination MAC Address. If the IP Address is not on your LAN the system will determine the appropriate gateway and then use ARP (or its ARP cache) to determine the gateway's MAC Address. Then the Ethernet packets are sent using Unicast to the gateway's MAC Address.
Multicast is a hybrid of these two modes. Multicast uses a special block of IP Addresses (224.0.0.0 - 239.255.255.255). There are some reserved and special use IP Addresses in this block but they aren't important to our discussion.
A Multicast packet does not contain the MAC Address of a destination computer, it contains a MAC address that contains part of the IP address. This identifies what group this packet belongs to and any computer that is listening for that particular MAC Address can then receive the packet and handle it appropriately.
Most simple Ethernet switches (cheap) will repeat the Multicast packets to all of its outputs. There is a special protocol called Internet Group Management Protocol (IGMP). There are a few variations to the protocol that have evolved over the years. IGMP allows computers to 'join' a group and then IGMP aware switches can filter the Multicast packets and only send them out the lines that contain one or more members.
So what does this mean to you as a user of E1.31 and EthConGateway?
The E1.31 specification calls for the use of Multicast and sets the rules for mapping Universe numbers to Multicast group numbers. However the specification also allows for the use of Unicast but requires that the user configure the destination based on their own knowledge and the specification does not include any set way for discovering the IP Addresses (like Art-Net II does).
If you think of E1.31 as a replacement/upgrade to standard RS-485 DMX that may be connected to a large number of individual lights, each maybe consuming 8 slots, all sharing one Universe then Multicast is a logical way to go. If, however, like a usual EthConGateway topology the entire purpose of the E1.31 is to transport one or more entire universes to one ECG for it to retransmit them out RS-485 serial lines it is, in our opinion, more logical to use Unicast to deliver the packets. Each ECG that you install on your network must have a unique static IP Address so that you can contact the HTTP server to control and monitor it. So to use that IP Address as the destination of your E1.31 packets CAN reduce the load on your network when used with inexpensive switches which do not support IGMP.
As required by the specifications ECGs will accept Unicast packets.
Release v1.1.0 and v1.3.0 implement a very simple 'promiscuous' Multicast receiver. The protocol stack will accept ALL Multicast packets and queue them up for the E1.31 Server. The E1.31 Server will read through all the traffic and discard any Universe data that it is not interested in. This does add a small load on the server. Release v1.1.0 and v1.3.0 do NOT implement any form of IGMP and so if you have an IGMP aware switch it will not let it know that it is interested in receiving any groups and they will, therefore, not reach the ECG (unless you can set your switch to repeat all multicast out all lines anyway).
We are working on a filtered version of a Multicast receiver where the Ethernet co-processor will evaluate each Multicast packet and discard any that the E1.31 Server has not expressed an interest in. This will reduce the work load on the E1.31 Server and keep the queues from being filled with unneeded data. We hoped to have this working for v1.3.0 but expect to have it in v1.3.1 or v1.3.2 at the latest.
Then we will need to implement IGMP in the TCP/IP stack (Microchip did not provide that protocol) and allow for full participation in a robust Multicast environment. We will complete this as soon as practical and include it in a future release.
So, we just wanted to set this information down so everyone can know the parameters under which they work. Again, in our opinion, Unicast is the preferred method for moving large amounts of data from point A to point B with the least amount of effort and we recommend using Unicast for ECG communication. However, if used with an inexpensive promiscuous switch, multicast will be received and decoded properly but at perhaps a small cost in throughput and server load. As we improve our Multicast implementation these differences may become less apparent.
-Ed
I wanted to take a few minutes and set down some information on Unicast vs. Multicast and how an ECG implements Multicast in the current versions and plans for upgrades.
Most people are aware of the difference between Unicast and Broadcast. Even though you don't think about Broadcast you use it everyday. But 98% of the time you use Unicast. Broadcast is being used behind the scenes by your computer to do Address Resolution Protocol (ARP) and other similar protocols. Your computer uses Unicast to talk to Name Servers, Web Servers, Mail Servers, printers and so forth. If you talk to a computer by name (www.j1sys.com) your computer first resolves it to an IP Address. If that IP Address is on your LAN the system will then use ARP to translate the IP Address to a MAC Address. Then the Ethernet packets are sent using Unicast to the destination MAC Address. If the IP Address is not on your LAN the system will determine the appropriate gateway and then use ARP (or its ARP cache) to determine the gateway's MAC Address. Then the Ethernet packets are sent using Unicast to the gateway's MAC Address.
Multicast is a hybrid of these two modes. Multicast uses a special block of IP Addresses (224.0.0.0 - 239.255.255.255). There are some reserved and special use IP Addresses in this block but they aren't important to our discussion.
A Multicast packet does not contain the MAC Address of a destination computer, it contains a MAC address that contains part of the IP address. This identifies what group this packet belongs to and any computer that is listening for that particular MAC Address can then receive the packet and handle it appropriately.
Most simple Ethernet switches (cheap) will repeat the Multicast packets to all of its outputs. There is a special protocol called Internet Group Management Protocol (IGMP). There are a few variations to the protocol that have evolved over the years. IGMP allows computers to 'join' a group and then IGMP aware switches can filter the Multicast packets and only send them out the lines that contain one or more members.
So what does this mean to you as a user of E1.31 and EthConGateway?
The E1.31 specification calls for the use of Multicast and sets the rules for mapping Universe numbers to Multicast group numbers. However the specification also allows for the use of Unicast but requires that the user configure the destination based on their own knowledge and the specification does not include any set way for discovering the IP Addresses (like Art-Net II does).
If you think of E1.31 as a replacement/upgrade to standard RS-485 DMX that may be connected to a large number of individual lights, each maybe consuming 8 slots, all sharing one Universe then Multicast is a logical way to go. If, however, like a usual EthConGateway topology the entire purpose of the E1.31 is to transport one or more entire universes to one ECG for it to retransmit them out RS-485 serial lines it is, in our opinion, more logical to use Unicast to deliver the packets. Each ECG that you install on your network must have a unique static IP Address so that you can contact the HTTP server to control and monitor it. So to use that IP Address as the destination of your E1.31 packets CAN reduce the load on your network when used with inexpensive switches which do not support IGMP.
As required by the specifications ECGs will accept Unicast packets.
Release v1.1.0 and v1.3.0 implement a very simple 'promiscuous' Multicast receiver. The protocol stack will accept ALL Multicast packets and queue them up for the E1.31 Server. The E1.31 Server will read through all the traffic and discard any Universe data that it is not interested in. This does add a small load on the server. Release v1.1.0 and v1.3.0 do NOT implement any form of IGMP and so if you have an IGMP aware switch it will not let it know that it is interested in receiving any groups and they will, therefore, not reach the ECG (unless you can set your switch to repeat all multicast out all lines anyway).
We are working on a filtered version of a Multicast receiver where the Ethernet co-processor will evaluate each Multicast packet and discard any that the E1.31 Server has not expressed an interest in. This will reduce the work load on the E1.31 Server and keep the queues from being filled with unneeded data. We hoped to have this working for v1.3.0 but expect to have it in v1.3.1 or v1.3.2 at the latest.
Then we will need to implement IGMP in the TCP/IP stack (Microchip did not provide that protocol) and allow for full participation in a robust Multicast environment. We will complete this as soon as practical and include it in a future release.
So, we just wanted to set this information down so everyone can know the parameters under which they work. Again, in our opinion, Unicast is the preferred method for moving large amounts of data from point A to point B with the least amount of effort and we recommend using Unicast for ECG communication. However, if used with an inexpensive promiscuous switch, multicast will be received and decoded properly but at perhaps a small cost in throughput and server load. As we improve our Multicast implementation these differences may become less apparent.
-Ed
