Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!PESCADERO.STANFORD.EDU!deering From: deering@PESCADERO.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: multicast on ether Message-ID: <87.04.05.1509.510@pescadero.stanford.edu> Date: Sun, 5-Apr-87 18:09:00 EST Article-I.D.: pescader.87.04.05.1509.510 Posted: Sun Apr 5 18:09:00 1987 Date-Received: Mon, 6-Apr-87 03:39:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 60 Approved: tcp-ip@sri-nic.arpa From Hans-Werner Braun : 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 .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