On 02/21/2019 07:43 AM, Paul Koning via cctalk wrote:
"raw 802.3" is a bug, caused by a programmer
not understanding how the
specs work.
I thought people started using 802.3 /before/ the 802.2 specification
was finished. Thus it's hard to follow what doesn't exit. Or at least
that's what I've read multiple places.
The mapping from Ethernet to 802.2 SNAP is trivial,
but yes, you do need
that mapping.
I'm still pontificating how trivial the mapping between Ethernet II and
802.2 SNAP is. I guess as long as you translate the Ethernet Frame Type
to the SNAP Protocol ID (and vice versa) and the Ethernet frame payload
would fit in the upper layer data area, things would be okay. There
might be some payloads that would fit in an Ethernet II frame that
wouldn't fit in an 802.2 SNAP frame on Ethernet. Fortunately Token Ring
had bigger MTUs.
You would probably only be going between Ethernet II and 802.2 SNAP if
you were going from Ethernet (802.3) to a different 802 network. Which
means that other things on that non-Ethernet 802 network would already
understand the same protocol(s) in 802.2 SNAP frames.
The idea of using a mixture of Ethernet II and 802.2 SNAP on an Ethernet
seems odd. (en0 vs et0 interfaces in AIX come to mind.)
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.
Interesting.
Thank you for explaining it.
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.
Was one functional address used in lieu of the broadcast? Meaning that
all stations would receive it, look at it, and decide if they needed to
act on it or not. Much like traditional 10Base5 / 10Base2 / hubs?
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.
I think there's a minutia difference. I don't know if it's germane or not.
To me, Ethernet (10Base5 / 10Base2 / Hubs) are functionally a broadcast
that every station hears without any action on other stations behalf.
Conversely, Token Ring each frame is actively passed station to station
by each station. It's also my understanding that the station will not
pass the frame on to the next station in the ring if the incoming frame
was destined to the local station. Thus, not all stations would
necessarily hear every frame like they would on Ethernet.
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.
ACK
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,
Please elaborate on why it's false.
I've heard of stations locking up and breaking the ring. But I suspect
that you're talking about something else.
802.5 worst case latency is incredibly large for large
rings.
Ya, I can see that.
802.4 and FDDI with their "timed token
protocol" have far lower worst
case latency.
I effectively don't know anything about 802.4 or FDDI.
--
Grant. . . .
unix || die