Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!hoptoad.UUCP!gnu From: gnu@hoptoad.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: multicast on ether Message-ID: <8704050218.AA22481@hoptoad.uucp> Date: Sat, 4-Apr-87 21:18:43 EST Article-I.D.: hoptoad.8704050218.AA22481 Posted: Sat Apr 4 21:18:43 1987 Date-Received: Sun, 5-Apr-87 14:48:32 EST References: <8704030214.a001249@Huey.UDEL.EDU> <8704031719.AA28257@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 Approved: tcp-ip@sri-nic.arpa 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, interfaces. > 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 > .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 .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.