Re: multicast on ether


Steve Deering (deering@pescadero.stanford.edu)
5 Apr 1987 15:09-PST


    From Hans-Werner Braun <hwb@MCR.UMICH.EDU>:

    You have to watch out, though. Most interfaces I know of only support a
    limited set of multicast addresses (DEQNAs, I think, just have a table
    for fourteen or so addresses in general). You don't really want to end
    up having to listen to each and every packet in a multiprotocol gateway,
    just because your multicast address table in the EThernet device
    overflows.

You don't have to listen to every packet, just every *multicast* packet,
when your multicast filter is exceeded. The DEQNA and other interfaces
provide such a reception mode. If we are just replacing broadcast packets
with multicast packets, listening to all multicasts is no worse than the
current situation of having to listen to all broadcasts. However, using
multicast addresses is much better for those hosts that *are* able to filter
multicasts adequately. Besides, it is not unreasonable to expect a
sophisticated multiprotocol gateway to have a sophisticated Ethernet
interface. The important thing is to stop sending unwanted packets to
non-gateway hosts.

I agree that we should conserve multicast addresses by looking out for
situations in which more than one application may reasonably use the same
multicast address, but I don't think we should be bound by the limitations
of current hardware. Once there is a demand for good multicast filtering,
the manufacturers will improve their products.

    From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)

    It might be worth looking at the filtering algorithms in the common
    Ethernet chips before figuring out the configuration of the multicast
    numbers. Typically they hash the addresses down to ~6 bits and the
    user supplies a 64-bit filter mask. We should try to match the number
    assignment to the hash functions.

That's a good idea if they all use the same hash function. Both the AMD
7990 and the Intel 82586 send incoming multicast addresses though their
CRC generators and take 6 bits of the result as a hash value, as you
described. From the documents I have, it is not obvious that they
both use the same 6 bits of the CRC in the same order. (Can anyone say
for sure?) Are there other hashing functions in use in other interfaces?

    Virtually every host has to implement ARP so they will all be listening
    on <ether-link>.8.6 and there would be no benefit over just
    broadcasting.

Hosts that aren't running IP aren't interested in ARP-for-IP packets.
Some of us share Ethernets with hosts running Pup, Chaos, XNS, or ISO
protocols. We don't like their broadcasts and they don't like ours.

    If a scheme like this gets worked out, I suggest that we allocate a bit
    in the ARP packets for "I listen to multicast for IP broadcasts", to
    tell a sending kernel which scheme to use (like the trailer protocol
    stuff).

I don't think any new bits are needed. Just send your ARP requests to
the multicast address, and if you don't get an answer, try the broadcast
address.

Steve Deering



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:47 GMT