On 4/12/22 7:49 AM, Paul Koning via cctalk wrote:
DEC documentation.
Thank you.
The concept of a repeater goes back to day 1 of Ethernet; you'll find
them in the D/I/X Ethernet spec. And they were part of the first
batch of Ethernet products from DEC.
Repeaters existing from day 1 of Ethernet sort of surprises me.
I wonder if there is some difference in the original 3 Mbps Ethernet at
Xerox PARC vs the 10 Mbps Ethernet (II?) that was commercialized.
Yes, AUI based devices, two port.
ACK
But the next thing out the door was the DEMPR, "Digital Multi-Port
Repeater", an 8 port repeater. I think that's 10Base2.
$ResearchList++
I first saw "structured wiring" -- the star wiring with a hierarchy
of wiring closets and devices -- around 1986, in the new Littleton
King Street DEC building. It had distribution cabinets at the end of
each row of cubicles. These looked just like standard office supplies
storage cabinets, with shelves; inside you'd find a bridge and a couple
of DEMPR repeaters, connected to 10Base2 coax drops to each cubicle.
Interesting use case. -- Now I'm wondering if each station run was
standard 10Base2 with it's T connector and terminator.
That's not where the term "switch" was introduced. And devices
like that were called "bridge" by market leaders like DEC -- the two
generations of FDDI to Ethernet bridges I mentioned were both called
"bridge".
I first saw "switch" used as a way to differentiate a (dumb) hub from an
intelligent hub type of functionality.
Also, the general operation of the device is the same whether it does
MAC frame tweaking or not, 802.1d applies unchanged. Ethernet to
non-Ethernet bridges have to do some tinkering with Ethernet protocol
type frames (which is where SNAP comes in, all nicely standardized in
the FDDI days). For 802.5 they also have to deal with the misnamed
"functional" addresses, but that's not hard.
I now feel the need to call out what I think are two very distinct
things that need to be differentiated:
1) Learning of which port a source MAC address is on for the purposes
of not sending a frame out to a destination segment when the location of
the destination is known.
2) Spanning Tree / 802.1D learning the path to the root of the tree.
The former is a fairly easy algorithm that doesn't require anything
other than passive listening for data collection. The latter requires
introduction of a new type of active traffic, namely BPDUs.
There also was such a thing as a "source routing bridge", an 802.5
only bad idea invented by IBM and sold for a while until the whole
idea faded away.
We are actually seeing "source routing" make a resurgence in IPv6 via
Segment Routing.
I think "hub" is what DEC called the chassis that these boxes could
plug in to.
I understand now. Yes, that's annoying indeed.
Yes, quite annoying.
I could actually see the use for a card that could go into non-fixed
configuration switches that provided a few 10/100 ports specifically for
this purpose.
So yes, it's theoretically part of the spec. As you said, it doesn't
seem to be in actual use.
ACK
Curious. Clearly such things are possible. But FDDI came out well
before HSTR, and it was crushed by 100 Mb Ethernet. All the reasons
for that to happen would apply much more so for HSTR.
Yep. Lab vs actual commercialized products are quite different. Then
there's what the market purchases and uses.
Does anyone still remember the other 100 Mb Ethernet-like proposal,
I think from HP, which added various types of complexity instead of
simply being a faster Ethernet? I forgot what it was called, or what
other things it added. Something about isochronous mode, perhaps?
Or maybe I'm confused with FDDI 2 -- another concept that never got
anywhere, being much more complicated even than regular FDDI.
I vaguely remember there being multiple 100 Mbps Ethernet
specifications. I think one of them had "Any" in it's name.
--
Grant. . . .
unix || die
