Summary

  • Ginny Strazisar wrote early BBN gateway software and installed it across heterogeneous network boundaries; the code, PDP-11 hardware and local interfaces had to be coordinated before the famous three-network transmission could run.
  • The surviving record separates architecture from operational proof: it documents disputed demonstration dates, sites that were prepared but not necessarily traversed, collective authorship, and a later shift from research code toward bounded queues and observable gateway operations.

In Oslo, the future Internet briefly depended on a missing machine. Ginny Strazisar had arrived expecting to install gateway software after a meeting. The hardware was not ready. She stayed with Norwegian researcher Paal Spilling, travelled elsewhere in Norway, then returned when the PDP-11 could finally receive the program. In her later oral history, the episode is recalled with affection rather than drama. Yet it contains the practical core of early internetworking: a protocol could cross a boundary only after the hardware, interface, code and people met at the same place.

That is a different origin story from the familiar diagram of a packet leaving a moving van, crossing packet radio, ARPANET and a satellite network, and returning to a host in California. The diagram captures the path. Strazisar's work exposes the prerequisite. Before packets could travel, gateway software had to travel.

Strazisar joined Bolt Beranek and Newman in April 1975. She said she quickly began working on “gateways,” the machines that connected networks. A gateway already linked BBN's experimental Resource Computer Network to ARPANET. She then worked on connections between ARPANET and the Packet Radio Network, and between ARPANET and the Atlantic Satellite Network. The Computer History Museum describes her as the author of the first internetworking router software for the emerging TCP/IP protocols—at a time when “router” was not yet the usual name.

The phrase “connected networks” can make the job sound like a uniform cable exercise. It was the opposite. Packet radio dealt with mobility, changing radio paths and intermittent testbed availability. ARPANET presented its own host and interface conventions. SATNET crossed an ocean and depended on geographically separated equipment and operators. Internetworking mattered precisely because those networks were not redesigned into copies of one another.

The physical arrangement reflected that heterogeneity. Strazisar recalled that the packet-radio station code and gateway code shared a PDP-11. At the satellite boundary, the gateways were separate PDP-11s: one side communicated with ARPANET, the other with the satellite network, and the software directed packets between them. This was not a single universal appliance dropped unchanged into every rack. A common internetworking function had to be realised against distinct local mechanisms.

Her installation chronology makes the dependency visible. By her recollection, she installed work at BBN in summer 1976, in London in December 1976 and in Norway in summer 1977. Hardware and software were separate responsibilities, so travel had to be coordinated with machine delivery and interface readiness. The London machine arrived before her software visit. Oslo's delay broke that sequence and forced a return. A programme described at architectural altitude became a series of site-readiness decisions.

The early proof came in stages. A Computer History Museum magazine describes packet-radio trials in summer 1976 that stayed one radio hop from the station housing Strazisar's bidirectional ARPANET gateway software. It dates a ceremonial two-network transmission to 27 August 1976. The harder demonstration linked three physical kinds of network in 1977. The museum's later account describes data flowing from a moving van through the Bay Area and onward to USC by way of transatlantic infrastructure.

Even this famous event resists a polished single date. The museum's 2017 essay says the demonstration ran on Wednesday, 22 November 1977. Its 2002 magazine labels the three-network diagram 27 November. The sources also distinguish deployment geography from packet geography. Strazisar installed software in Norway, but Vint Cerf recalled in the oral-history discussion that the demonstration traffic did not actually enter Norway; the exercised gateways were associated with other satellite links. A prepared site is not automatically evidence of an exercised path.

That distinction is not pedantry. Infrastructure histories often turn a successful end-to-end exchange into proof that every component, site and contingency worked. In reality, a demonstration validates one route under one configuration at one time. An installation proves that hardware and software were placed together. Neither alone proves failover, sustained availability or the behaviour of an unexercised interface.

Nor was this the achievement of one programmer. The museum lists more than 35 participants across eight institutions. It separately credits Bob Kahn and Vint Cerf for the TCP concept; Jim Mathis and Dave Retz for the client; Ray Tomlinson and Bill Plummer for the server; teams at SRI, Collins Radio, Linkabit, BBN, UCL and the Norwegian Defence Research Establishment for packet radio and satellite work; and Strazisar under BBN gateways. Her contribution becomes clearer, not smaller, when placed inside that system: she owned a boundary without owning every network on either side.

The gateway record continued after the demonstrations. RFC 823 says the design was first documented in IEN 30, Gateway Routing: An Implementation Specification, and later in Strazisar's IEN 109, How to Build a Gateway. It gives special credit to V. Strazisar, M. Brescia, E. Rosen and J. Haverty. The sequence matters because a running artefact accumulated a written account that other implementers and operators could inspect.

IEN 30 is unusually candid about what implementation detail cannot guarantee. It specifies a routing algorithm closely enough to build and aims to route around failed components. Yet it says analysis cannot prove that gateways will always route correctly or that some destinations will never suffer indefinite non-delivery. Vulnerability may appear only after experimentation and operational use. It also separates algorithm failure from implementation failure: routing information can be corrupted, hardware or software can malfunction, and a correct algorithm can be coded incorrectly.

RFC 823 records the next transition. Early gateway software used BCPL with the ELF operating system, then MOS for better performance. By late 1981, the programme was building a new implementation for an operational communications facility rather than a research testbed. The rewrite used MACRO-11 to save space for buffers and monitoring. Despite the language and operational changes, the RFC says the architecture remained fundamentally the same.

Operationalisation therefore did not mean declaring the prototype finished. It meant making limits observable. The documented gateway capped each interface's output queue so a slow network could not consume every buffer. When a packet could not be queued, the system dropped it and sent a monitoring trap. Operators could inspect interface status, neighbours, reachable networks, throughput and reasons for drops. RFC 823 called itself a snapshot of the current implementation, not a specification—a warning against confusing a deployed version with a permanent contract.

Strazisar's journey leaves a precise modern test. When a platform claims to bridge unlike networks, ask for the build that runs at each boundary, the hardware and driver it expects, the interfaces actually exercised, and the telemetry that reveals what it drops. A control-plane diagram is evidence of intent. A successful packet is evidence of one path. Repeatable deployment and failure observation are evidence that the boundary can be operated.

The gateway code travelled before the packets because interoperability has a geography. It lives in machines, release media, local cabling, site schedules and people who can tell whether an interface is merely installed or demonstrably working. The abstraction made the Internet possible. The installation work made the abstraction true.

Sources