Re: multicast on ether

John Gilmore (hoptoad.UUCP!
Sat, 4 Apr 87 18:18:43 PST

brescia@CCV.BBN.COM (Mike Brescia) writes:
> The goal is to completely eliminate use of the broadcast address. TCP/IP
> implementations may be overusing this feature, between ARP, RWHO, etc.

I heartily agree with this goal. While working at Sun I noticed a
large number of broadcast packets passing around, and this caused a few
amusing problems, especially when these packets were addressed to
user-mode daemons which swapped in over the ether. Note, however, that
the current volume of broadcasts has the worst impact on hosts with old
or badly designed Ethernet interfaces, e.g. 3Com boards with one or two
receive buffers. These interfaces typically don't filter multicast
packets anyway -- you can set a bit saying "receive multicast" or "toss
multicast" and no more. Moving broadcast applications to multicast
will only benefit hosts with more modern, e.g. AMD or Intel VLSI,

> Go to the ethernet number czar and get two (2) groups of 65536 (2^^16)
> multicast addresses. By that, I mean the high order 32 bits are assigned by
> the czar, and the low 16 bits are ours to play with.

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.

> Thus ARP,
> instead of polluting all the hosts in the net, would send to the address
> <ether-link>.8.6 (0x0806 is the number assigned to the address resolution
> protocol).

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. In the case of ARP, it would be better if the multicast
address included the low byte of the Internet address you're looking
for, so that hosts which don't know anything about that Internet
address could ignore the packet in hardware. Note that most machines
on one Ethernet will have the same high 3 bytes of their Internet
address, so supplying the whole thing would be overkill.

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). This begs the question of how the sending kernel decides how
to send the ARP Request packet, but we're designing on the fly here
anyway. Of course, a receiving kernel that handles multicasts should
also accept the old broadcast packets for compatability.

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