Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!tut.cis.ohio-state.edu!ucbvax!CISCO.COM!cire From: cire@CISCO.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: IP Multicasting in SunOS Message-ID: <9001080653.AA24474@ucbvax.Berkeley.EDU> Date: 8 Jan 90 03:24:36 GMT References: <43507@lll-winken.LLNL.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 95 Except for the problems with Casey's proposal it is fine. :-) In this discussion I'm using the popular Ethernet meaning of 'multicast'. That is a multicast addresses is an Ethernet/802.3 address that is non-specific and non-broadcast. Prob 1: Not all ethernet controllers implement multicast addresses. Those that do implement only a finite number. Prob 2: There is potentially an unbounded number of protocols that would need to use a multicast address. But there is only a finite number of multicast addresses available in a given ethernet controller. These problems can be dealt with in a number of ways. 1) Broadcast must continue to be used to take care of those controllers that don't use multicast. This is the final safety net that insures things keep working. 2) It makes good sense to provide a multicast facility where available. This facility could be used by ARP, IP Multicast, etc. The facility must be able to handle running out of resources. Namely multicast addr slots. 3) Running out of slots can be handled in two ways (probably more but two here). If the controller supports accept all multicast addresses that works. (This type of controller typically does not have any multicast slots). For those controllers that have multicast slots, a well known multicast address could be defined that is used to catch generic multicast traffic. This is almost the same as broadcast (broadcast multicast) but all hosts wouldn't receive it which would be a good thing. Now a really good question is "Is this additional complexity worth it?" I don't think so. Note that the complexity is only needed if this is implemented fully. That is an arbritrary node with an arbritrary ethernet controller should work. The big problem is that ARP needs to be ubiquitous for IP. All IP nodes need to implement what ever is needed to receive ARP packets. Forcing ARP to change to a multicast only causes problems for a significant number of nodes and is not a good idea. Implementing one or more mechanisms for extended ARP mechanisms (multicast) adds to the complexity for new hosts significantly without necessarily eliminating the ARP broadcast traffic. Given that ARP is a cached protocol (I don't think 'lazy' applies) extending it to use multicast doesn't seem like a big win. Except for ARP storms :-) ARPing doesn't happen that often. IP Multicast on the other hand doesn't have to be ubiquitous. It would be nice but it doesn't have to be. Therefore it is no big deal if the use of multicast addresses in an IP Multicast environment is restricted to those hosts with decently advanced controllers. -c cire|eric "I could have done it in a much more complicated way", said the Red Queen, immensely proud. -- Lewis Carrol, Alice in Wonderland Eric B. Decker cisco Systems - engineering Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 >> Date: 8 Jan 90 00:57:50 GMT >> From: gauss.llnl.gov!casey@lll-winken.llnl.gov (Casey Leedom) >> Organization: Lawrence Livermore National Laboratory >> Subject: Re: IP Multicasting in SunOS >> >> While you're at it, you should hit up IETF to convert ARP from using >> Ethernet broadcasts to using Ethernet multicasts. The fact the ARP >> scales up nicely on large networks (fundamentally because it's a lazy >> evaluation algorithm) doesn't excuse it from the bad etiquette of using >> the Ethernet broadcast address. After all, why should all the non-IP >> stations on an Ethernet be bothered with IP ARP packets? >> >> But this is just an example of the more general complaint of ``Why >> Ethernet broadcasts at all?'' I have yet to hear of a legitimate need for >> Ethernet broadcasts. If the Ethernet Data Link Layer we're more >> sophisticated and supported facilities that required communication beyond >> mere packet delivery, then there might be a need for broadcasts. But as >> it stands now, the only Data Link Layer facility that Ethernet offers is >> delivery of packets. There are no control type messages that might need >> to be delivered to all stations and therefore (as far as I can see) no >> need for Ethernet broadcasts at all. >> >> Abolish Ethernet broadcast! >> >> Casey