The most important new fact about the human condition is that we are now suddenly connected. When I say “suddenly” I refer to the Internet’s birthday, October 29, 1969 and how two thirds of the human race, five billion people, are already on the Internet, in only 50 years. Suddenly. The Arpanet started the Internet in 1969 by networking time-shared minicomputers serving dumb character terminals. Then in 1973 Xerox Palo Alto Research Center (PARC) decided to put a personal computer on every desk. Ethernet was invented on May 22, 1973 to provide local connectivity among those PCs, one on every desk, if you can imagine that. The PARC Ethernet was formed by combining Jerrold coaxial vampire taps, Manchester on-off keying, and Alohanet randomized retransmissions. Then we wrapped it in internet protocols according to a layered reference model. Then we standardized it all: Ethernet, IP, TCP, TELNET, FTP, Mail, URL, HTML, HTTP. Ethernet evolved rapidly away from its Jerrold-Manchester-Alohanet prototype. Ethernet’s legacy is instead packets to the desktop, abundance of bandwidth, and standardization. Come hear all about it. GPT is writing my lecture now.

The author's involvement in developing Arpanet and Ethernet computer network interfaces is described. The lessons learned in designing and implementing Arpanet in 1969 and Ethernet in 1989 are discussed. It is argued that some of the more general lessons are likely to be applicable to interfaces operating on up to a terabit, petabit, or perhaps even an exabit per second.>

Pup is the name of an internet packet format (PARC Universal Packet), a hierarchy of protocols, and a style of internetwork communication. The fundamental abstraction is an end-to-end media-in dependent internetwork datagram. Higher levels of functionality are achieved by end-to-end protocols that are strictly a matter of agreement among the communicating end processes. This report explores important design issues, sets forth principles that have guided the Pup design, discusses the present implementation in moderate detail, and summarizes experience with an operational internetwork. This work serves as the basis for a functioning internetwork system that provides service to about 1000 computers, on 25 networks of 5 different types, using 20 internetwork gateways.

Local computer networks which communicate over copper conductors have been developed both to promote resource sharing and provide increased performance. Such networks typically operate at bandwidth-length (Bw \circ L) products up to a fewMHz \circ km. In this paper we consider the use of fiber optics in such networks, and give a status report on a star-configured fiber optic network experiment called Fibernet which operates at aBw \circ Lproduct of\sim 100 MHz\circ kmat a data rate of 150 Mbits/s and which in its final phases will connect up to 19 stations. We compare the merits and problems of linear, ring and several star configurations, and of active versus passive networks. The packet communication protocol is discussed and network efficiency is calculated as a function of the packet length, channel capacity and network propagation time. We describe the system performance of the present Fibernet experiment, which uses a 19-port transmissive star coupler, GaAIAs injection lasers and avalanche photodiodes, and incorporates bi-phase data encoding. Power distribution inhomogeneities, observed in the output of the transmissive star coupler's mixer rod, are explained geometric-optically.

The ARPA computer network (ARPANET) is a nationwide network of diverse autonomous computers connected via a message-switching store-and-forward communications subnet using leased wide-band (50-kbit/s) telephone lines. A primary objective of the ARPANET is to share preexisting programs and data. Many of the difficulties of using remotely generated programs and data are found to be simple format incompatibilities requiring data manipulations like character set conversion, header prefacing and stripping, packing and unpacking of repeated data, generating counters and flags, and field transposition. The data reconfiguration service (DRS) is an attempt to provide a convenient way of performing these data manipulations in order to mediate between superficially incompatible data streams connecting existing programs in the ARPANET. Desiring to match two incompatible input-output streams, an applications programmer specifies a data stream transformation (called a form) written in the data reconfiguration language (DRL). Associating the appropriate form name with the connection between his two programs, the programmer causes the DRS to follow his instructions on how the specified data streams are to be manipulated in the communication required to make the two programs cooperate over the ARPANET. Components of the DRS include the specification of its special-purpose data reconfiguration language, a form compiler to translate forms into fast-running transformation programs, an interpreter to perform high-speed data transformations at application program run time, and a standard set of ARPANET protocols for the routine handling of connections and form specifications between operating systems.