Retro networking / WAN communities
Grant Taylor
cctalk at gtaylor.tnetconsulting.net
Tue Apr 12 11:45:30 CDT 2022
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
More information about the cctech
mailing list