Path: utzoo!utgpu!watserv1!watmath!att!mcdchg!laidbak!ism.isc.com!uunet!lll-winken!sun-barr!newstop!jaytee!deitrick!ckollars From: ckollars@deitrick.East.Sun.COM (Chuck Kollars - DSGG Technical Marketing - Boston) Newsgroups: comp.dcom.lans Subject: Re: How many physical addresses belong to 1 Ethernet station? Message-ID: <2988@jaytee.East.Sun.COM> Date: 19 Oct 90 18:42:27 GMT References: <1990Oct18.172918.24929@forwiss.uni-passau.de> Sender: news@jaytee.East.Sun.COM Reply-To: ckollars@east.sun.com (Chuck Kollars - DSGG Technical Marketing - Boston) Organization: Sun Microsystems, Billerica MA Lines: 65 In article <1990Oct18.172918.24929@forwiss.uni-passau.de> grass@unipas.fmi.uni-passau.de (Grass) writes: >As we found from the CSMA/CD ANSI/IEEE standard, there exists a *set* of >individual/multicast/broadcast addresses for each single station. Addresses >are 48 bits wide and the first bit (LSB) distinguishes individual (0) and >group (1) addresses. Group addresses may be multicast addresses (specified >by higher protocol layers!) or a particular broadcast address. This unique >broadcast address has to be predefined for the network and must be known by >every station. Usually 11...1 is chosen, but the standard leaves it open to >choose another address pattern. In practice, every station has one individual address, one broadcast address, and zero or more multicast addresses. The individual address is usually read from an internal PROM and should be world-unique. (The first 24 bits are allocated to "vendors" by the IEEE, and each "vendor" then assigns the second 24 bits. Rather like the Universal Price Codes you see at the grocery store in the US, where the first five digits encode "manufacturer" and the second five digits encode "product".) In practice the broadcast address on all Ethernet networks is always all ones. The zero or more multicast addresses recognized will be enabled by higher layer software--the startup default is that no multicast addresses will be recognized. To date the multicast capability is not used very much. Many ethernet hardware vendors use one multicast address to exchange "private" management information. You may see more use of Ethernet multicast addresses in the future: 1) The newest version of Apple's EtherTalk uses one for distributing routing information. 2) The NetBIOS-over-TCP/IP protocol (RFC 1001) may use a few for more efficient group distribution. 3) IP multicast, which is not yet widely deployed, probably uses one. 4) The VMTP protocol probably uses some. I don't know of any "standard/portable" applications program interface to the multicast address capability, which may be why the feature is used by so few application programs. >This sounds that at least group address recognition is done by software: all >messages with its first destination address bit set are received by every >station, transferred to some place in memory and examined by some software >routines. If the destination address does not match with the actual set of >active group addresses the whole message is discarded from memory. What a >waste of cpu/memory/bus ressources! The standard says what to do, but not how to do it. Fortunately available silicon is smarter than your worst-cast scenario. The hardware does first-pass filtering of received multicast packets, and passes only packets that are "probably" for this station up to software. The Intel 82586 chip for example hashes all incoming multicast addresses into one of 64 internal buckets. Each bucket can be individually enabled by software. If the incoming multicast address doesn't hash to an enabled bucket, the packet is silently discarded. The chip's interface to this functionality is friendly--software specifies the multicast address of interest and the chip figures out which bucket to enable. >To save up these ressources the Ethernet controller hardware (chip?) could >be provided with *all* addresses it shall respond to. Address decoding is >done by hardware. Only messages with according destination addresses are >passed. Although a chip could in theory filter *all* incoming multicast addresses, doing so would make the chip significantly more complex. As you point out, having all filtering done in software would degrade performance. So a combintion solution seems called for--make the chip do the first-pass filtering and discard "most" unwanted multicast packets, and let the software do the second-pass filtering to render an "exact" decision about whether or not to examine each packet. --- chuck kollars DSGG Technical Marketing, Sun's Boston Development Center