IBM 3174 C 6.4 Microcode Disks?

"raw 802.3" is a bug, caused by a programmer not understanding how the specs work. The mapping from Ethernet to 802.2 SNAP is trivial, but yes, you do need that mapping. Broadcast is just a special case of multicast. My point was that 802.5, at least as IBM thinks of it, doesn't have proper multicast addresses (low bit set plus 47 bits to say what the address is). Instead, it has "functional addresses" which have a fixed beginning plus one of 32 bits that is set. So instead of 2^47 possible values, you have 32. I don't know why this was done. Perhaps their chip designers thought hash or CAM address matching was too hard? So if you have a protocol that uses multicast, like DECnet, you have to translate the real multicast address to the corresponding "functional" address in an Ethernet-802.5 bridge. And you have to make up a functional address, since the address space of 32 values is too small to have globally assigned multicast addresses as you do with other LANs. The ring passes through all stations of a LAN segment, just as the Ethernet bus (in the original version) passes through all stations of the segment. The point of multicast is that it recognized by multiple stations, not just one. But multicast matters to bridges because they have to forward it differently than individual addresses: individual is forwarded according to the address database entry if there is one, while multicast is not learned and always flooded along the spanning tree. One example of this is the behavior under high load. At one time, token ring marketeers claimed it was better because it wouldn't "collapse" under load "like Ethernet". That is actually false, but in any event, 802.5 worst case latency is incredibly large for large rings. 802.4 and FDDI with their "timed token protocol" have far lower worst case latency. paul