jch@RISCI.TN.CORNELL.EDU (Jeffrey C Honig) (01/06/90)
Below is a copy of the RFE (Request for Enhancement) I submitted to Sun asking them to support IP Multicasting. I'd like to encourage other people to do the same, and not just with Sun, but with other vendors too. For most BSD 4.3 based systems the code is already available so implementation should not be too difficult from a technical aspect. The hard part is convincing them that we want it. Jeff The purpose of this RFE is to request that SunOS support IP multicast communications and Internet Group Management Protocol (IGMP) as soon as possible. IP Multicasting and IGMP, as defined in [RFC1112], are both "recommended standard" internet protocols for use in the DARPA Internet. IP Multicasting is listed as a feature that "SHOULD" be implemented and IGMP is a listed as a feature that "MAY" be implemented in [RFC1122]. Whenever multicast capability has been made available on local area networks, applications which exploited and benefited from it have rapidly evolved. Since the Internet is moving toward an environment of high-speed circuits, and high-performance hosts, we can expect an increasing demand for real-time interactive and transaction-style applications not just on local networks but across the nation. IP multicasting provides many benefits. On the local network level it reduces the amount of broadcast traffic a host must process. A host need only subscribe to the multicast groups it desires. On a regional and national level multicasting will reduce the amount of traffic required to "flood" information to distributed applications in the internet. One protocol to support wide-area multicasting already exists, more sophisticated ones are under currently under development, support is already committed by some major router vendors. Widely available support for IP multicasting in SunOS would greatly benefit this development. One major use for IP multicasting is the Open Shortest Path First (OSPF) designed by the IETF and submitted as a "proposed protocol" for Internet routing. OSPF is a much more robust interior routing protocol than RIP and is a major candidate to be the "recommended standard" interior routing protocol for the Internet. OSPF was designed to use IP multicasting instead of IP broadcasting to reduce the broadcast traffic that must be handled by non-participating hosts. Suns are the Unix system of choice for use as high speed routers. Their ability to support IP multicasting and hence OSPF will be crucial in their continuing to be so. The Internet of the near future will not be able to survive without a more robust interior routing protocol than RIP. Sun has proven itself to be a leader in workstation field, especially in wide-spread use of networking. Implementation of IP multicasting would help maintain this leadership. RFC1112: Deering, S. "Host Extensions for IP Multicasting". August, 1989. RFC1122 Internet Engineering Task Force. "Requirements for Internet Hosts -- Communication Layers". October 1989.
casey@gauss.llnl.gov (Casey Leedom) (01/08/90)
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
cire@CISCO.COM (01/08/90)
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
andrew@dtg.nsc.com (Lord Snooty @ The Giant Poisoned Electric Head ) (01/08/90)
Why is it that (unlike Ethernet), IBM Token Ring products do not support multicasting, despite the fact that the protocol (i.e. Group Addresses) exists already? No vendor (TI or IBM) support more than one Group Address! -- ........................................................................... Andrew Palfreyman andrew@dtg.nsc.com Albania before April!
hwajin@wrs.wrs.com (Hwa Jin Bae) (01/09/90)
While newer ethernet boards designed around recent chip sets such as LANCE and National's NIC (DP8390) family do provide ability to program your multicast addresses this is not yet available every where. Even the boards built around such advanced chips do not provide direct access to the chip registers (e.g. some of cmc and excelan boards) thus making the multicast address programming less than straight forward at the driver level. The complexity involved shouldn't be ignored either. A well maintained ARP cache, in my opinion, is a good compromise. Besides, in the real world most people do not forward random broadcast packets via gateways, thereby restricting the local broadcast traffic. The only big problem I can see is the occasional broadcast storms caused by early 4.2bsd derived systems which sent out ARP's for certain unrecognized broadcast IP addresses, but this bug is quickly disapearing. hwajin
casey@gauss.llnl.gov (Casey Leedom) (01/09/90)
| From: cire@CISCO.COM | | Except for the problems with Casey's proposal it is fine. :-) Yes, I know that it's really too late to get rid of Ethernet broadcasts, but I had to bring it up because too many people think that Ethernet broadcasts are the Right Way to do things (for instance all the &^*%&*^ groady broadcast license schemes floating around). | 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. "Lazy" refers to Lazy Evaluation which is an algorithm technique that can often work wonders for theoretically large polynomial or even non-polynomial problems. The basic idea is that instead of always trying to be prepared at every stage of an algorithm with every possible value one might need to compute the next stage of the algorithm, you don't pre- compute anything. Instead you fault when you need a value that hasn't been compute yet. It's called Lazy Evaluation because of the analogy of a Lazy Person not doing anything until it's needed. In this particular case I'm comparing the non-Lazy Hello type Address Resolution Protocols to the Lazy Ethernet/IP Address Resolution Protocol. In the ARPs of the former type, every station constantly screams its Ethernet/Network address pairing to the entire net to make sure everyone knows how to get to it. This technique doesn't scale up well at all for larger networks. Unfortunately it's used by a lot of network protocols. The IP/Ethernet ARP on the other hand scales up very nicely. Thus, I essentially agree with you that there's not a lot to be gained in converting IP/Ethernet ARP to Ethernet multicasting. But I still hate the use of Ethernet broadcasts. I just don't think they ever should have existed, or their use should have been specifically described for use in an Ethernet level Control Message Protocol (and even then that should simply have been yet another multicast address; thus I can't find any good reason to support Ethernet broadcasts). Casey
cire@CISCO.COM (cire|eric) (01/10/90)
Well its not that Token Ring doesn't support multicasting ... it does. It just does so in a different way. The Group Address is the form that the Ether community is used to thinking as Multicasting. However as you pointed out there is only one of those in the current implementations. The useable form of multicasting though is the Functional address. These are bit significant addresses. A Token Ring interface can have upto 31 of these assigned. For example, if I had an interface assigned the functional address c000.0080.1000, this interface would receive packets with the destination addresses that had either of those bits set. ie. c000.0080.0000 or c000.0000.1000 or c000.0080.1000 or c000.07f0.d000 etc. This provides essentially a superset of the ethernet multicast capability. The biggest dissadvantage however is the small address space. However you don't have to convince the various hardware vendors to implement n multicast address slots. Which in practice is as much as a limitation. Another argument is that they are not universal and thus will lead to address collisions. I maintain that this can ge dealt with via appropriate naming authority mechanisms. -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 Token Ring Development cisco Systems - engineering Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941
sylvain@burden.chorus.fr (Sylvain Langlois) (01/10/90)
In article <819@wrs.wrs.com> hwajin@wrs.wrs.com (Hwa Jin Bae) writes:
Hwa Jin> While newer ethernet boards designed around recent chip sets such
Hwa Jin> as LANCE and National's NIC (DP8390) family do provide
Hwa Jin> ability to program your multicast addresses this is not
Hwa Jin> yet available every where.
Hwa Jin> Even the boards built around such advanced chips do not provide
Hwa Jin> direct access to the chip registers (e.g. some of cmc and
Hwa Jin> excelan boards) thus making the multicast address
Hwa Jin> programming less than straight forward at the driver level.
I'm trying to bring up Multicast IP (V 1.2 of june 89) on a Sun 3/80
running sun OS 4.0.3 ...
It seems that the Lance Ethernet driver has been changed a lot for
the 3/80 (numerous references to this type of architecture in the
sources!). As far as I understand, Mutlicast IP, as distributed by ftp
has not been ported on such a box. I've tried to hack around between
Steve's sources and Sun Kernel sources but I still cannot boot: it
seems that me IP layer is totally dead (init process cannot launch
ypbind for instance!).
Has anyone already faced these problems? Is it planned that a next
release of Multicast IP will be running on this particular configuration?
Sylvain
--
----------------
Sylvain Langlois "Dogmatic attachement to the supposed merits
(sylvain@chorus.fr) of a particular structure hinders the search
(sylvain%chorus.fr@mcsun.EU.net) of an appropriate structure" (Robert Fripp)