Summary

  • DEC’s LANBridge 100 put a distributed spanning-tree algorithm into a product in 1986; the bridge let separate Ethernet segments operate as an extended LAN while placing redundant paths in standby.
  • IEEE 802.1D preserved the same logical tree result, but its Hello frames differed from DEC’s. Migration bridges could recognize and run either mode, one at a time; publication alone did not make the installed bridge populations interoperable.

Ethernet’s useful redundancy created an awkward problem. Two bridges joining the same LAN segments could leave a physical loop. A broadcast frame entering that loop might keep circulating and be copied back onto segments that had already seen it. A bridge therefore needed a rule for deciding which links carried ordinary traffic and which stayed available as backups.

Radia Perlman described such a rule in a 1985 paper on distributed computation of a spanning tree in an extended LAN. Bridges exchange information, choose one root, identify the preferred bridge for each LAN, and leave redundant paths out of the active logical tree. Her paper framed this as a distributed algorithm for arbitrary LAN topologies. It reported convergence proportional to the network’s diameter while the memory needed at each bridge and the communication burden on each LAN did not grow with the total number of bridges or links. The paper established a method; it did not establish a product market or show how many networks used it.

DEC’s product history came through a development project rather than a standards announcement. Its September 1986 Digital Technical Journal described an early prototype nicknamed Brooklyn Bridge. The prototype ran in a laboratory and was later installed between an Ethernet and Digital’s Engineering Network at Tewksbury. That work led to a product project called Janus and the LANBridge 100. The bridge was meant to join LANs transparently while keeping the expanded network manageable.

Its designers wanted it to start and operate without a person at the console, detect troublesome configurations such as loops, and still expose counters and selected settings to a network manager. The redundancy decision was therefore part of a larger product: forwarding hardware, address learning, management, and standby behavior had to work together.

DEC’s engineers described the spanning-tree calculation as a way to keep a looped physical layout from becoming a looped forwarding topology. The LANBridge 100 could put a link into backup while the remaining active links connected the LANs as a tree. A failed bridge or path could then change which links were active. That was not the same thing as proving every resulting path delivered an application’s traffic; the algorithm controlled bridge forwarding topology.

The next step was not simply to rename DEC’s frames. DEC offered its algorithm to IEEE, and the IEEE 802.1D MAC-bridging standard eventually specified a compatible tree calculation. IEEE’s standard record gives three separate dates: board approval on 31 May 1990, ANSI approval on 18 October, and publication on 8 March 1991. Those dates describe standardization stages, not a simultaneous replacement of equipment in operating networks.

Digital’s bridge reference explains the practical gap. LANBridge 100 mode and IEEE 802.1D mode could calculate the same logical spanning tree, yet they used different multicast addresses for their Hello messages. A bridge in one mode did not interpret the other mode’s message. If both types sat in the same extended LAN, each could form its own tree; depending on the topology and startup order, the outcome could become indeterminate or unstable. Compatibility lived in the message that the bridges actually exchanged, not only in the graph they were intended to compute.

DEC’s later LAN Bridge 150 and 200 and DECbridge 500/600 lines supplied an Auto-Select or migration mode. A bridge could listen for the older LANBridge 100 Hello, switch to that mode, and, when no legacy device remained, return to IEEE mode. The same device did not run both trees at once. A network manager could also lock it to IEEE mode. The manual described a way to locate remaining legacy bridges and plan replacements, but it did not report how many customers completed that migration.

That is the narrow historical lesson. A standard can preserve a shared outcome while implementations still disagree at the point of exchange. The bridge release made the algorithm operational; 802.1D made it a standards-based rule; migration equipment gave mixed installations a route between them. None of those events alone proves broad adoption. The evidence supports a sequence of design, productization, standardization, and compatibility work—not a single moment when every Ethernet bridge began speaking the same language.

Sources