Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!hub.ucsb.edu!spectrum.CMC.COM!lars
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.dcom.lans
Subject: Re: How many physical addresses belong to 1 Ethernet station?
Message-ID: <1990Oct24.160422.26990@spectrum.CMC.COM>
Date: 24 Oct 90 16:04:22 GMT
References: <1990Oct18.172918.24929@forwiss.uni-passau.de>
Organization: Rockwell CMC
Lines: 74

In article <1990Oct18.172918.24929@forwiss.uni-passau.de>
	grass@unipas.fmi.uni-passau.de (Grass) writes:
[How does Ethernet address recognition work ?]
>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.
>
>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!

Early Ethernet controllers did exactly that. It is simple, and not
really all that much work. Computers already "waste" a lot of cycles.
Just think of all the cycles that go into displaying windows on your
desk top ... 

>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.

Providing a list of all active group addresses is not really practical.
The list could be very long .. a hundred would be fairly typical. It
takes a lot of silicon to do it, and to do it on the fly requires
scanning the on-chip table during a very short window after the address
is complete, before the data starts to flow.

>Here we are back to our question: is hardware address decoding done in
>practice? If yes, how many address pattern have to be buffered (adjusted by
>switches??? 48-bit?) on average/maximum?

"Modern" Ethernet controllers such as the AMD LANCE use a hash scheme,
where a function is calculated over the set of active multicast
addresses, and a bit mask allows the controller to discard a large
subset of multicasts that are not desired at the station. What passes
through the filter still needs to be checked in software, though.

The proliferation of MAC-level bridges have forced an interesting
solution to the problem. A bridge must pick up a large subset of
traffic, delimited not by multicast addresses, but by "regular"
addresses. Typically several hundred addresses are known, and
partitioned into a set of "local" addresses, which can be ignored, and
"remote" addresses, which must be forwarded. Since commodity ethernet
controller chips do not support this, they must be configured in
"promiscuous" mode, and receive ALL traffic, which is then filtered in
software. This is very hairy on a loaded network (about 5000 frames per
second; at least an order of magnitude above the commodity affordable
class of processing power for embedded systems).

The solution is to store the address table in a bank of
"content-addressable memory". The ethernet chip is set in promiscuous
mode, but the incoming address is loaded into a shift register in
parallel with being fed to the ethernet chip. WHen the address is
complete, a lookup is done on the CAM, which will tell in a single
cycle, whetehr a match was found. If there is no match, a collision
detect is generated to the ethernet chip, which then resumes scanning
for the next frame without needing memory access to the receive buffer,
and without generating any interrupts. Of course, this is a little out
of range for your generic desktop system.

>Please enlighten some curious greenhorns. Thank you in advance.

Always a pleasure to enlighten the world.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM