Custom Search

Entrepreneurial Capitalism and Innovation:
A History of Computer Communications 1968-1988
By James Pelkey

Home Page
Table of Contents
Market Sectors
Supporting Documents
Computer History Museum

CHM Home Page
Oral History Archive


Entrepreneurial Capitalism & Innovation:
History of Computer Communications
1968 -1988
By James Pelkey

This history is organized by three co-evolving market sectors and also standards making.
An overview of the schema is presented in the Introduction.

Ch. 1: Emergence
Ch. 3: Competition
Ch. 5: Market Order
Ch. 11: Adaptation

Ch. 2: Vision
Ch. 4: Arpanet
Ch. 6: Diffusion
Ch. 7: Emergence
Ch 8: Completion
Ch. 10: Market Order

Ch. 9: Creation

Ch. 12: Emergence



Chapter 12
Internetworking: LANs and WANs 1985-1988
Local Area Networks and Wide Area Networks


12.4    Bridges - Data Link Layer: Adding a Few Networks Together

By making use of the information contained in the Data Link Layer, bridges offer major improvements over repeaters. The price to be paid, however, is a much more expensive and complex product than the repeater; a product necessarily containing logic and memory. Furthermore, host computers will have to encapsulate the data to be sent in a packet(s) containing, at a minimum, the information of the Data Link Layer. That information includes both the source and destination addresses as well as important supervisory bits.

Bridges, also known as Medium Access Control (MAC) bridges, use the source and destination addresses in packets to build tables of what addresses have come on what interfaces, or links. Afterwards, if it receives a packet with destination addresses that are in the table, the bridge only sends the packets using the interfaces it has seen the source addresses come from. It will not send the packets down all interfaces. Early in there evolution bridges were called “learning bridges,” although the tables bridges built were in no sense routing tables. The tables did contribute to the store-and-forward functionality designed into the relay logic of bridges. (See Exhibit 12.2 A Bridge) These rudimentary tables were an initial step in the creation of “intelligent” internetworks.

Exhibit 12.2 -- A Bridge


The ability to read and use the address information in packets, or datagrams, give bridges even more advantages. If the destination address is on the network originating the packet, then the packet need not be forwarded to other networks, thereby further reducing network traffic. This ability also enables users to subdivide an existing network to improve the performance of both new networks. For example, if a network includes both engineering workstations and office PCs, a bridge used to isolate these different types of computers onto two new networks will likely improve the performance of both new networks. Bridges could also interconnect devices on incompatible networks as long as they conformed to the same Data Link standards, albeit the functionality would be limited.

Initially, bridges were connected in hierarchical topologies known as spanning trees, working best when the LANs were only Ethernet. (See Exhibit 12.3 A Bridge Spanning Tree Network Topology) Spanning tree networks permit multiple connections between bridges, but only connections that do not create loops. There is no calculation of an optimum path.

Exhibit 12.3 -- A Bridge Spanning Tree Network Topology


The address information contained in the Data Link Layer assumes that there is only one wire, or media. When a new network is connected to an existing bridge-based network, all node addresses have to be validated for uniqueness and changed if not. This can become an administrative nightmare as bridge-based networks expand in size and include incompatible networks, such as DECnet or AppleTalk. The processing efficiency of bridges also reached an effective maximum of between thirty and fifty nodes, depending on the mix of LANs and distribution of nodes. [1] Nevertheless, since bridges do not examine or use any information in the Layers above the Data Link Layer, bridges are exceptionally fast.

Another limiting characteristic of bridges is transparency. Transparency refers to the fact that connected Hosts do not need to address bridge(s) specifically but can simply launch Data Link Layer constructed packets. At first this would seem to be an advantage, but as the needs of networks grew more sophisticated, Hosts would need to address the Internetworking product. Lastly, since bridges know only node source and destination addresses, bridge tables are but a static representation of a network. [2] Bridges cannot route packets around congested or failed links (or interfaces), an important requirement for a robust network.

Thus, as considerable as the advantages of bridges are, not being able to route dynamically nor truly accommodate multi-protocols, bridges could not meet the needs of corporations and institutions wanting to create geographically dispersed, large enterprise networks.


[1] Years would pass before hubs earned recognition as Internetworking device. Initially, hubs were essentially wiring closets used to interconnect multiple token ring networks. (At this stage, hubs where Physical Layer devices.)

[2] Except when a tables is updated for new nodes or node address changes.