[evla-sw-discuss] Multicast address

[James Robnett]

    I'm resending an email I sent a few months ago,
the first part explains why certain multicast ranges
should be avoided, the second part suggests an
addressing scheme.

    This is primarily an EVLA (at least in the short
term) concern.  I was just talking with Hichem and
agreed we should re-address (your choice on pun or not)
this.

    Can we bring it up briefly at the 9am meeting.

James

-----------------------------------------------------------
    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 receivers.
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 24th bit
in the remaining octets 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
224.1.2.2 could be NM, EVLA correlator non-monitor
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 intra-site 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 x.0.y.z or
x.128.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 or (01:00:53:00:00:01)


     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 (or 01:00:5e:00:00:01)

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