IBM 3174 C 6.4 Microcode Disks?

[Grant Taylor]

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