[evla-sw-discuss] Multicast address

[James Robnett]

    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