brescia@CCV.BBN.COM.UUCP (04/03/87)
Do you have a concrete suggestion on how to manage the multicast group? How about the following (summary: manage by czar). The goal is to completely eliminate use of the broadcast address. TCP/IP implementations may be overusing this feature, between ARP, RWHO, etc. 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. Call the first group <ether-link> and the second group <ip-port>. These become well know, and wired in the programs, much like 255.255.255.255.255.255 is today. The first group, <ether-link>, is the contact address for all hosts which handle 'broadcast' for a particular ether link (message type). 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). The second group, <ip-port> is the set of addresses for IP broadcast protocols, and subdivided into one byte of IP protocol (e.g. UDP, 17), and one byte of well-known-port (e.g. RWHO, 550 (oops, well, you get the idea). While this idea is a bit half-baked, it should serve to move host and gateway impementations to independence from broadcasts.
deering@PESCADERO.STANFORD.EDU.UUCP (04/04/87)
The goal is to completely eliminate use of the broadcast address. TCP/IP
implementations may be overusing this feature, between ARP, RWHO, etc.
Hear! hear! At the moment, if you want to use IP on an Ethernet, you
must listen to Ethernet broadcasts, for the sake of ARP. Here at
Stanford, that means you get to receive and discard packets broadcast
for RWho, Reverse ARP, RIP, TFTP, Time, Domain Name lookups, Pup name
lookups, BOOTP, ND, Pup routing, XNS routing,... and whatever new
broadcast protocol was invented today.
In RFC988, I propose a way to manage multicast addresses for IP-based
applications. I suggest that the number czar should allocate well-known
IP multicast address, rather than Ethernet multicast addresses, and that
there should be a standard mapping from IP to local network multicast
addresses for each type of local network.
As for ARP, I think ARP-for-IP should use a different Ethernet multicast
address than ARP-for-Chaos or ARP-for-whatever, even though they use the
same Ether-type. And, of course, Reverse ARP should use different
addresses than ARP.
To phase in multicast-based ARP, you could (during the phase-in period)
listen to both the broadcast address and the multicast address. When
sending an ARP request, use the multicast address first, then broadcast
if you don't get a reply.
Karen Lam of BBN has extended the 4.3bsd UNIX IP code to support
RFC988-style multicasting, on top of which I have implemented a
multicast version of Berkeley's rwho daemon. This code (both Karen's
and mine) is running successfully at a couple of test sites and I hope
it will soon be made available for wider distribution to those who wish
to experiment with IP multicasting.
I would appreciate any feedback on RFC988. I would also like to hear
of any other work going on in the area of internetwork multicasting.
In particular, is the x3s33 committee considering internetwork multicast
addressing and routing?
Steve Deeringhwb@MCR.UMICH.EDU.UUCP (04/05/87)
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. -- Hans-Werner
DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP (04/06/87)
As I think some people have already tried to state, ** There is now standard for multicast addressing **. The only thing the blue Ethernet book says is that multicast addresses exist and here's what they look like. It does not say what functinality implementors of hardware interfaces should provide. It doesn't give any hints if implementations should allow filters on the top 24 bits, or the bottom 8 bits, or anything. Therefore, what Interlan does is different than what 3Com does which is different than what DEC does which is different.... Please don't go inventing ideas that work well on only one type of interface. I also suggest people separate network level packets like ARP from protocol like packets like RWHO, TFTP and Time. They are very different and you may find that the "solution" for each is different. I'm against adding IP-specific things to the handling of ARP. ARP is blatently non-IP specific (non-anything specific for that matter) and I fear putting in non-modular hooks between the layers will burden multi-protocol operatins systems at the expense of single-protocol systems. Additionally, it isn't easy to extend ARP to be Ethernet specific (e.g., have ARP-for-IP and ARP-for-CHAOS) since ARP doesn't know anything about Ethernet nor about IP and wouldn't know what to do if you told it. I conjecture that if there are excessive ARP packets on your cable, than one of two things is happening: Some station's cache isn't big enough (simple enough to solve), or some station isn't responding. XNS, Pup and Chaos routing present a constant (though supposedly low frequency) stream of broadcast packets. Multicast would probably be a good thing here, if we could figure out how multicast should work. RWho in my opinion should be flushed. It is an unsolicited user-level protocol. Time is (or should be) a solicited user-level protocol. I'd be surprised if it really caused excessive burden. Domain Name lookups are broadcast? New one on me. How often does BOOTP really happen? If the BOOTP protocol isn't able to latch on to the server address directly, I suggest the BOOTP protocol be changed to do so. A PDP-11 netboot protocol I wrote 5 years ago did indeed broadcast the initial request and then latched onto the server. Everybody is burdened with one, perhaps two, packets and then never hears from the booter again.