[evla-sw-discuss] Multicast address

[Walter Brisken]

Hi James,

Thanks for the details of multicasting that I never knew about.  Since we 
need an address more or less immediately, I'll take 224.2.2.1 for the VLBA 
correlator stuff for now, but changing to a more permanent address will be 
simple if things do end up changing.

-Walter

On Wed, 2 Apr 2008, James Robnett wrote:

>
>   I apologize for not giving this the attention it probably
> deserved (I was on vacation)....
>
>   225.0.0.1 is a bad address to use,  in general addresses of the form 
> x.0.0.y and x.0.1.y, or x.128.0.y and x.128.1.y are bad choices.
>
> IGMP (and CGMP) in general only forward packets to registered recievers. But 
> the multicast groups 224.0.0.x and 224.0.1.x are used to contact all 
> multicast hosts and routers (vaguely equivalent to the broadcast address of 
> x.y.z.255), so they have to go to all switch ports.
>
>   The switch tracks this by destination MCAST MAC address.
>
> Switch ports register not only the hardware MAC of the pc connected but also 
> the MCAST MAC addr for any registered mcast groups connected to that port so 
> it knows whether to forward layer 2 mcast (similar to
> deciding whether to forward layer 2 unicast based on the PC's MAC addr)
>
>   Unfortunately there are 32 addresses that map to the same MAC(1)
>
>   In creating the mapping it ignores the first octet and the 128 bit in the 
> 2nd octet of the destination multicast IP, keeping the last 23 bits of the IP 
> address in the multicast MAC address. So not only do 224.0.0.x and 224.0.1.x 
> get flooded to all ports in a VLAN, but so do 225.0.0.x, 225.0.1.x, 
> 225.128.0.x, 225.128.1.x, 226.0.0.x, etc.
>
>   It'll work if you use those but it causes unnecessary traffic.
>
>   I knew what the more or less 'initial' multicast addresses were
> that EVLA was using but I never got any sort of list so I have no
> clue what's being used in total.
>
>   We should create an EVLA and VLBA address logic and mapping.
> We have a huge range so setting up something like v.x.y.z where
> V is site, x is instrument, y is instrument subsystem and z is
> specific data would make some sense.
>
>   For instance
> 224.1.1.1 could be NM, EVLA, antenna, monitor,
> 224.1.2.1 could be NM, EVLA, correlator, monitor and
> 224.2.2.1 could be NM, VLBA, correlator, monitor.
> 224.2.2.2 could NM, VLBA correlator, data that's not monitor
> 225.3.2.1 could be GB, GBT, correlator, monitor
>
>   Using 224,225 etc will make intrasite forwarding or blocking
> simpler.
>
>   Not saying the above is *the* way to do it but we have
> several million addresses, they might as well make some sense.
>
>   BTW,  the above may be bad in that they collide with well
> known mcast groups, easy enough to shift.  The point is philosophical
> (we should create a mapping) not specific (we should create
> that mapping).
>
> I think this site: http://www.iana.org/assignments/multicast-addresses
> implies that if we avoid address of the form v.0.y.z we're good.
>
> james
> 1)For example:
>
>    224.0.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary
>    low order 23 bits =    000 0000.0000 0000.0000 0001
>    hex equivalent    =     0    0    0    0    0    1
>    result of mapping = 0x0100.5e00.0001
>
>
>    224.128.0.1 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary
>    low order 23 bits =      000 0000.0000 0000.0000 0001
>    hex equivalent    =       0    0    0     0    0    1
>    result of mapping = 0x0100.5e00.0001
>
> ps: CC'ing my group because they should know stuff, Chris and
> Gene in case they have an opinion.
>
>
> Walter Brisken wrote:
>> 
>> Hi EVLA folks,
>> 
>> I'm going to start using a multicast system in the VLBA software correlator 
>> within the AOC.  I plan on using multicast group 225.0.0.1, with ports 
>> starting at 10000.  I'll keep the time-to-live as low as possible.  Do you 
>> know of any potential conflicts with EVLA?  As far as I know, only EVLA 
>> uses multicasting at the moment within the AOC.
>> 
>> Thanks,
>> 
>> Walter
>