A History of The ARPANET The First Decade (Report) - Arlington, VA Bolt, Beranek & Newman Inc.. 1 April 1981.

jr
"
"DEFENSE kDVANCED RESEARCH <PROJECTS AGENCY

"
A HISTORY OF
"THE
ARPANET:
The First Decade
,*,i , C.%"
SWPt'ov
April 1981
1'o PLtLiT o
^ELECTE
DTIC
dltT.~
and Newman, Inc.)
(Prepared for DARPA by ,-- ,ranek
1400 WILSON BOULEVARD ARLINGTON, VIRGINIA 22203
S82
Li
06 10
044
Report No. 4799
A HISTORY OF THE ARPANET
The First Decade
AMOVED&'Cl YFUBLIC RWX I'0?rsGAZ SaL.UUI.IMID

-DISTRIBIJ?1Of
JuStifiee
DTIC TAB
ii
April 1981
DCst.Ibu
tJ
speci
Report No.
4799
Bolt Beranek and Newman Inc.
Table of Contents I. EXECUTIVE SUMMARY ARPANET PROJECT

,'t
OBJECTIVES AND RESULTS'
I-I II-1 11-2 11-2 11-5 11-7 II-7 II-10 II-10 11-12 11-19 11-21 11-21 11-23
II.'N 'HE
1.&,'rogram Objective and Technical Need. 1.1 1.2 1.3 1.4 Defense Program Addressed State of the Art at Program Inception Specific Technological Problems Addressed Expected Payoff/Time-Frame/Costs
2.(30rogram Description and Evolution2.1 2.2 2.3 Program Structure Major Technical Problems and Approaches Major Changes in Objectives and Approaches
3, ,3 Scientific and Technical Results and Accomplishments. 3.1 3.2 Results of the Effort in Relation to the Program Objectives Technical Aspects of the Effort Which Were Successful and Aspects of the Effort Which Did Not Materialize as Originally Planned Applications and Considerations for the Future,
4.
11-28 11-28 II-28 11-31 11-31 11-31 11-32 11-32 11-33
4.1 4.2
Conclusions of Technical Feasibility Recommendations on Additional R&D Requirements and Opportunities t54rogram Impact and Assessment of Technology beveloped Service Use of Technology Impact on Non-DoD Programs Applications of the Program Results Advance in the State-of-the-Art Bibliography of Reports
5. 5.1 5.2 5.3 5.4 6.
Li
Report No.
4799
III! A HISTORY OF THE ARPANET PROJECT,
II-12
1. 1.1
History Background The RAND Study of Distributed Communications Networks The Lincoln/SDC Experiment The NPL Data Network The Events of 1967 and 1968 Key Aspects of the RFQ Chronological Development, 1969 to 1975
111-2 111-5 I1I-5

II-9
1.1.1 1.1.2 1.1.3 1.2 1.3 1.4
III-11 111-14 111-18 III-24 111-25 111-26 111-29 111-32 111-35 111-36 111-39 111-45 111-48 111-53 III-58 111-61 111-64 111-68 111-72 111-72 III-76 111-91 111-94 111-104
1.4.1 -'The Groups and the Key People, 1.4.1.1 1.4.1.2 1.4.1.3 1.4.1.4 1.4.1.5 1.4.1.6 1.4.1.7 1.4.2 1.4.3 1.4.4 1.4.4.1 1.4.4.2 1.4.4.3 Management and Administration of the Network: DARPA/IPTO,, DSS-W, RML, and DECCO The Network Analysis Corporation The Telephone Companies Bolt Beranek and Newman Inc. The Network Information Center The etwork Measurement Center The Network Working Group and Host Involvement Initial Subnet Design Subnet Development Host Protocol Development Host-to-Host Protocol The Evolution of TELNET The Evolution of Other Host ?rotocols Growth -A Summary.
1.4.5,:Network 1.4.5.1 1.4.5.2 1.4.5.3 1.5 1.6
Traffic Growth Topology Hosts
The Impact of the ARPANET Maturity and Handover to DCA
6 6
S"'
" ' " J i : '" :- " ' .. . i I "'|';"' " iii
Report No. 4799
111-106 2.
2.1
Observations
Social Issues
111-107
111-112 III-113 111-119 III-122
2.2 2.2.1 2.2.2 2.2.3
Technical Lessons Terminal Handling Reliability and Fault Isolation Maintenance Management Appendices
A.
BBN ARPANET Bibliography A.1 A.2 Technical Reports Published Papers
A-1 A-1 A-3 B-1 j
B.
Selection of ARPANET Logical Maps
iii
Report No.
4799
CHAPTER 1:
EXECUTIVE SUMMARY
I-
Report No.
4799
Bolt Beranek and Newman
Inc.
1.
EXECUTIVE SUMMARY
In fiscal year 1969 a DARPA program entitled "Resource
Sharing
Computer
Networks"
was initiated.
The research carried famous as
out under this program has since become internationally the ARPANET.
This DARPA program has created no less than a revolution computer technology and has been one The
in
of the most successful program has initiated
projects ever undertaken by DARPA! extensive changes in well as in
the Defense Department's use of computers as
the use of computers by the entire public and private the United States and around the worlu. the telegraph, and the printing Just as had
sectors, the
both in
telephone,
press
far-reaching
effects on human intercommunication,
the widespread the the
utilization of computer networks which has been catalyzed by ARPANET project represents a similarly far-reaching change in use of computers by mankind.
The full impact of the technical understood for
changes set in
motion by this project may not be
many years.
In 1975 the ARPANET was successfully transferred to the it since that
Defense Communications Agency which has operated time.
* Defense Advanced Research Projects Agency (DARPA)
I-2
Repor
No.4799Bolt
Beranek and Newman Inc.
CHAPTER II:
THE ARPANET PROJECT
OBJECTIVES AND RESULTS
Ii,
iI
[
5
1I-1
Report No.
4799
1. 1.1
PROGRAM OBJECTIVE AND TECHNICAL NEED Defense Program Addressed The DPRPA program and had the following objectives: experience on (1) To
develop computers
techniques in
obtain
interconnecting
such a way that a very broad class of interactions and (2) To improve and increase It computer research that by
are possible,
productivity through resource sharing. establishing
was envisioned
a network tying computer research centers together, In fact, for an the most efficient way to effective network was
both goals would be achieved. develop the thought in to techniques needed
be by involving the research talent at these centers Just hundreds as of time-shared individual computer users it was to systems share thought
prototype activity. groups of
permitted
hardware and software resources with one another, that networks connecting dozens of
such systems would permit users. Each system, by
resource sharing between thousands of virtue of being time-shared,
could offer any of its services to The most important criterion

I'
another computer system on demand.
for the type of network interconnection desired was that any user or program on any of the networked computers be able to utilize without
any program or subsystem available on any other computer having to modify the remote program.
11-2
Report No.
4799
This objective was an entirely new and different approach to an extremely serious problem which existed throughout botn the The many hundreds of
Defense Department and society at large. computer centers in the
Defense Department and the many other the private and public sectors
thousands of computer centers in operate
almost completely autonomously.
Each computer center is wishes
forced to recreate all the software and data files that it to utilize. In of many cases this involves the
complete This time such of
reprogramming
software
or reformatting of data files. extremely DARPA the costly and that costs
duplication and redundant effort is consuming. In fiscal more year than the 1969
estimated national
duplicative efforts creating and
double
maintaining
software.
There had been other problem, such as at
completely different attempts to address this attempts at language standards for and
computers, attempts
attempts at
standardizing the types of hardware, translation between computer
automatic each trying such to
languages.
Although of
approach had some value and utility,
the problems
share computer software resources or files was truly enormous. In addition to the general problem shared with the rest of the Defense DepartmeTrt also faces
the scientific certain special
community, problems
having to do with training.
Military often from
personnel trained to use one manufacturer's equipment must be trained again to use another's. Machines procured
11-3
Report No.
479'
Bolt Beranek and Newman inc.
different manufacturers require as many different
user
training
programs as there are machines,

of training that could
thus inhibiting positive transfer

through and the rotation which of have
accumulate
military personnel. common utility
Those data files
programs
to many military organi.ations and installations
must
be
stored,
created
and
maintained
systems
separately
at
each
in a
different
machine.
Military
interconnected
distributed intiractive network obviate such constraints. Another objective of th( of specialized It computers to program was to permit the linking
the many general purpose computer recent improvements
centers. in the
was thought that with the then area, it
hardware
would become most cost effective to efficient at specialized tasks
design and construct computers (e.g., compiling, list
processing to
and information retrieval). all the computer research
Making such machines establishments would
available
significantly
increase
the capability at
these other centers.
This program was addressed et no less then changing the of computers by the entire Defense Department. computer across network It
use
was clea. ly permit
intended that the use of such a resource sharing within and
would
the military services and
throughout the Defense research community.
11-4
Report No.
4799
1.2
State of the Art at Program Inception By the date of the program plan in the late 1960s most of
the
specific
technologies
required
for a computer network had For example, (e.g., there had
individually been achieved in
some form.
been many connections of phone lines to computers system, However, Air Line reservations systems, there
the SAGE
and time-sharing systems).
had been only a very small number of attempts to with
connect computers together for the purpose of experimenting the sharing of resources.
"o
In the early 1960s an attempt was made to link computers together at the Western Data Processing Center at UCLA
for the purpose of enabling similar computers to perform load sharing. A similar experiment was also performed
at Bell Laboratories and achieved reasonable success for several years.
"o
A number of networks were constructed purpose inventory of message control handling, system The
for
the
primary
including a Westinghouse several air line
and
reservations
networks.
SITA network for air line concept in generally In any case, the not the
reservations was surprisingly advanced in mid-1960s, known in but details about SITA were
the U.S. used
computing community. for
techniques
such message systems were special
11-5
Report No.
4799
purpose in the general o
nature and were not readily transferable area of inter-computer communications.
into
A direct progenitor of the ARPANET was an effort made in the mid-1960s to achieve computing computer. between Laboratory, modifying interactions. expertise and a coupling the between academic
operation of the SDC Q32 phone the line TX2 connection at Lincoln ease of
This effort led to a the and time Q32 at SDC and
demonstrated sharing
the
relative to permit
systems
network
Aside computers
from with
the
technical
problems circuits,
of
interconnecting
communications considered of view. in
the notion of computer of places from a
networks had been theoretical point
number
Of particular note was work done by Corporation in a study "On
Paul Baran and others at the Rand Distributed was work done Communications" by Donald in
the early 1960's. and others at
Also of note the National
Davies
Physical Laboratory In sum, in fiscal
in England in
the mid-1960's.
at the time of the initiation of the ARPANET program year 1969 many of the requisite ideas bits and had been pieces
considered and many of the requisite technical had been attempted in some form, them
but no significant attempt had into a resource sharing
ever been made to put computer network.
together
11-6
Report No.
4799
1.3
Specific Technological Problems Addressed The technological problems of building the ARPANET can be
At the top level,
considered at many different levels of detail. there were really two problems: 1. To construct a "subnetwork"
consisting
of
telephone
circuits
and
switching capacity,
nodes whose reliability, delay and cost would facilitate
characteristics,
resource sharing among the computers on the network. 2. To understand, procedures design, and implement the the operating protocols of and each
within
systems
connected computer,
in order to allow the use of the new
subnetwork by those computers in sharing resources. Within these two major technological problems, of course, a large number of sub-problems; there including were, the
engineering of the phone circuit connections, network,
the topology of the the design of the routing

I-
the selection of switching node equipment,
line disciplines to work through phone line errors, problem, 1.4 and many others.
Expected Payoff/Time-Frame/Costs The goals for the ARPANET project were very broad and of computers
envisaged a significant eventual impact on the use
11-7
Report No.
4799
in
both the public and private sectors. DARPA visualized
However, some
in addition to quite specific
these long range goals, initial
payoff in the form of improved productivity of the DARPA
research program itself, and a resulting cost/performance benefit to the services from DARPA research. number of In fiscal year 1969, a
computer research centers throughout the country were Information of Processing an effective
supported in whole or in part by DARPA's Techniques Office (IPTO). The
installation
network tying these locations together would substantially reduce duplication and improve the transfer of well as develop scientific results, as
the network techniques needed by the military. inportant to all this output three be of
The research output of these projects was Services and it was expected that
could
substantially increased for the same dollar cost if the funds were utilized for the network. In addition,
a portion
initial payoff was anticipated in the form of
technology transfer from the ARPANET project in three ways: o By dissemination of new scientific knowledge through
conferences and the appropriate literature. o By transfer of management of the carrier, and the resulting ARPANET to of of a common ARPANET Education and
availability Office
services to other groups (such as Regional Laboratories,
NSF-supported universities,
various user groups supported by the NIH). 11-8
Report No.
4799
By
adoption
of
the
network
technology
by
specific
military System
groups Support
(such as the National Military Command Center and other military centers
affiliated
wth
it; e.g.,
CINCPAC,
CINCEUR,
and MACV).
11-9
Report No.
4799
2. 2.1
PROGRAM DESCRIPTION AND EVOLUTION Program Structure With the initiation of the ARPANET program plan in early
fiscal
year
1969,
DARPA began work in the for
earnest on three parallel circuits; (2) to
paths of effort: select the
(1) to obtain contractor to for
network
system
the switching nodes and the efforts sharing within the DARPA and
overall design; and (3) research community
initiate resource
experiments
specialized network support. DECCO was able to handle all the the contractual details with
common carriers for circuit leases. the ARPANET were
Most of the required 50 leased through DECCO
kilobit circuits used in from AT&T,
but a small number of circuits were leased from other In addition, in DARPA arranged which system
carriers such as General Telephone. for a special point of contact
AT&T (long lines), network
greatly facilitated the interactions between the contractor, DARPA, and AT&T. The selection (and,
of network node therefore, the
locations and the location of
internode
connections was
circuit
terminations)
a specialized topology problem problem, (NAC). NAC in its DARPA had
problem and represented a difficult theoretical own right. To help solve this particular
contracted with the Network Analysis Corporation developed certain networking
analysis tools and via this DARPA
II-10
hal':'d
A'-
=,
" ,
.-
- - . -
-:o
I .
Report No.
4799
support,
such tools were refined;
NAC's advice
on
topology
was
sought through the various stages of ARPANET growth. A competitive procurement was planned for the selection of as general
the contractor to design the switching nodes and act systems contractor. Bolt Beranek and An RFP was prepared and issued in Newman Inc. (BBN)
July 1968.
was selected as the systems and the switching
contractor for the design of the nodes. BBN
subnetwork
subcontracted with Honeywell Over the until the life of the to
for the switching node ARPANET program from BBN
hardware itself, January 1969
transfer
DCA in
July of 1975,
served as the systems contractor for the design, operation and maintenance of the subnetwork; Defense
implementation, BBN is still
serving that role under the aegis of the Agency (DCA). The
Communications
research groups receiving DARPA IPTO support then began the and, design in turn, and implementation of protocols in and the
considering procedures
computer program modifications, order to use the subnetwork. were arranged:
various host computers in specific responsibilities
Several
UCLA was specifically
tasked to develop and run a "Network Measurement Center" with the objective of determining the performance of the network; SRI was
specifically tasked to develop and operate a "Network Information Center" with the objective of collecting information about the
lI-11
Report No.
4799
network,
about
host
resources,
and at the same time generating and accessing that collected
computer based tools for storing information. hoe
Beyond these two specific contracts, were pursued to reach the over the
some rather ad between the "host The the
mechanisms research for Working host
agreement
various
contractors
about
appropriate subnetwork. from
protocols" "Network various
intercommunicating Group" was of
interested
individuals
sites
rather informally encouraged by DARPA. the forum for, for, the
After a time, this Network Working Group became and eventually a semi-official approval
authority
discussion of and issuance of host protocols to be implemented by the various research contractors. Progress in this area was
rather slow for a while, but with time, this mechanism eventually was successful in establishing effective host protocols. 2.2 Major Technical Problems and Approaches In a program of this duration and complexity, it is not
difficult to identify many dozens of important technical problems and approaches to those problems. We here list a few of the
problems which were most technically challenging in the early few years of the ARPANET program. A few additional major technical
problems will be listed in the next section on "Major Changes and Objectives".
11-12
Report No.
4799
TOPOLOGY - For any network of dozen nodes, an obvious, is
this
type
with
even
early recognized, topological
and quite
formidable Assuming
problem that
optimization. the number is very-
the node locations are known, links among N nodes
of ways of arranging M
large; the links are usually available in (bandwidth); delay and the and component reliability
discrete sizes time all
cost structures, functions are
functions,
typically non-linear. constraints, including
The design may be subject to many maximum or average time delay, and reliability
average or peak throughput requirements,
requirements. The usual goal of the optimization is to provide a network design that meets all constraints at the lowest cost. design an The approach to this problem was to the
elaborate It is
computer program to assist in not possible to use an
optimization. approach, a
exhaustive
and instead the approach used was to generate network" to the and then to in perform local
8starting
transformations
topology
order to reach a
locally optimum network. If this procedure is repeated with many starting networks and if the resulting locally optimum networks are evaluated, feasible it is possible to find a
solution with costs that are close to optimal.
11-13
Report No.
4799
ERROR CONTROL - A critical sharing computer network
necessity was to
for
resource reliable was
provide
communication and one component of such reliability an ability to work through the
expected phone line The approach hardware each 50 taken at the kilobit
errors on the 50 kilobit circuits. was to design and special
checksumming end of
transmitting circuit in
receiving
the network. procedure, a
As part of the switching node powerful 24 bit cyclic
transmission checksum is
appended to every packet of information to
the at the receiving node, Then, be transmitted. checksum is recomputed in hardware and compared with Lhe transmitted checksum. If there is no error, back error, will an to no be 3 An important issue was the proper
acknowledgment (with its own checksum) the transmitting is node. sent If and there the
is sent is an
acknowledgment retransmitted. 0 HOST INTERFACE design of an
packet
interface between the switching node and It is important node
host computers of many different types. to allow a logical match between the
switching
computer word length and the varying word lengths of the

host computers, and also to node allow and the input/output the input/output
routines of the
switching
11-14
Report No.
4799
routines
of
the host computer to service the interface
"cooperatively" burden or tight
without
placing
an
undue
processing
timing constraints on either machine. interface
The approach taken was to design a bit-serial which

require
could
that
logically
each
small
stop after any bit, and to then

computer build (obtain) a
host
host
specialized
hardware
unit called a "special
interface" which would be installed in a itself to serve the network connection.
the host Thus,
machine a logical
and electrical convention was specified by the switching network in to all a manner intended to minimize overall trouble then each host was required to meet that
hosts,
standard both in hardware and software.
SWITCHING NODE PERFORMANCE network was
central
goal
of
the
to provide resource sharing between remote such a way resource required that a local user could In be have
installations in employ a
i-emote this
without that the
degradation. subnetwork low delay,
particular, sufficiently sufficiently cost, use.
reliable, great
have sufficiently
capacity
and have sufficiently low local
that remote use would be "as attractive" as
These objectives translated into a major technical for the switching node itself to provide low
problem
11-15
Report No.
4799
delay and high capacity at modest taken was to
cost.
The
approach
select a mini computer for the switching to write
nodes whose I/O system was very efficient and very
carefully tailored programs in machine language to
optimize the capacity and the low delay of the data path in the switching node. minimizing the Great time attention of was paid to
operating
the inner loops of
these programs. o REMOTE CONTROL - A special and new problem was posed by
the need to put dozens of small identical mini computers in the field, in an environment where the host
connections to those computers was somewhat experimental and where the programs in the mini computers were month. under themselves
development and were changing from month to debugging of
It was important to be able to do debugging and costs of the and new
software,
host connections, of new
program programs with
modifications, without the
installation difficulties
associated
having manned sites. an entirely new
The approach taken was to technology of Center remote was
develop computer
management.
A Network Control
established
for the subnetwork and software was developed which made it possible to examine or change the operating software control
in any node of the net from the central network
11-16
Flow_
Report No.
4799
center.
This
approach
made
it
possible each
to
issue in In to
complete new versions of the software to the
node
network from a central place in an hour or twc. each node reports the state of its health
addition, the
central place periodically and provides information maintenance activities. an important
on which to base debugging and o
ROUTING - In a non-fully connected network, problem is the decision process by
which each node
decides how to route information to reach any particular destination. This is a difficult theoretical problem
and there are many different approaches, routing, random routing,
including fixed
centrally controlled routing, The
and various forms of distributed adaptive routing. approach taken was to use a distributed adaptive traffic routing algorithm which adjacent for estimates nodes each the on the
basis
of
information from instantaneous
globally in
proper
path
message and local
the face of or nodi
varying input traffic failures.
loads
line
Each IMP keeps tables containing an estimate
of the output circuit corresponding to the minimum delay path to each other IMP,
the delay.
and a corresponding estimate

each IMP sends its whenever
of
Periodically,
its
current an IMP
routing estimates to
neighbors;
receives
such
message
it
updates
its
internal
II-17
Report No.
4799
Bolt Beranek and Newman Int.
estimates. is
Thus,
information about changing throughout the
conditions network, and
regularly
propagated
whenever a packet of traffic must be placed on the queue for an output circuit, of the best path. the IMP uses its latest estimate
HOST PROTOCOL - In many ways a computer host users: computers as the telephone
network is
is
to
system
to human
a transparent communication medium in which even to that in insert dimes and
after the caller has learned how dial, it is still the necessary person called
he speak the same order for useful referred
language as communication
to occur.
The common language is
to as host protocol, protocol which is
and the problem is
to design a host
sufficiently powerful for the kinds of
communication that will occur and yet can be implemented in all of the various different host computer systems. approach taken involved the development of a a a "Network host would Control Program" such with that the The
The initial
piece of software called which would reside a in host
computer, communicate Control
processes within network through
this
Network
Program.
primary function of the NCP is break connections,
to establish connections, and control flow.
switch connections,
U1-18
Report No.
4799
Bolt Beranek and Newman
Inc.
A "layered" approach was taken such
that
more
complex
procedures (such as File Transfer Procedures) on top of simpler procedures in Program. 2.3 Major Changes in Objectives and Approaches
were built
the host Network Control
The ARPANET development was an extremely intense activity in which contributions were made by many of the best computer "major
scientists in technical
the United States. already
Thus,
almost all of the received
problems"
mentioned to years major
continuing changed
attention and the detailed approach several However, times in during the early
those
problems
of the ARPANET effort. changes in objectives
addition several more
were introduced once the initial o THE TIP - The IMPs, were initial
network became operational: nodal switching units, called
intended to interconnect computers and high lines. At the outset all terminal
bandwidth phone access to the
network was via terminal connections to After a time it cf users for became clear that which terminal
the hosts themselves. there was a access to population
the network was very desirable,
but who were a host
not conveniently able to access the network via computer. Thus, a new nodal switching unit, or TIP, was
a Terminal defined to
Interface Message Processor,
11-19
Report No. 4799
serve
the purpose of an IMP plus an additional function This shift resulted in the
of direct terminal access.
design of a TIP which really was a tiny host embedded in a switching node itself and permitted the direct
connection of up to 63 terminals to the
asynchronous node.
character-oriented The TIP became the where there
switching
nodal switching unit of choice, was a local
often even
host computer; this allowed connection of location directly to
both hosts and terminals at that the network.
11-20
1i
II
Report No.
4799
3. 3.1
SCIENTIFIC AND TECHNICAL RESULTS AND ACCOMPLISHMENTS Results of the Effort in Relation to the Program Objectives can be seen to reach its
In some cases a major program objectives in a single instant:
a mushroom cloud at Alamogordo, In other cases, like the
or Armstrong stepping onto the moon. ARPANET, success, and was over "to
an equally important objective may be reached with equal but the event must be observed in a longer period of time. develop techniques in and a more complicated way ARPANET objective experience on
The first obtain
interconnecting
computers
such a way that a very broad class Not just techniques, but an
of interactions are entire
possible".
technology of packet switching has been developed,
and an
enormous body of experience has been developed on interconnecting computers to allow a broad class of interactions. A second objective, which has also been attained, was to
improve computer research productivity through the development of computer resource sharing. Another objective was to permit the linking of specialized Several
computers to the many general-purpose computer centers. major the
specialized computers have been linked over the ARPANET to main general purpose computer centers in an extremely
successful fashion.
11-21
Report No.
4799
Bolt.Beranek and Newman Inc.
At
technological
level,
the overall objectives were to delay characteristics,
construct a subnetwork whose reliability, capacity, computers and in cost
would facilitate resource sharing among the and to understand, such over 50 resource nodes design and implement sharing. Such a
the network;
the host protocols to subnetwork, consisting
permit of
and stretching from and the necessary the connected
Hawaii to Norway,
was successfully constructed; resource sharing
host protocols to allow
among
computers were successfully understood, The demonstration
designed and implemented.
of initial net operation with four nodes a time scale
and later the extension to 19 nodes took place on that was
extremely close to the incremental time anticipated in However, as the success of
the program that was being planned. the
ARPANET became obvious after about two years,
decisions were to a
made to take advantage of this success and to grow the net size that had never been anticipated at the outset;
growth to 'o Norway
more than 50 nodes over a geographic area from Hawaii was certainly not originally anticipated.
In similar fashion, very
the costs in close
the first
two fiscal years of the program were
to anticipated costs, the, network,
but as decisions were made to expand the cost no longer followed the
the scale of
original program plan.
11-22
Report No.
4799
In
short, far
the
results than
of
the
effort met
were the
eminently objectives
successful and initially
more
adequately
stated.
The success of the program far exceeded even
the most optimistic views at the time of inception.
3.2
Technical Aspects of the Effort Which of the Effort
Were
Successful
and
Aspects Envisaged
Which Did Not Materialize as Originally
A representative list
of the aspects of the ARPANET programs

follows:
which were technical successes
Powerful
computer-based were
techniques
for
topological
optimization
developed
and the choice of ARPANET
topology was made with the aid of these tools. o The carriers successfully provided high reliability
50K/sec circuits. o A subnetwork including nodal switching IMPs and TIPs was constructed whose performance, facilitate resource sharing. o The ARPANET provides adaptive routing in a convincing can demonstration be made that reliability, and cost did
algorithms
to perform the face to
reliably (e.g., of local
a globally correct manner in efficiently (e.g.,
failures),
adapting
.1
11-23
Report No.
4799
changes flexibly
in
the
network
quickly a
and accurately), variety of
and
(e.;., and
accommodating internode
circuit
bandwidths
distances) without excessive
complexity and overhead. o The ARPANET has demonstrated that it is possible to
build a large operational network in such a way that the effects of component failures are localized rather than otherwise
all
"crashing" or
portions or
making
non-operational
large
of the network.
A node or a host can
fail in the ARPANET and network use for only
will
be
prevented
the few users directly connected to that node
or using that host.
The ARPANET has confirmed the networks delays

incurred network.
theoretical packets to
result
that
which which
in
store-and-forward are low when
can achieve the delays
compared
the
computers (hosts)
which are using the
The ARPAMET has
demonstrated
that
network
can
be
constructed so that nodes, be added or
lines, traffic,
and so on can
deleted without major upheavals with each
addition.
I1-24
Report No.
4799
The ARPANET has demonstrated that it network to control and
is
possible
for
operate itself
for hours at a
time without explicit control from a control center. o The ARPANET has demonstrated and new techniques for
monitoring,
maintenance,
debugging.
The nodes in no
the ARPANET typically operate at sites where there is krowledgeable automatically itself) and person report available their locally. (via and The the
nodes network
status
to a network monitoring center, debugging (of
maintenance are the
both the software and hardware) from
typically carried out (again via the network) monitoring center. o Possibly the development most of the difficult ARPANET to make of a task was undertaken
in
the which
the attempt -of
proved successful -host computer
number
independent and
systems
varying
manufacture,
varying operating systems within a type,
single
manufactured
communicate with each other despite their diverse
characteristics. o A set of host protocols was host organizations hammered out between the
and resulted in
a layered structure sharing.
of host protocols that did facilitate resource
11-25
-'
*-wla~oL---
Report No.
4799
The ARPANET was successfully transferred Communications Agency.
to the
Defense
Inevitably tractable than
there had
were been
technical hoped and
areas some
which proved less kinds of network
utilization developed more slowly than had been anticipated. Problems of routing, the subnetwork flow control, out and congestion control in to be as difficult as be
turned
theoreticians had anticipated,
and the algorithms had to
modified more than the implementors had anticipated. Luckily, the improvements in the algorithms managed to stay slightly and, ahead of the growth in network size and traffic with to the algorithms sharing on never the
therefore, an
difficulties impediment
represented
network. It
resource
proved more difficult to agree on host protocols than of had the
the
specification
of
adequate However,
been originally hoped. host protocols was
the eventual
design
eminently successful and provided a strong base for resource
sharing.
k
of a widely-useful on-line Network project.
tools
The
development
Information Center (NIC)
proved to be a
difficult
Although very interesting and important computer-based
11-26
Report No.
4799
for
information
handling were developed,
the actual timely descriptions proved

that
collection and on-line publication of detailed of resources at the various

the
host
sites
tools
nearly
were
intractable. developed,
Further, while rather
computer
elegant,
were not so clearly cost Eventually, the goals
effective for wide scale remote use.
of the NIC wer-e substantially reduced and at the time of the ARPANET obtain transfer detailed to DCA, it was about generally necessary to the resources at a
inform3tion
particular site directly from the site.
Many
different
kinds
of
resource the
sharing
use
were Of
anticipated at the inception of these, the
ARPANET
program.
remote use of one program by another was one of While some of this kind of resource such Use has grown more
the more distant goals. sharing has, indeed,
taken place,
slowly than other network uses.
t1
11-27
Report No. 4799
4.
APPLICATIONS AND CONSIDERATIONS FOR THE FUTURE
4.1
Conclusions of Technical Feasibility

The ARPANET reliable by project high means proved the technical cost feasibility of digital in
achieving
performance,
effective
communications turn,
of packet switching technology and, resource
the technical feasibility of operating a network based on this technology.
sharing
computer
The ARPANET project
also proved the feasibility of achieving closely knit communities of technical interest over a widespread geographic possible that this social feasibility area; it is is as
demonstration
important as the many technical feasibility demonstrations. 4.2 Recommendations on Additional R&D Requirements and
Opportunities It is clear that packet switching and in control networks have a very and a significant
direct application to research opportunity
command exists
attempting to investigate such DARPA is already proceeding to other in is
command and control applications.
develop testbeds whereby packet switching technologies and related technologies can be experimentally
employed There
cooperation with one or more of the military services. a clear requirement for improved
command and control and the the ARPANET provides a
packet switching technology developed in
major opportunity to make progress towards this goal.
11-28
Report No. 4799
At
deep
technical
level,
the
proper
design
of host to
operating systems for efficient and cost effective connection networks is still in the area of significant project,
research and the network
development opportunity. connections more detailed connections. The were
In the
ARPANET
"add-ons"
and it of how
is clearly time to mount the best to accomplish such
investigation
techniques for remote control of computers in the field probably more broadly
developed within the ARPANET project are
applicable to the management of computer resources in other areas of the Defense Department. These remote management techniques ARPANET
represent another opportunity which has grown out of the experience. It was earlier indicated that it
was not practical for the
Network Information Center in the ARPANET to keep current on-line detailed descriptions of program resources available host and community. development This within the
difficulty in turn represents a research for the future. Specifically,
opportunity
research computer
and development is required on how to properly describe programs such and how to create standards for such
descriptions
that it
will be easier to create compendia of despite the sharing great problem success still
available resources. of the ARPANET,
In other words, the basic
resource
11-29
Report No.
4799
represents a fertile area for research and development. the networking technology itself is "given",
Now that at
attempts
description and documentation of host resources might more easily yield to a research and development effort.
IJ
11-30
Report No.
4799
5.
5.1
PROGRAM IMPACT AND ASSESSMENT OF TECHNOLOGY DEVELOPED

Service Use of Technology
The
ARPANET technology is being succe.sfully transferred to Not only was it possitle to transfer the
the rest of DoD.
ARPANET itself to the Defense Communicationr
Agency (Code
535),*
but the Defense Communications Agency has already embarked on the procurement of its primary backbone major communications system
AUTODIN II -based very specifically on the
of the future --
packet
switching
technology step
developed all of three
in
the
ARPANET. are
Even
beyond this very major involved in
services
actively
investigations
packet switching technology for
their specific needs. 5.2 Impact on Non-DoD Programs In just the very short ARPANET time since the inception of the
this technology has already resulted in the formation of a private sector development
networks. Two
a new industry:
packet
of
"value
added"
and
switching
corporations,
Telenet
Tymshare,
are currently marketing packet switched
communications
to the general public as common carriers under the Communi'.,ations act of 1934. This program therefore has also had direct and sector. In addition,
immediate exploitation in the commercial

*
Now DCA Code 252 (December 1981).
11-31
Report No.
4799
all
over the worlc new communications systems are being designed packet switching technology
--
and built to take advantage of the demonstrated by the ARPANET project. Great Britain, France and Canada
At least three countries --
have major national PTToperating or
sponsored packet switching networks either already under
development and many other countries are actively pursuing
this technology. 5.3 Applications of the Program Results The most specific result of course, been the ARPANET itself; the ARPANET and the Program has, of is
ARPANET itself the
currently fully operational under the management of Communications Agency and is actively serving
Defense of
thousands
individuals on a daily basis. 5.4 Advance in the State-of-the-Art in
The ARPANET program has represented a first-rank advance the state-of-the-art
of communications and the state-of-the-art The greatest advance reliable, has been in the
of computer technology. provision of
cost effective, but very
high per-formance digital advances
communications, have also
significant
state-of-the-art
taken
place in many other areas, multiprocessor programs,
such as topological protocols for and
optimization, resource
routing,
technology, network
sharing
between
mail systems,
remote computer management.
11-32
Report No.
4799
6.
BIBLIOGRAPHY OF REPORTS There has been an enormous amount of literature sharing been about the
ARPANET
in
particular, general.
and
about
resource
computer formed in
networks in the
Literally an industry has
space of two-thirds of a decade and the amount of literature
reflects this really unusual metabolism.

The initial May of 1970 at seminal papers on the ARPANET were presented the are in.
AFIPS Spring Joint Computer Conference in published in the Proceedings Vol 36, of that
Atlantic City and conference (AFIPS
Conference Montvale, was held
Proceedings,
AFIPS Press, early
210 Summit Avenue, ARPANET session
New Jersey at the
07645).
Another
1972
Spring Joint C~,mputer are published in
Conference in
Atlantic City and these
papers
AFIPS Conference Proceedings, Vol. 40. papers represent a sensible introduction about and plans for the ARPANET.
A
These two early sets of to the early notions
sizeable bibliography and index to publications about the 1976 with DARPA support: "Selected Becker This about
ARPANET was published in
Bibliography and Index to Publications About the ARPANET", and Hayes Inc., February 1976, 185 paias, AD-A026900. listing
document represents the most ARPANET publications, but it
complete is
availa.le
a bibliography only and does not of the many references
provide help in
trying to select which
11-33
Report No. 4799
would be suitable to look at in what order. on the literature of resource ARPANET) sharing has been
Another bibliography computer issued by networks in the U.S.
general (not just the Department of Commerce, Bibliography Networks", document what is NBS is of the Special also not
National Bureau of Standards: Literature on Resource 384,
"Annotated
Sharing Computer 1976. This
Publication
revised
very useful in helping the reader decide not. which deal
important and what is
Several volumes of reprints have been published with computer networks but which in general attempt to (rather collect than
the ARPANET the
specifically),
together
important
papers
themselves
and provide a much easier entry to

(1) "Advances in
the literature than the large bibliographies.:
Computer
Communications",
Dedham,
Wesley W. Chu,
Artech House,
1974; (2)
Inc.,
610
Washington St.,
Massachusetts
02026,
"Computer
Communications", Lucky, 10017, Blanc York, IEEE 1975; and
edited by Paul 345 East
E. 47th
Green,
Jr.
and
Robert
W.
Press, and (3) Ira W.
Street,
New York,
New York P.
"Computer Networking",
edited by Robert
Cotton, 1916.
IEEE Press, 345 East 47th Street, New
New York 10017,
A very hefty, but fairly readable
compendium
with
very
large list of references is "Infotech State of the Art Report 24, Network Systems and Software", Infotech International Ltd.,
11-34
Report No.
4799
Nicholson House, document
Maidenhead,
Berkshire,
England,
1975.
This
the ARPANET, but it tries deals with far more than just other current work as of 1975. to put the ARPANET in context with There are three important been prepared for the reference documents which have by the
Defense
Communications
Agency
Menlo Research Institute, Network Tnformation Center at Stanford addressed to 94025 which are specifically California Park, (1) "ARPANET Resource Handbook", various aspects of the ARPANET: NIC Protocol Handbook", "ARPANET NIC 39335, December 1976; (2) (3)"ARPANET Directory", NIC 36437, 7104, Revision 1, April 1976; July 1976. A textbook on computer networks is John Davies Wiley, and Barber, 1973. A
"Communication Networks for special issue of
Computers",
Communications the IEEE proceedings on Packet 1978.
was issued in November,
11-35
Report No. 4799
Inc. Bolt Beranek and Newman
CHAPTER III:
PROJECT A HISTORY OF THE ARPANET
~1
I<
I"
II
tt-
SA
Report No.
4799
1.
HISTORY The DARPA Computer Network, or ARPANET as it has come to be
called,
consists of IMPs,
lines,
and hosts as shown in Processors)
Figure 1. small,
The IMPs (short for special-purpose lines.
Interface
Message
are
computers
connected
to each other by telephone collection of computers
The hosts are a
heterogeneous
IHO St]IHOST!
HOlST
PHONE
LINES
Figure 1
--
IMPs,
Lines,
and Hosts
used
for
variety
of
applications. through
The
IMPs
provide
communications each other,
subnetwork
which hosts communicate with system provides a
much as the commercial telephone
111-2
Report No.
4799
communications other words,
subnetwork
through which humans communicate. utility
In
the IMPs and lines make up a communications Each host is
of which the hosts are users. one IMP may have several When is data is
connected to one IMP;
hosts connected to it. the data
to be sent from one host to another,
broken into discrete entities called "messages" which is of also called the "source host".
at the sending Each message to
host,
consists
some data and an address. to be sent, that
The address specifies is, the
which host the data is host". its IMP, Successive where they
"destination
messages are
are passed from the source host to into smaller entities called
broken
"packets", The they
each of which carries the same address as the message. are routed from IMP to IMP across the network until at the IMP to which the destination host is
packets arrive
connected, packets, The
where the original messages are reconstructed from the and passed to the destination host. ARPANET was conceived in the middle to late 1960s as a Techniques (DARPA) of the r
project to be sponsored by the Information Processing Office of
the Defense Advanced Research Projects Agency Department of Defense ir' 1969. By (DoD). Construction
of the U.S. network
began
1975 the network had gone through intents and purposes
several stages of development and for all
had become an operational Department of Defense computer network.
111-3
Report No.
4799
In 1975, U.S.
control of the network was transferred from DARPA to the Communications Agency, an agency better suited to
Defense
the administration of a working facility. The ARPANET is a computer major development Our why it purpose in here the evolution of
communications.
is to present the build minor

its
history of the ARPANET: the major design
was built, who helped (and some of the
it, ones)
deci3ions
its
associated with it, and why it is
evolutionary development,
maturity,
important.
111-4
Report No.
4799
1.1 1.1.1
Background The RAND Study of Distributed Communications Networks One of the most important early studies of computer networks
was
performed
by
Paul
Baran
and Many
his
colleagues at the RAND central to the
Corporation in the early 1960s.
concepts
later development of the ARPANET and other computer networks were first described in the series of reports published by RAND in
1964 (a list end of this
of these reports is given in the bibliography at the subsection). These ideas include the improved
reliability of a distributed network structure over a centralized or star network and over so-called decentralized networks made up of a collection of smaller star networks. undertaken, determine expected including how to be simulation a of Extensive studies were some grid networks, could to be
"survivable"
distributed
network
after heavy node and link failures.
This study a high
was particularly concerned with the question of percentage of the
keeping
network available and performing well in the view of
face of enemy attacks on the network# from the point of its suitability for Department of Defense applications. In specifying closely
the engineering details of what was Block Network", Baran
called the "Distributed Adaptive Message

anticipated many of the developments in
practical
networks that
came a full decade later.
In the
Distributed
Adaptive
Message
111-5
Report No. 4799
Block
Network, of
"multiplexing differing
is
station"
connects
up to 1024 Automatic
the network links
terminals
widely
characteristics.
integrated into
user-to-user
cryptography
switching technique to ensure efficiency. and low-cost micrrwave
Both satellite
relay systems are suggested as techniques
for providing the npt-.'ork with very high data rate circuits. The a packet of up to concept of a,"mesrav block" .s introduced: 1024 bito of header and data, which is the unit of data
aspects
transferred in of this study
Lhe network. is
One of the most interesting
that 1t concluded
that a large-scale digital
transmission network cost-effective,
was
not
only
feasible
but
also
highly
and proposed that many of the switching functions Baran was considering ways of making and so preferred simple solutions
be implemehted in hardware. extremely reliable
networks,
and reliable hardware where possible. The following bibliography includes the entire set of eleven reports in the original RAND study as well as two published papers resulting from that set and trom two later reports. is included in An
annotated version of this bibliography Routing Algorithms for
"Adaptive (John M.
Distributed Computer Networks" 2831, May 1974, pp. 14-17).
McQuillan,
BBN Report No.
11
Report No.
4799
Bolt Beranek and Newman Ino.
Bibliography P. Baran, "On Distributed Communications: I. Introduction to Distributed Communications Networks," August 1964, 37p. RAND Corp. Memo RM-3420-PR,
S. Boehm and P. Baran, "On Distributed Communications: II. Digital Simulation of Hot-Potato Routing in a Broadband Distributed Communications Network," RAND Corp. Memo RM-3103-PR, August 1964,
4
9p.
J. W. Smith, "On Distributed Communications: III. Determination of Path-Lengths in a Distributed Network," RAND Corp. Memo RM-3578-PR, August 1964, 91p. P. Baran, Precedence, 1964, 63p. "On and IV. Priority, Distributed Communications: Overload," RAND Corp. Memo RM-3638-PR. August
P. Baran, "On Distributed Communications: V. History, Alternative Approaches, and Comparisons," RAND Corp, Memo RM-3097-PR August 1964, 51p.
P. Baran, Microwave,"
P. Baran,
"On Distributed Communications: VI. Mini-Cost RAND Corp. Memo RM-3762-PR, August 1964, 101p.
"On Distributed Communications: VII. Node," Tentative
Engineering
Specificatio,'
and
8 5p.
Preliminary
Design
RAND
High-Data-Rate Distributed Network Switching
for
Corp.
Memo RM-3763-PR,
August 1964,
P. Baran, "On Distributed Communications: VIII. The Multiplexing Station," RAND Corp. Memo RM-3764-PR, August 1964, 103 p. P. Baran, "On Distributed Communications: IX. Security, Secrecy,
and
Tamper-Free
Considerations,"
RAND
Corp.
Memo RM-3765-PR, RAND
August 1964, 39p.

P. Baran, "On Distributed Communications: X. Cost Analysis," Corp. Memo RM-3766-PR, August 1964, 21p.
P. Baran, "On Distributed Communications: XI. RAND Corp. Memo RM-3767-PR, August 1964, 23p. Summary
Overview,"
P. Baran, "On Distributed Communication Networks," Transactions on Communications Systems Vol. CS-12, March
pp. 1-9.
IEEE 1964,
111-7
Report No.
4799
emo and R. L. Mobley, "Adaptive Corp.M Motn B. W. Boehm Communications SYstems" RAND
Distributed February 1966, 78p.
iqe
fo47-r,
Simulation of Adaptive L. Mobley, "A Computer R. RAND and Boehm W. B. Communications Systems," Distributed for Routing Techniques February 1966, 35p. Corp. Memo R14-4782-PR, for "Adaptive Routing Techniques on Mobley, L. R. and Transactions B. W. Boehm IEEE Systems," 3, June 1969, pp. Distributed Communications Vol. No. COM-17, Technology, Communication
340-349.
.1
.4
IH
1I1-8
Report No.
4799
1.1.2
The Lincoln/SDC Experiment The notion by of J.C.R. linking computers into a network was
envisioned reality.
Licklider long before the ARPANET become a director of DARPA IPTO. and his colleagues at Computer were
Licklider was the first Thomas of Marill (in
"In 1965
Corporation
America
Cambridge,
Massachusetts)
commissioned by M.I.T. computer networking.
Lincoln Laboratory to study the concept of The primary technical contact at Lincoln the
Laboratory was Lawrence Roberts,
who played an active role in in fact,
network study; and the contract was, the Laboratory's DARPA contract. and a report of on the
a subcontract under late 1965
The study was done in
study was issued in Computers",
1966 ("A Cooperative Marill, 11, June 1, Computer 1966; a and
Network
Time-Sharing of America, same also
Thomas
Corporation
Technical Report No. name authored by
later paper of the Lawrence Roberts
Thomas
Marill
appeared in
the Proceedings of the AFIPS pp. 425-431). The report
1966 Spring Joint Computer Conference, examined the basic
idea of computer networking, software
considered the problems, network and be
available communications techniques and recommended constructed. computers, that The a three-computer suggested
experimental linking three
report
existing the
the AN/FSQ-32 at Systems Development Corporation, and Lincoln Laboratory's
IBM 7094 at MIT's Project MAC,
TX-2.
II I-9
Report No.
4799
Later
in
1966,
CCA
received another contract to carry out the The Q-32 and TX-2 were in Later a fact small
linking of the Q-32 and the TX-2. linked together, Digital network,
and the link was demonstrated.
Equipment Corporation machine at DARPA was added to this by now known that The as "The Experimental Network". It is
noteworthy directly,
Experimental Network linked host computers
and did not use IMPs.
Ii
III-10
S" ... .... . . '.... -'i.. ....""..-" -
' ...
Report No.
4799
1.1.3
The NPL Data Network Another early of the major network was development undertaken England, system under design at which the the affected National leadership
development
ARPANET
Physical Laboratory in Middlesex, of D. W. Davies. The broad
of the NPL Data and bears and
Network,
as it
was called, was first published in 1967,
a resemblance to the network proposed by Paul Baran at RAND, to the ARPANET. The network NPL and Data was
Network was specified to be a to have a hierarchical
packet-switching structure. with It
was proposed that "local networks" be constructed "interface computers" which had responsibility for
multiplexing among a number of user systems and for communicating with a "high level nodes" network". connected The latter would be constructed together with megabit rate
with "switching
circuits.
Considerable
detail about the NPL Data Network may be found by two of the network's designers, Davies and 1973). A
in the textbook, written -entitled D.L.A. Communications Barber, of John
Networks for Computers (D.W. & Sons papers publishers, resulting
Wiley
bibliography
published
from the NPL Data
Network effort follows.
iIi
... . mrlmm
Report No. 4799
Bibliography T. and P. Scantlebury, R. A. Bartlett, D. W. Davies, K. A. Wilkinson, "A Digital Communication Network for Computers Giving Rapid Response at Remote Terminals," ACM Symposium on Operating Systems Problems, October 1967, 17p. Bartlett, R. A. Scantlebury, and P. K. A. Real-Time for Network Communication International Conference on Communications, Wilkinson, "A Data IEEE Computers," U.S.A., June 1968. T.
Networks to Serve Rapid Response "Communication D. W. Davies, Vol. 2 1968, Computers," Proceedings of the IFIP Congress Hardware Applications, pp. 650-658. K. A. Bartlett, "Transmission Control in a Local Data Network," Vol. 2 - Hardware Proceedings of the IFIP Congress 1968, Applications, pp. 704-708. "The Principles of a Data Communications Network D. W. Davies, IFIP of the for Computers and Remote Peripherals," Proceedings Congress 1968, Vol. 2 - Hardware Applications, pp. 709-715. Wilkinson, and K. A. Bartlett, "The T. P. A. Scantlebury, R. Communication Design of a Message Switching Centre for a Digital 2 Vol. 1968, of the IFIP Congress Proceedings Network," Hardware Applications, pp. 723-733. in P. T. Wilkinson and R. A. Scantlebury, "The Control Functions 1968, Congress Proceedings of the IFIP a Local Data Network," Vol. 2 - Hardware Applications, pp. 734-738. Colloque D. W. Davies, "A Versatile Data Communication Network," Paris, March 1969, pp. sur la Teleinformatique, International
&461-467.
Scantlebury, A. R. and D. V. Blake, Barber, A. D. L. for Data Interface of the British Standard "Implementation Colloque Data," Digital of and Acceptors Exchange between Sources pp. March 1969, Paris, International sur la Teleinformatique, 807-816. Bartlett, R. A. Scantlebury, and P. T. Wilkinson, K. A. Transmission over Half-Duplex on Reliable Full-Duplex CACM, Vol. 12, No. 5, May 1969, p. 260. "A Note Lines,"
D. L. A. Barber, "Experience with the Use of the British Standard Interface in Computer Peripherals and Communication Systems," ACM Symposium on Data Communication, Pine Mountain, October 1969. III-12
Report No.
4799
Bolt Berarnek and Newman Inc.
for the Local Area of a Data "A Model R. A. Scantlebury, and Hardware Organization," Communication Network - Objectives Mountain, October 1969. ACM Symposium on Data Communication, Pine a Data "A Model for the Local Area of Wilkinson, T. P. on Symposium ACM Communication Network - Software Organization," 1969. Data Communication, Pine Mountain, October "The NPL Data Network," Barber and D. W. Davies, A. D. L. Automation, Laboratory On Conference Proceedings of the Novosibirsk, October 1970. Switching "The Control of Congestion in Packet D. W. Davies, on Symposium of the Second ACM/IEEE Proceedings Networks, Systems, Communication of Data the Optimization Problems in Vol. of IEEE, Transactions in also 46-49; pp. October 1971, COM-20, No. 3, June 1972. "The Design of a Switching R. A. Scantlebury and P. T. Wilkinson, Computer Services by Other Access to System to Allow Remote of the Second Proceedings Devices," Computers and Terminal the Optimization of Data in ACM/IEEE Symposium on Problems also in 160-167; Pp. October 1971, Systems, Communication 1972. 3, June Transactions of IEEE, Vol. COM-20, No.
W.
ACM Principles," on Isarithmic 1973. November Florida, Symposium,
L.
?rice,
Controlled "Simulation of Packet-Switching Networks Communications

Data Third op. 4-49.
Physical and P. T. Wilkinson, "The National R. A. Scantlebury ICCC the of Proceedings Laboratory Vata Communication Network," 229-238. Conference, Stockholm, August 1974, pp.
D.
Data Communication Networks," IFIP 1974, pp. 147-150.
W.
Davies,
"Packet
and Future Switching, Message Switching Stockholm, August

Congress,
W.
Isarithmically Controlled L. Price, "Simulation Studies of an Proceedings of the Network, Store and Forward Data Communication
IFIP Congress, Stockholm, August 1974, pp. 151-154.
111.l3
Report No.
4799
1.2
The Events of 1967 and 1968 The years 1967 and 1968 were spent promoting interest in the
ARPANET
project
both
within
the
government
and
the
with
IPTO
contractors, writing a
deciding the fundamental structure of request for quotation,
network, and
selecting a contractor,
other related 'activities.
In early 1967,
work began on the conventions to be used
for
exchanging messages between any pair of computers in
the proposed
network,
lines that
and also on consideration of the kinds of communications

data sets to be used. communication In particular, "protocol" it was decided include
and the
inter-host
would
conventions
for character and block transmission,
error checking Frank
and retransmission,
and computer and user identification.
Westervelt,
then of the University of Michigan,

an AA-_h"
wrote a position
"Communication and
paper on these areas of communication, Group"
was selected from among the institutions represented,
a meeting of the group scheduled. The plan considered throughout much of the Michigan was and to data connect sets meeting
all of the computers by dial-up telephone lines so as any to allow any computer to establish
communication
with
other it up
computer on the
using a line-switching telephone). A small
technique (i.e.,
calling
program
in
each
computer
would
interface to the data set and
111-14
Report No.
4799
phone line and when given a small interface
message
to
-another
computer,
the
program would perform a "message-switching" and the other then of point
transmission function, deciding how to actually reach computer and transmitting the message to it.
Wes Clark, some
Washington University, in the meeting that
is credited with proposing at
a small computer be inserted between each phone line. This concept was
participant's computer and the

further refined within DARPA,
and the concept of the Interface
Message Processor or IMP emerged. The IMP checking, the would perform the functions of dial-up, error
retransmission,
routing,
and verifications on behalf of we shall lines hereafter and data call sets
participants'
computers
(which
hosts). would
Thus the IMPs plus the telephone constitute a
"message-switching network". would define the
The protocols communications
which were to be formats between
established the IMPs.
The interface between a host and an
IMP would be a digital interface of a much simpler sort requiring no host consideration routing. It was IMP of error checking, retransmission, and of
clearly was the
noted that the major disadvantage cost of installation of
inserting the computer
another
beside each host.
The major advantage of inserting the
IMPs
was
recognized
to
be
design
the
could
fact
be
that
unified,
straightforward
network
made and implemented
without undue consideration of the variations and constraints
of
111-15
Report No.
4799
the host computer.
Further,
an the network evolved,
it
would be
much simpler to modify the network of IMPs than to modify all the host computers. communications It Finally, burdens the IMPs would relieve the hosts of the they were initially scheduled to carry. be located at
was also noticed that if connection
necessary IMPs could within
strategic
points
the network to concentrate a network a of IMPs was
messages over cross-country phone lines, likely to be implemented faster of than
network of directly provided a distinct
connected hosts, network publicly. entity
and the network which
IMPs
would be useful in
presenting the network
By October 1967 the proposed network was becoming the ARPA Computer Network, discussion or ARPANET for short. at that time
known
as
A variety of message message and 50 Kb
topics were under formatting, propagation, IMP-to-host
including and
message queuing,
protocols, error It
dynamic control, was
routing
measurements, decided that
communication.
communications lines would be used because of the vastly improved response time which could be obtained with these lines as opposed to the previously proposed 2.4 Kb lines. be leased, The 50 Kb lines were to The nature of 50
eliminating the slow dial-up procedure.
the telephone tariffs Kb. lines
available to the government made use of With each IMP normally
affordable.
permanently lines,
connected to at least two other IMPs via the leased 50 Kb
111-16
Report No.
4799
the IMPs were to use store-and-forward
techniques to provide fast
message handling.
bits from its
Each IMP was to accept messages of up to 8,000

host
computer
and to break this
into 1,000-bit
packets.
Each packet was to be treated independently and
routed
on one of the two or more inter-IMP lines. at an IMP, further it was to be stored, At its
When a packet arrived and routed on to a
error checked,
It.?.
destination, assembled
packets would be held until an and then delivered to the it
entire message could be destination host. was expected that
With an average of say three lines per IMP,
approximately three store-and-forward stages a message from any one of twenty
would be necessary to get locations to any other. In July 1968, an
RFQ
for
the network was mailed out to
prospective bidders.
Twelve proposals were received by the Agent
(DSSW).
Four bidders were rated within the zone of contention to technical briefings
receive the IMP contract, and supplementary were requested from each of these bidders.
Final negotiations chosen in the
were carried out with two finalists, and one was

week before Christmas, 1968.
The contract was awarded and work
began the second day of the New Year in 1969.
111-17
Report No.
4799
1.3
Key Aspects of the RFQ It was specified that responses to the RFQ would be
evaluated on four criteria in 1. 2. Understanding and problems involved.
addition to cost: depth of analysis of technical
Availability of qualified, experienced personnel for assignment to software, hardware, and installation of the system. Estimated functional performance and choice of hardware. General quality, responsiveness, commitment to the network concept. RFQ had and corporate
3. 4.
The
provision for a bidders conference and stated to discuss
that there would be no other opportunity for bidders technical issues with the government.
Bidders were asked to but to price
provide a system design for a nineteen-IMP network, a four-IMP network. A thirteen-month
performance period was and The
requested to include design,
construction of a prototype IMP, operational IMPs.
implementation and installation of four four IMPs were to
be installed nine months after start of the in the field for
contract with the contractor supporting them three take months after installation. full system responsibility,
The contractor was required to although subcontracting a
portion of the work was a possibility.
111-18
Report No.
4799
I.
Network Description A. Introduction B. Functional Description 1. The User Subnet 2. The Communication Subnet
C. Functional Description of the IMPS 1. Breaking of Messages into Packets 2. Management of Message Buffers 3. Routing of Messages 4. Generation. Analysis and Alteration of Formatted Messages 5. Coordination of Activities with Other IMPS 6. Coordination of Activities with its HOST(s) 7. Measurement of Network Parameters and Functions 8. Detection and Disposition of Faults 9. IMP Software Separation Protection The HOST-IMP Interfaces The IMP-CARRIER Interfaces Network Performance Characteristics 1. Message Delay 2. Reliability 3. Network Capacity 4. Network Model HOST-HOST Characteristics IMP-Operator Interface
D. E. F.
G. H. II. III.
Network Contractor Performance Elements of System Design
Appendix A. ARPA Network Nodes B. ARPA Network Topology C. IMP Delivery Schedule D. Input and Output Facilities for the IMP Operator E. ARPA Network Data Rates Between Nodes in Kilobits/sec.
F.
Data Communications Conventions

Routing
G.
Figure 2:
Table of Contents from RFQ Statement of Work
111-19
Report No.
4799
The
IMP
specification
clearly
delineated the division of

and telephone
responsibilities company. and
among host sites,
IMP contractor,
Each individual host site was responsible for designing for its own convenience the the hardware and and the The
implementing
software necessary to attach the host to
network,
hardware and software to utilize other hosts on the network. telephone company
was to be responsible for providing necessary and line conditioning equipment utilized IMP contractor was to by
circuits, data sets, the network. The
be responsible for
providing necessary hardware and software to connect IMPs to each other using the circuits supplied by the telephone company and to connect IMPs to hosts, as well as providing hardware and software
necessary to implement the procedures which allowed creation of a network of IMPs capable of forwarding messages from one another. The functional description of an IMP specified the use of would be broken into host to
"'essages not longer than 8192 bits which

packets of not more than 1024 bits.
Messages were limited in Shorter packets were error with the
size to make them manageable for the hosts. used to reduce the probability of attendant necessity for
transmission It
retransmission.
was noted that IMP permit speed
provision of message and packet buffer space would conversions delays, to take place,
provide queuing space in in the event of
the face of erroneous
and permit
retransmission
111-20
Report No.
4799
transmission.
routing algorithm was hypothesized which would IMP and line
take into account the connectivity of the network, busyness, and message priority, IMP and on a use path
this information to to the ultimate
forward a packet to the next destination; periodic
updates
bajed on exchange of routing and
loading
information
with
other
IMPs
and
hosts
was
also
hypothesized.
An IMP was to coordinate its activities with other IMPs were to

but to
IMPs and its hosts and perhaps other special hosts.

take
messages from a local host at the IMP's convenience,
send messages to a local host at IMPs were to be able and the at to
the
host's
convenience.
The
selected trace the The
times to measure selected movements of selected
network messages
parameters through
network.
data resulting from these a

of IMPs
measurements and tracings was to be capable of transmission to

host, and the measurement activity was to be IMP. host, capable The
initiation and termination by a host or another were to detect and recover from
various IMP,
and line
failures.
examine,
In particular, it was to be possible to

or reload IMPs from selected network hosts.
stop,
start,
it
Finally,
was
thought
that
at
each
code
IMP
to
site, it would be possible for

be provided by host site
special
host-specific and thus it portion
programmers, IMP from
was desirable to protect the rest of the that the host personnel could access and
the
program.
111-21
Report No.
4799
There were
host-to-IMP
two
particularly
1)
interesting
aspects
of
the
interface:
a standard host interface was to be
specified rather than a different one

bidder was to consider the cost only
for
of
each
host;
2)
each
providing interfaces to one host interface was
multiple hosts per IMP, required; and 3)
although
sufficient program space was to be left to do of binary
host-specific character code conversion and repacking
messages.
The interface between an iMP and its telephone lines was detect CRC, control a
required to have hardware to characters, calculate 20 and
sense check
characters, the 24-bit
provide and was
real-time clock with fault and status
microseconds
resolution, the IMP
provide to be six.
information.
Further,
optimized to handle three lines but be capable of Several network performance
handling
characteristics were specified.
The average message delay for a short message to go from a source IMP to a destination IMP was to be less than one-half second for
fully
loaded
network.
was to be
The probability of lost messages and

very third low. in Interestingly, network
message errors capacity was
considered
order of importance and was be input at every
defined to be the maximum bit rate that can node and still
have the meSsage delay remain less than one-half A network model
second;
a 20 Kb network capacity was hoped for.
was presented.
111-22
Report No. 4799
Host-to-host
traffic
flows be
were a
estimated
and
it
was of
hypothesized that there traffic length,
would
trimodal
distribution
type (high rate and short length, and low rate and long length). the
medium rate and medium
In addition to considering connected to an IMP,
option
of
multiple
hosts
the bidder was also asked to consider the to new facilitate software, simultaneous IMP
provision of memory protection operation and checkout of
and to consider what
additional hardware and software would be necessary for an IMP to

provide a terminal concentration capability for its the network (i.e., no host, just terminals). host or for
II-2
Report No.
4799
1.4
Chronological Development,
1969 to 1975 the first
Within a year after the award of the IMP contract, IMPs were installed in the field.
Hosts were connected to these was undertaken.
first IMPs and a series of network measurements Host software
was written, hosts began to communicate with each and gradually the ARPANET
other, more IMPs and hosts were added, became an operating entity.
After six years of development and by
operation the network was no longer best suited to management an agency with the charter to
sponsor advanced research and to the
development, Defense
and thus network management was transferred Agency.
Communications
In the following subsections we
describe the happenings of the years 1969 to 1975.
I1I-24
Report No.
4799
1.4.1
The Groups and the Key People The ARPANET and development was a all joint effort to of many DARPA's further,
individuals dire.tion. it is
institutions,
responsive
Before we describe the ARPANET
development
best to list
the principal "players" and briefly describe
their areas of responsibility.
11
!i'I
!
III-25
F77--
Report No.
4799
1.4.1.1
Management and Administration of the Network: DARPA IPTO, DSS-W, RML, and DECCO the development was as Robert well as
Naturally, of the network. Taylor, who
DARPA IPTO played a major role in The director of IPTO provided the at the
time
necessary
support
encouragement in was the initial promoted the
helping to fund the network.
Lawrence
Roberts Roberts
program manager for the network program. network, made certain key architectural the IMP
decisions, and
led the evaluation team which selected selected other involved contractors. director of IPTO. While
contractor
He also succeeded Taylor as
IPTO set policy for the network, etc.,
made decisions about run the network
who would join the network, day by day. the out network, much of
IPTO did not
BBN provided day-by-day operation and maintenance of and BBN and the other contractors the day-by-day business of the involved carried network among
themselves without need for daily IPTO supervision. Initially IPTO itself filling out took care of ordering telephone lines,
forms which were sent to DECCO for procurement from telephone companies. of Also, the IPTO
and execution by the various initially did its own
technical
monitoring
various as the
contractors associated with the ARPANET; procurement agency for the contractors.
DSS-W was used Eventually,
attempting
1II-26
Report No.
4799
to rid
itself
of
the
routine, and
tedious
aspects
of
ordering of
communications
lines
providing
technical
monitoring
routine dealings the DSS-W functions, shifted IPTO contractors, Range technical monitoring to the with DECCO, and some contractor Force Base in Florida; in Laboratory at Patrick Air Measurements RML also had a capability, procurement a having addition to technical support capabilitY. of the IPTO staff who have were several other members Roberts. of the ARPANET besides management the in prominent been There
These
have
included
A.
Blue,
B.
Wessler,
D.
Carlstrom,
S.
Crocker,
B. Dolan,
C. Fields,
S. Walker,
and D. Russell.
a strong technical IPTO often played number As mentioned above, of the IPTO staff wrote a role in the ARPANET, and members
of papers describing the ARPANET activity.
Several of these
papers are listed in
the following bibliography.
111-27
Report No. 4799
Bibliography Network T. Marill and L. G. Roberts. "Toward a Cooperative Time-Shared Computers," Proceedings FJCC 1966, p.425-431. of
L. G. Roberts, "Multiple Computer Networks and Intercomputer Communication," ACM Symposium on Operating System Principles, October 1967, 7p. L. G. Roberts and B. D. Wessler, "Computer Network Development to Achieve Resource Sharing," Proceedings SJCC 1970, p.5 4 3-5 4 9. L. G. Roberts, L. G. Roberts, 1971, p. 4 - 8 . "A Forward Look," Signal, August 1971, p.77-81. Fall
"ARPA Network Implications,"
EDUCOM Bulletin, Future Plans,"
L. G. Roberts, "ARPANET: Current Status, Spring Conference, April 1972, p.7-12.
EDUCOM
L. G. Roberts, "Network Rationale: A 5-Year Proceedings COMPCON 1973, February 1973, p.3- 6 .
Reevaluation,"
L. G. Roberts, "Dynamic Allocation of Satellite Capacity through Packet Reservation," Proceedings NCC&E 1973, p.711-716.
L.
G.
Roberts,
"The
ARPA
Net,"
in
Computer-Communication
Prentice-Hall, 1973.
Networks,
N. Abramson and F.
Kuo (Eds.),
S.D. Crocker, J.B. Postel, J.F. Heafner, R.M. Metcalfe, "Function-oriented Protocols for the ARPA Computer Network," AFIPS Conference Proceedings 40, May, 1972, pp. 271-279.
111-28
Report No.
4799
1.4.1.2 Led (MAC) to its
The Network Analysis Corporation by Dr. Howard Frank, Long Island, the Network Analysfs Corporation was put under contract by DARPA
of Glen Cove, specify cost,
the topological design of the ARPANET and to analyze and reliability characteristics. of the parameters of a or
performance,
In the process of evaluating any particular network design,
such as cost,
reliability,
delay,
throughput,
through the
it
is necessary
proposed
to
simulate
Then,
the
flow
of
traffic
network.
the design may be altered In this procedure, it
slightly to improve one of these measures.
is
important to have a facility traffic will
for
specifying
the
routes
on
which
flow in the network, and the procedure must repeated so often in the
not be too complex since it must be iterative methods design process. for incremental
MAC has developed some very efficient changes to a shortest-path routing
algorithm as the network topology is changed. discovered

available,
Further, they have
faster shortest-path algorithm than was previously

the low connectivities usually
taking advantage of
present in most practical communications networks.

The following bibliography lists much of the published work
by MAC related to the ARPANET.
111-29
I,
Report No.
4799
Bibliography NAC First Semiannual Technical Report for the Project, "Analysis and Optimization of Store-and-Forward Computer Networks," June 1970, 62p. NAC Second Semiannual Technical Report for the Project, "Analysis and Optimization of Store-and-Forward Computer Networks," January 1971, 96p.
NAC Third Semiannual Technical Report for the Project, "Analysis and Optimization of Store-and-Forward Computer Networks," June
1971, 109p. NAC Fourth Semiannual Technical Report for the Project, "Analysis and Optimization of Store-and-Forward Computer Networks," December 1971, 1 2 3p. NAC Fifth Semiannual Technical Report for the Project, "Analysis and Optimization of Store-and-Forward Computer Networks," June 1972, 92p. NAC Final Technical Report for Optimization of Store-and-Forward 1972, 120p. the Project, "Analysis and Computer Networks," October
H. Frank, I. T. Frisch, and W. Chou, "Topological Considerations in the Design of the ARPA Computer Network," Proceedings SJCC 1970, p.581-585. H. Frank, I. T. Frisch, R. Van Slyke, and W. S. Chou, Design of Centralized Computer Networks," Networks, Vol. 1, 1971, p.43-58. H. Frank and W. Chou, "Routing in Vol. 1, No. 2, 1971, p.99-112. H. Frank, "Computer Network Convention Record, March 1971, p. H. Frank Networks,"
2 20
"Optimal 1, no. Networks,
Computer Networks," IEEE
Design," -221 .
Internation:'.
Networks,
England,
and W. Chou, "Throughput in Computer- Communications International State of the Art Report no. 6; Computer
Infotech
Information
Ltd.
Maidenhead,
Berkshire,
Part
1971,
p.493-512. Analysis:
R. Van Slyke and H. Frank, "Network Reliability I," Networks, Vol. 1, No. 3, 1971, p. 2 79- 2 90.
111-30
Report No.
4799
R. Van Slyke and H. Frank, Proceedings Networks," Conference, December 1971,
"Reliability of Computer-Communication Winter ACM Simulation of the 1971 p.71- 8 2 . Networks," p. 6 - 1 1 .
H. Frank and I. T. Frisch, "The Design of Large-Scale Proceedings of the IEEE, Vol. 60, No. 1, January 1972,
R. E. Kahn, and L. Kleinrock, "Computer Communication H. Frank, Practice," and Theory with Experience Network Design SJCC 1972, p.255-270; also in Networks, Vol. 2, No. Proceedings 2,1972, p135-166. W. Chou and H. Frank, "Routing Strategies for Computer Network Institute Research the Microwave of Proceedings Design," Networks and International Symposium on Computer-Communications Teletraffic, April 1972, p.301-309. A. Kershenbaum and R. Van Slyke, "Computing Minimum Spanning Conference, Trees Efficiently," Proceedings of the ACM Annual August 1972, p.51 8 -5 2 7. "Topological H. Frank and W. Chou, Networks," Proceedings of the IEEE, Vol. 1972, p.1385-1397. Optimization of Computer November 60, No. 11,
"Optimal Design of Computer Networks," in Computer H. Frank, Networks, R. Rustin (Ed.), Prentice-Hall, 1972, p.1 6 7-1 8 3. in Routing Policies "Deterministic and Adaptive M. Gerla, Packet-Switched Computer Networks," ACM Third Data Communications Symposium, Florida, November 1973, p.23-28. Slyke, "Simulation of Centralized R. 'Van H. Frank, W. Chou, Computer Communications Systems," ACM Third Data Communications Symposium, Florida, November 1973. p.121-130. W. Chou and A. Kershenbaum, "A Unified Algorithm for Designing Multidrop Teleprocessing Networks," ACM Third Data Communications Symposium, Florida, November 1973, p.148-156. H. Frank, "Providing ACM Third Components," November 1973, p.161-164. Unreliable Reliable Networks with Data Communications Symposium, Florida,
I. Gitman, R. M. Van Slyke, and H. Frank, "On Splitting Random Channels," Proceedings of the Accessed Broadcast Communication on System Sciences. Conference International Seventh Hawaii January 1974, 5p.
111-31
Report No.
4799
1.4.1.3
The Telephone Companies a nationwide communications network means doing further, if the
Building
business with a number of telephone companies; network deal is
to have overseas or foreign components, various international This task carriers was and
one must also national Post which
with
Telephone
Telegraphs.
handled by DECCO,
negotiated with the relevant telephone companies and obtained the specified service at the best price. from UCLA to RAND, for example, In the case of a circuit
most likely the service would be the dominant telephone company
procured from General Telephone, in the Los Angeles area. in the example just
given,
requested
circuit
fell
completely within the jurisdiction of a single telephone company. To handle all instances when the requested service spanned the
jurisdictions of more than one telephone company, utilized their Long Lines division; and in
the Bell System
the case of many of procured the
the ARPANET circuits, service was Long
the company from which DECCO which in requested
Lines,
turn procured the components service from the regional
necessary to make up the telephone companies. For the first
several years of the ARPANET development, to DARPA were, Ken Stanley. in A turn,
the Al
Long Lines customer representatives Fraser, Bill Gordon, and
customer
111-32
Report No.
4799
representative's job is to make the customer aware of of service available Fortunately that
the
kinds
and to keep him happy with the service he for the ARPANET, the Bell System
receives. understood
a customer building a nationwide network needed

grasp of
the assistance of some central individual with a broad
the
requirements
rather
than
having
to
rely
on
the Thus
usual the
miscellaneous dealings with local telephone companies. Long Lines representative,
who from his position in Long Lines
was already in contact with his counterparts in the many regional telephone companies, was permitted to use his network of contacts to provide informal coordination of the entire Bell System
service to, the ARPANET. For instance, installing a telephone circuit between two at both
IMPs requires that the IMPs and the telephone companies
ends
all
be
ready
simultaneously.
It is useless for the IMP make a
supplier and one of the telephone companies to strain to scheduled date. strain date if
the other telephone company cannot make that is useless for the date if telephone companies to
Similarly, it to make a
the IMP supplier cannot.
The Bell
System customer representattve took it upon himself to coordinate all such interdependent events.
willingness to
By virtue of the
Bell
System's
provide this critical coordination,
an extremely between the
smooth and efficient relationship has been built up IMP suppliers, DARPA, and the member companies
of the Bell
111-33
I..
... . .. .
_,
' i i J/ i l
I I'
:I i
Report No.
4799
System.
For a network of the size and complexity of the ARPANET, trouble with the procurement
there has been surprisingly little
and operation of the telephone circuits.
Report No. 4799
1.4.1.4 The
Bolt Beranek and Newman Inc. contract to construct and it Frank was the IMP Inc. for (BBN) the ARPANET was of Cambridge,
awarded to Bolt Beranek Massachusetts, leadership installed, of where Mr.
Newman
carried Once
out in a group under the the first IMPs were
Heart.
BBN continued to play a central role in the evolution operating it and maintaining it as well as doing
of the network, the development
necessary for several major enhancements of its
capability. In addition to Frank Heart, a number of other individuals at The
BBN have been involved with the development of the ARPANET.
names of many of these individuals may be found as authors of the papers on the ARPANET which have come out of BBN. Robert Kahn, deserves particular However, one
individual, several
mention.
After
years
as a principal member of the group working on the from which
network at BBN, he moved to the IPTO office at DARPA he has probably
done more to promote and support the continued
advance of packet-switching technology than any other individual. A bibliography of ARPANET-related reports and papers wri;.ten by members of the BBN staff is included as Appendix A. L
I,
-~-I
111-35
Report No.
4799
1.4.1.5
The Network Information Center with it
The accessibility of distributed resources carries the need for an information service (either
centralized or resources,
distributed) that enables users to learn about A contract was awarded to
those
the Stanford Research Institute to (NIC) to be of
develop and operate a "Network Information Center" established for the ARPANET. 1969, With the
beginning
implementation of the network in the NIC at SRI.
construction also began on
The NIC provided several services. network participants
It
maintained a list
of
and distribution lists network
for various special An archive of
interest groups within the various
community.
document series was maintained.
Documents could be sent to A and
to the NIC with instructions for duplication and distribution the membership or one or more of the ipecial structured system data base NLS) construction, interest groups. manipulation,
highly display
(called A list the
was made available on-line for use on
over the network. hosts throughout
was kept of the resources available network. The various
ARPANET protocol
specifications were maintained on-line at the NIC. The NIC has had a hand in the proauction or distribution of
hundreds and hundreds of documents related to the ARPANET. of these documents describe the activities of the NIC itself
A few or
111-36
Report No.
4799
are
otherwise
of
special
interest
within
the
ARPANET;
bibliography of these follows.
.1
II1-37
Report No.
4799
Bibliography D. C. Engelbart, "Network Information Augmented Team Interaction", Stanford Augmentation Research Center, January 30,
Center and Computer Research Institute, 1971, 105p.
D. C. Engelbart, "On-line Team Environment", Stanford Research Institute, Augmentation Research Center, June 2, 1972, 272p. D. C. Engelbart, "Coordinated Information Service for a Discipline or Mission-oriented Community", Time-sharing: Past, Present, and Future. Second Annual Computer Communications Conference, 1973, pp. 2.1-2.4. Current Catalog of the NIC Collection, NIC No. 5145. 5150.
Current Directory of Network Participants, Network Resource Handbook, Current Network Protocols, NIC No. NIC No. 6740. 7104.
NIC No.
111-38
"Report No.
4799
1.4.1.6 One
The Network Measurement Center of the influential early studies of communications is reported in
networks was performed by Leonard Kleinrock and his 1962 Ph.D. thesis at MIT,
Communication Nets! by Dover
Stochastic New
Message Flow and Delay York, in 1964).
(reprinted
Publications,
This study proved convincingly that message delays network can be made very low, and
a large store-and-forward put to
thus
rest one of the early and persistent objections to Kleinrock considered several and aspects their of the
networking. operation of
communications
networks
underlying Kleinrock
algorithms in is
developing a precise model for networks.
today a faculty member at UCLA. UCLA was selected to be allow used (NMC). to be the site of the first IMP
installation, which was to
early connection of an SDS SIGMA 7 host to support The the tasks of a Network for
Measurement
Center
NMC had the responsibility ARPANET
much of the analysis and simulation of the as well as
performance.
direct measurements based on statistics gathered by While Kleinrock himself was the guiding force
the IMP program. at the NMC,
over the years he had a series of students or staff including Naylor
members who supervised the day-to-day measurement work, Gerald Cole, (each Vinton Cerf, Holger Opderbeck, and
William
obtained
a UCLA Ph.D.,
although not necessarily for their
NMC work).
111-39
Report No.
4799
There has been a series of doctoral di-ssertations written by students at the UCLA School of Engineering work of the NMC. A list and related to the
of of these theses.
as well as other
relevant publications by the faculty and students associated with the NMC, is included in the following bibliography.
111-140
Report Nc.
4799
Bibliography L. Kleinrock, "Communication Nets: Stochastic Message Delay," Dover Publications, New York, 1964, 2 0 9p. Flow and
L. Kleinrock, "Models for Computer Networks," Proceedings of the International Communications Conference, June 1969, p.21.9-21.16. L. Kleinrock, Methods for Computer Network Modela,""Comparison Proceedings of of Solution the Computers and Communications Conference, October 1969. L. Kleinroek, "Analytic and Simulation 1970, p.5
6
Methods 9-579.
in
Computer
Network Design,"
Proceedings SJCC
L. Kleinrock and G. L. Fultz, "Adaptive Routing Techniques for Store-and-Forward Computer Communication Networks," International State of the Art Report No. 6; Computer Networks, Infotech Information Ltd. Maidenhead, Berkshire, Efigland, 1971, p.541-562; also in Proceedings of the International Conference on Communications, Montreal, Quebec, Canada, June 1971, p.39.1-39.8. G. Cole, "Performance Keaourements on the ARPA Computer Network," Proceedings of the Second ACM/IEEE Symposium on Problems in the Optimization of Data Communications Systems, October 1971, p.39-45; also in IEEE Trans. on Communications , Vol COM-21, No 3, June 1972, p630-636. V. G. Cerf and W. E. Naylor, "Storage Considerations in Store-and-Forward Message Switching," Paper presentec at WESCON Conference, September, 1972, 8 p. V. G. Cerf and W. E. Naylor, "Selected ARPA Network Measurement Experiments," Proceedings COKPCON 1972, September 1972. L. Kleinrock, "Computer Networks," in Computer Science. A. F. Cardenas et al. (Eds.), John Wiley and Sons, Inc. New York, 1972, p.241-284. L. Kleinrock, "Performance Models and Measurement of the ARPA Computer Network," Proceedings of the International Symposium on the Design and Application of Interactive Computer Systems. Brunel University, Uxbridge, England, May 1972, 30p. L. Kleinrock, "Survey of Analytical Methods Networks," in Computer Networks, R. Rustin (Ed.), 1972, p.1 8 3-205. in Queueing Prentice-Hall,
111-41
Report No. 4799
Bolt Beranek and Newilnan Inc.
D. Cantor and M. Gerla,
"The Optimal Routing
of
Messages
in
Computer Network Via Mathematical Programming," Proceedings COMPCON 72, September 1972, p.167-170. L. Fratta, M. Gerla, and L. Kleinrock, "The Flow Deviation
Method:
Design,"
An
Approach
Vol.
to Store-and-Forward Communication Network

3, No. 2, 1973. p.97-13
4
Networks,
. in Distributed
D. U. Cantor and M. Gerla,
"Capacity
Allocation
Computer Networks," Proceedings of the Seventh Hawaii International Conference on System Sciences, January 1974, p. 115-117. G. Cole, "Computer Networks Measurements: Techniques and Experiments," PhD Thesis, UCLA-ENG-7165, Computer Science Department. School of Engineering and Applied Science. UCLA, October 1971, 350p. G. L. Fultz, "Adaptive Routing Techniques for Message Switching Computer-Communications Networks," PhD Thesis, UCLA-ENG-7252, Computer Science Department, School of Engineering and Applied Science, UCLA, July 1972, 4 18 p. M. Gerla, "The Design of Store-and-Forward (S/F) Networks for Computer Communications," PhD Thesis, UCLA-ENG-7319, Computer Science Department, School of Engineering and Applied Science, UCLA, January 1973, 30 0 p. Kleinrock, L. Queueing Systems, Interscience, New York, 1975. Volume I: Theory, II: in Wiley Computer Time-Shared
Kleinrock, L. Queueing Systems, Volume Applications, Wiley Interscience, New York, 1976. Kleinrock, L., "Scheduling, Queueing and Delays
Systems and Computer Networks," in Computer-Communication Networks, Abramson, N. and Kuo, F. (eds.), Prentice Hall, Englewood Cliffs, New Jersey, 1973, pp. 95-141. Kamoun, Science F., "Design Considerations for Large Computer
Communication
Networks," 407p.
PhD
Thesis,
UCLA-ENG-7642,
Computer
Department,
School
of Engineering and Applied Science,
UCLA, April 1976,
Ziegler, J. and L. Kleinrock, "Nodal Blocking in Large Networks," ICC Conference Record, Montreal, Canada, June 1971, pp. 39-9 to 39-15.
11-i
Report No.
14799
Bolt Beranek and Newman ILnc.
Kahn and L. Kleinrock, "Computer Communication R. H., Frank, Network Design--Experience with Theory and Practice," AFIPS Conference Proceedings, Vol. 40, SJCC, Atlantic City, New Jersey, May 1972, pp. 255-270. Also in Networks, Vol. 2, No. 2 1972, pp. 135-166. Kleinrock, L., "Analytical Techniques for Computer- Communication Networks," Computers and Communications, Proc. of the joint IBM-University of Newcastle upon Tyne Seminar, University of Newcastle upon Tyne, England, September 1973, pp. 63-90. Kleinrock, L. and W. Naylor, "On Measured Behavior of the ARPA Network," AFIPS Conference Proceedings, Vol. 43, NCC, Chicago, May 1974, pp. 767-780. Kleinrock, L. "Resource Allocation in Computer Systems and Computer Communication Networks," Proc. of the International Federation for Information Processing, Stockholm, Sweden, August 1974, pp. 11-18. Opderbeck, H. and L. Kleinrock, "The Influence of Control Procedures on the Performance of Packet-Switched Networks," National Telecommunications Conference Record, San Diego, California, December 1974, pp. 810-817. Naylor, W. E., "A Loop-Free Adaptive Routing Algorithm for Packet Switched Networks," Proc. of the 4th Data Communications Symposium, Quebec City, Canada, October 1975 pp. 7.9 to 7.14. Kleinrock, L., W. Naylor and H. Opderbeck, "A Study of Line Overhead in the ARPANET," Proc. of the IIASA Conf. on Computer Communication Networks, October 1974, pp. 87-109. Also in "Communications of the ACM, Vol. 19, January 1976, pp. 3-12. Kleinrock, L. and H. Opderbeck, "Throughput in the ARPANET-Protocols and Measurement," 4th Datd Communications Symposium, Quebec City, Canada, October 1975, pp. 6-1 to 6-11. also in IEEE Trans. on Communications, Vol. COM-25, January 1977, pp. 95-104. Kamoun, F. and L. Kleinrock, "Analysis of Shared Storage in a Computer Network Environment," Proc. of the 8th Hawaii International Conf. on System Science. Honolulu, January 1976, pp. 89-92. Kleinrock, June 1976, L. pp. "ARPANET Lessons," 20-1 to 20-6. Proc. of the ICC, Philadelphia,
111-43
Report No.
4799
Kleinrock, L. and F. Kamoun. Packet-Switching Networks," Congress, Sydney, Australia.
"Data Communications Through Large Proc. of International Teletraffic November 1976, pp. 521-1 to 521-10.
W. and L. Kleinrock, "On the Effect of Periodic Routing Naylor, Dallas. Updates in Packet-Switched Networks," Proc. of the NTC, Texas, November 1976, pp. 16.2-1 to 16.2-7. Kleinrock, Computers, 1326-1335. IEEE Trans. L., "On Communications and Networks," 25th Anniversary Issue, Vol. C-25, December 197.6, on pp.
"On The Topological Design of Gerla, M. and L. Kleinrock, IEEE Trans. on Communications, Distributed Computer Networks," Vol. COM-25, January 1977, pp. 48-60. Kamoun, "Hierarchical Routing for Large Kleinrock, L. and F. Computer Performance Evaluation and Optimization." Networks, Networks, Vol. 1, No. 3, January 1977, pp. 155-174. Kleinrock, L., "Performance of Distributed Multi-Access ComputerCommunication Systems," Proc. of IFIP Congress, Toronto, Canada, August 1977, pp. 547-552. "Analysis of Buffer Allocation Kermani, P. and L. Kleinrock, 2, Vol. Schemes in a Multiplexing Node," ICC Conference Record, Chicago, Illinois, June 1977, pp. 30.4-269 to 30.4-275.
111-44
.... ,',,,,""+'",,,,"
II~l '171 iiInowiI
Report No.
4799
1.4.1.7 The
The Network Working Group and Host Involvement initial design of the ARPANET as contained in certain formats for the RFQ
went some way toward specifying communications and for to
inter-IMP
AP-to-host communication. host-to-host communication,
Less explicit this area
attention was given being left To
for host sites to work out among themselves. provide the hosts with a little DARPA assigned impetus to work on the the S. problem Crocker, fall of to S. Elmer Carr, to
host-to-host Shapiro and J. of
problems, SRI.
After an initial the
meeting, summer and
Rulifson met again in
1968
continue discussion of host-to-host protocol issues. thinking was at a very high level, e.g.,
Their early
the feasibility of
creating a portable front-end package which could be written once and moved to all network hosts; a host desiring to send another host would first data to
send a data description to the receiving
host which instructed the front-end package at the receiving host hcw to interpret data coming from the sending host. On
Valentine's Day, and
1969,
the first from the
meeting of host
representatives
representatives
NMC
and NAC, of
along 4ith the IMP an enormous snow
contractor, storm. In
was held at BEN in
the middle
April 1969,
a series of working notes called Request for which could be circulated to let
Comments (RFCs)
was established,
III-45
Report No.
4799
others know what they were doing and to obtain the reactions involvement of other interested parties.
and
They called themselves
the Network Working Group (NWG). The NWG eventually grew quite from almost every host large, with representatives and on
site in the network participating, and commenting
mountains of paper was circulated describing various protocols. There were
also occasional mass meetings. he would go to DARPA
From about the time it until near the time
was decided that he left DARPA.
Stephen Crocker served as grown
chairman of the NWG. too large, but much
By the beginning of 1972 the NWG had of its work was done -over the network.
large numbers of From this point
hosts were communicating onward, meetings
were limited to those of an executive protocol

iet to discuss general protocol issues and
committee which
provide
guidance e.g.,
for
Crocker,
and
to
those
of
various
subcommittees,
protocol. working network.
the group interested in the Remote Job Entry

most participant in the
Even after the big meetings stopped, notes
were circulated to most other participants
Gradually the activities of the NWG began to diminish. of the host site personnel who had originally been active
Many moved
on
0se
to
other
tasks,
and new users joining the network tended to

their
the defined protocols rather than becoming involved in
ri
1 -
111-46
k'
4~
Report No.
4799
Bolt Beranek. and Newman Inc.
specification.
As
Crocker's
time
for
the
NWG
group became Jon Postel
increasingly limited, he appointed Alex McKenzie and to serve jointly in his place.
McKenzie and Postel interpreted primarily,
their task to be one of codification and coordination and after
a fe4 more spurts of activity the protocol definition
process
settled
for
the
most
part
inio
the
status
of
maintenance effort. Further activities of the Network Working Group will be
described in the section below on the development of host-to-host protocol.
III-i7
Report No.
4799
1.4.2
Initial Subnet Design BBN's proposal for the IMP was for the most part compliant
with
the
requirements
of tne RFQ.
In some important respects, requirements or
however,
the BBN IMP design diverged from those the RFQ.
added constraints that were not in The BBN
design took the idea of inserting a communications extreme: between
processor between the host and the network to a logical it specified that the IMP be used only functions, and that there 1,;e maximum logical Thus, separation
for communications
IMP and host. of binary
the design did not provide for IMP repacking on behalf of a host or for doing character Further, IMP and the design precluded all host
messages
conversion for a host. programming of the
any control of the IMP by regular
hosts. The initial subnet design

messages between an IMP and its in the RFP.
also
hosts,
specified
minimal
control
many fewer than envisioned it proved useful to
As the network later developed,
add additional su'ch control messages. The IMP design called for a hardened robust statistics in the face of physical IMP, which would be
and electrical abuse. it was
While
have shown that hardening did help,
eventually
decided not be be worth the added price of the hardware.
111-48
Report No.
4799
The
capability This has
to
loop all interfaces was included in to' be of enormous
the
"design.
importance. A tape,
proved
operational
decision
was
made
to
reload IMPs initially
from paper It was be
and each IMP was provided with a paper tape reader. would sooner and it was or
always intended that this procedure replaced the paper
later
by loading through the network, tape reader at each IMP
was.
The use of a useful
probably
simplification in Program local
the beginning. was also specified to take place from a of simplicity, with tae A the
debugging in the
terminal, that
interests
knowledge
cross-network debugging could be added later. was added even before
cross-network debugging capability first IMP was delivered. A delivery schedule of
one IMP per month in months eight instead of all four at month
through eleven after contract start, nine, was assumed. In keeping w1th the strict IMP was to gather to statistics
independence of host and IMP, routinely and transmit
the them
periodically
specified hosts rather than permitting hosts to capabilities. This proved
control the IMPs' statistics-taking satisfactory.
111-419
Report No.
4799
The
initial
IMP
design
was
responsive to the RFQ in one the first meeting between
particular way which was changed at BBN, host DARPA, per and host representatives. IMP and
The RFQ had called for one although it Almost also asked it
six circuits per IMP, an host option. sites Thus
that more hosts per IMP be became connect clear to a the that many
immediately
had more than one host to the first three, IMP was
single
IMP.
before
delivered,
design was changed to permit two, four,
or four was
hosts on an IMP along with five, a simple change to implement. In the area of
or three lines.
This
the host-to-IMP protocol,
the initial IMP some
design specified this protocol as required. aspects of
Unfortunately,
the host-to-IMP protocol had significant detrimental performance of the other prutocols. the
effect on the design and
Particularly unfortunate have been the acknowledgment system, retransmission system, and the message
identification system
initially suggested by the host-to-IMP protocol. It is crucial for the IMPs to limit the rate of flow of host
is being
traffic into the net to the rate at which that traffic taken first out, in order to prevent subnetwork congestion. which was insufficient, took the
The IMPs' form of i!
attempt,
suggesting
that each message in until an
a conversation should be held by acknowledgment for the
the sending host
end-to-end
111-50
Report No.
4799
previous
message
was
received.
This suggestion was adopted as standard
part of host-to-host protocol upon which all the higher protocols are based. host-to-host ARPANET protocol time As a consequence, connection is using 50
the bandwidth of a single limited; given the waiting for a
severely lines,
response
Kbs
destination-to-source
acknowledgment
between messages typically in contrast to the
limits connection bandwidth to about 10 Kbs,
40 Kbs possible with a constant stream of messages. It was originally thought that the ARPANET would lose a hosts ever bothering resolving various
message so seldom that there was no point in with message retransmission. Unfortunately,
possible lockups has required the subnetwork to discard a message occasionally, and the topology of the network has evolved into the probability
long series of machines and lines that increase of involuntary message loss. However, did
the host-to-host protocol not of provide the for message of
followed the initial retransmission. message loss in which is
thought and Given the
realities
probability
the network and given the host-to-host sensitive to any
protocol, the proved
inordinately
abnormality, has not
host-to-host protocol (and protopols based on it) particularly * * As robust although it of the has been reliable.
part
host-to-IMP the
protocol host-to-IMP
end-to-end protocol
acknowledgment system described Pbove,
111-51
&MW go.
'
i tt tm li I iili ili
Report No.
4799
specified
an
8-bit
message identification number and suggested single

in
that all messages

identification
in a
number;
conversation
fact, messages
carry
with
this
same
different
identification numbers were not guaranteed to be delivered in the order sent. uniquely Eight bits is probably insufficient to identify
(for
the purpose of possibly required retransmissions) a conversation Use
outstanding messages when successive messages in are sent
without waiting for an end-to-end acknowledgment.
of the small 8-bit message identifier was one of the factors that prevented reliable high-bandwidth connections. The IMP/host protocol has been changed longer message necessary order to is cases wait now for the so that it is no
end-to-end acknowledgment; except for priority are
preserved requiring
considerations;
message host;
retransmission and the
unambiguou-ly reported to the
sending
message
identifier has been expanded to a sufficient size.
111-52
Report No.
4799
1.4.3
Subnet Development The first four IMPs were developed and installed on schedule
by it
the end of 1969.
No sooner were these IMPs in
the field than connect hosts .
became clear that some provision was needed to

distant from an IMP (i.e.,
relatively
up to 2000 feet instead of
the expected 50 feet).

interface drivers, was was
Thus in early 1970 a

Augmented simply
"distant"
by
IMP/host
line
developed.
heftier error it
these distant interfaces made clear that on the host/IMP interface. on such
control had been wired
needed
Previously, a local
assumed there would be no errors connection. By mid-year of 1970,
hard
a series of network performance tests flaws which were
were being carried out. quickly corrected, Also by mid-year,
These uncovered some
and some problems which looked more worrisome. a rudimentary version of the network control
center was established at BBN. As the year wore on, network, the IMP sites continued continued 230.4 Kb to to be be added to the NCC
program the first
improved, was
development continued, between two IMPs,
circuit
tested
and
design for a version of the IMP able to begun. The latter was
support direct terminal connection was called the Terminal IMP (TIP).
111-53
Report No.
4799
In 1970 major problems with the IMP flow control and storage allocation even after techniques were demonstrated. these problems were It is interesting that (and they were
demonstrated
serious enough to completely halt network operation under certain circumstances), for many, many the network while continued to give adequate service improvements were designed and
months
implemented. in
The hosts were simply asked to not use the network and the hosts did
the way that caused the subnetwork problems,
as they were asked. About three-quarters T1Ps were delivered, of the way through 1971 the first two time soine
providing ARPANET access for the first on
to users without their own hosts or access to terminals other organization's host. By the beginning of 1972 it 'as
recognized that even the and
distant version of the IMP/host interface was not sufficient, design for a circuits worth a was little IMP/host begun. interface for use over
communications is
The evolution of the IMP/host interface comment. The initial
additional
bit-serial, interface to was
asynchronous,
non-error-cuntrolled the RFQ, in
IMP/host an
essentially specified in network connection for
effort
simplify
the hosts.
This non-standard interface
may have been of some benefit in However. its
simplifying the host connection. it put between
greatest virtue was the separation
111-54
i
'1
Report No.
4799
the
IMP
and
the
host.
The IMP and host did not have to worry and they did not It have also have to worry
about each other's word size, about each other's timing
constraints. would
seems likely that delayed resulted for network in a
having to worry about these issues operation. hodge-podge of distant first However, interface than this
interface each
variations, its
designed
more
operation
predecessors,
and none except the which need not fear it would clearly be
was very elegant.
For any new network,
the now proven packet-switching technology, better e.g., to HDLC, use an industry
standard communications interface,
for every IMP/host connection. half of 1972 the TIP's capability was expanded
In the first
to support TIP-to-TIP magnetic tape transfers. was successfully used between
While this option it was never was
two network sites. the IMP
very elegant. undertaken
Also,
a massive change in
software
to correct the previously discovered flow control and In the second half of the year, was released in many the
storage allocation problems.
new version of increments, was begun.
the
IMP
program
small
and the design of a new,
ten times more powerful IMP
The beginning of 1973 brought the first the network, from California a to Hawaii. of
satellite Also, subnet
link
in
with network reliability
traffic
rapidly
increasing,
number
SIII1-55
Report No. 4799
problems
developed
which
had
to be corrected. for use
By mid-year, in Norway
pair of TIPs had been shipped to Europe. London. first These brought
and
numerous operational problems.
For the PTT, the these
time,
circuits had to be obtained from a foreign relatively slow at 9.6 Kb,
circuits
were
and like Hawaii,
TIPs were on a long spur off the network rather than being doubly connected as IMPs typically are. be delivered, During 1973, nodes continued to switching of
but there began to be a low level of to optimize the use of various TY,' came on and went off the
node locations, and as sites
configurations Certain routing
network.
improvements were also made to correct problems with the algorithm. As 1973 ended the first
very distant hosts were
connected to the network over telephone lines. In 1974 there were major efforts to make operationally usable. the network more
Subnetwork reliability was improved as was reliability. and Methods for providing TIP pa:t~tioning Methods were of logical to
TIP-to-host communication access control and
accounting
subnetworks of hosts were developed.
developed
selectively reload sections of IMP memory. In 1975 network development slowed up and the network took operational appearance. Major network
on more and more of an developments in modification of
1975 included delivery of the first the IMP
Pluribus IMP,
and TIP software to support more than
111-56
Report No.
4799
sixty-three IMPs in the network and attachment of the Satellite IMPs to the network.
first
two
By the end of 1975 the network
was under DCA management. Looking back, I appears the subnet development between 1969 and 1975
relatively smooth,
although there were many times during
that period when those intimately involved felt they were

to solve one crisis or another. and
trying
The network grew slowly enough, was flexible and which most
and the basic technology
implementation
robust
enough,
that
many problems,
both major and minor,
naturally cropped up with this new development were for the
part corrected before they obstructed the work of too mauy users. The fact that the network was also part of an experiment no doubt also made users more tolerant.
III-57
tita tttll'i~ll
NNWllII11
Report No.
4799
1.4.4
Host Protocol Development Specifications, generally called the IMP-to-host protocol, message transfer between a
exist for the physical and logical host and its to IMP. specify
This protocol is the methods of
not sufficient by itself, communication between the
however, processes
running in
two possibly dissimilar hosts.
Rather,
processes must have some agreement as to the method of initiating communication, forth. the interpretation of it pair a the transmitted data, and so
Altnough
would be possible for such agreements to be of hosts (or processes) interested in
reached by each communication, to minimize
more general arrangement is amount of implementation Accordingly, Working exchange Group of
desirable in necessary
order for
network-wide
communication.
the host organizations or NWG, introduced
formed a group (the Network above) to facilitate an
ideas
and to formulate
additional specifications
for host-to-host communications. of
The NWG adopted a "layered" approach to the specification communicartions protocols, use the services of wherein the higher layers lower l3yers; the of
protocol and in the
advantages
disadvantages of the layered approach are discussed elsewhere thiz report. As shown in Figure 3, the lowest layer is the of
IMP-to-host protocol. layer in the
The next layer specifies
(called methods
host-to-host establishing
figure)
111-58
Report No.
4799
iA
ad hoe
S~Host/Host
FTP
Host/IMP
Figure 3 --
Layered Relationship of the ARPANET Protocols
communications paths between hosts, managing buffer space at each end of a communications path, Protocol or ICP etc. Next, the Initial Connection
specifies a standard way for a remote user (or preparatory
process) to attract the attention of a network host, to using that host: The
ICP provides the analog of the user In
pressing the attention button at a local terminal on a host. the next layer is the Telecommunications Network
or TELNET
protocol, hosts.
which was designed to support terminal
access to remote
TELNET is
a specification for a network standard terminal
and the protocol for communicating between this standard terminal and a host. The next logical protocol layer consists of function two of which, File Transfer Protocol (FTP)
oriented protocols,
111-59
Report No. 4799
and
Remote
Job
Entry
protocol (RJE),
are shown in it is
the figure. possible to
Finally,
at any point in
the layering process,
superimpose ad hoc protocols. In events in the following subsections we discuss in some detail the
the evolution of the host-to-host and TELNET protocols, the evolution of a number of other protocols in
and the events in
somewhat less detail.
111-60
Um .... ..... . *''cl,',l i-,' ...... "l .' m' t. ._._.o_ta _, --. .. .
Report No.
4J
4799
1.4.4.1
Host-to-Host Protocol early 1969. By
The Network Working Group was established in December 1969 an initial
host-to-host protocol had been specified and
which supported communication between a terminal on one host a process on another the initial host. At a meeting in
Salt Lake City in was described because the mail
December 1969, to initial
protocol specification
Lawrence Roberts of DARPA who was unhappy with it plan would not support transmission of
electronic
over the network. back and get it By the
He instructed the Network Working Group to "go
right." spring of 1970 several successive versions of a and a relatively formal the
host-to-host protocol had been developed,
meeting of the NWG was held at UCLA before mid-year at which latest version of the protocol was described.
Reactions to the
described protocol were very negative. a series of meetings held at UCLA and from these two institutions tried
In June of 1970 there was Harvard finally should at to be which people
settle upon a implemented.
host-to-host protocol and specify how it
In August of 1970 some of the more general (and some thought more exotic) aspects of the host-to-host protocol being considered
were ordered dropped from the protocol by Barry Wessler of DARPA, thus administratively clearing away some of had prevented agreement. Tha those issues which
NWG discussion continued at the
111-61
Report No.
4799
1970 Spring Joint Computer Conference;
in
particular,
there
was
discussion between Crocker and Roberts regarding the formality to be sought for the protocol, and DARPA approvals required, Joint and so
forth.
Another NWG meeting was held at the Fall November 1970 in Houston, Texas. 1971
Computer
Conference in
At a NWG meeting held in of Illinois, a subcommittee to
mid-February was what
at the University to were look at the
appointed changes
host-to-host desirable or
protocol
see This
immediately
necessary.
subcommittee went directly from where it met for two days, Los
Illinois to Cambridge,
Massachusetts,
wrote an interim report, Angeles. It appears
and then reconvened a month later in that with
the efforts of this committee committee")
(known as the "host-to-host protocol glitch cleaning the design of the ARPANET host-to-host
protocol was finally
coming close to being settled. At about this same time DARPA was beginning to pressure not only exert great
to get the host-to-host protocol settled but At a NWG meeting at the in a May 1971,
also to get it
implemented by the hosts.
Spring Joint Computer Conference in Alex McKenzie took on the
Atlantic City of writing
task
definitive invent new
specification of the host-to-host protocol -protocol,
not to
but to write down what had been decided.
111-62
il
"Report No. 4799
In M.I.T.,
October
1971
the
final a
big
NWG
meeting was held at workshop at which In
and was preceded by
programmers'
differences in January' 1972
implementations were clarified and eliminated. a McKenzie ARPANET document
describing the protocol was protocol has remained
published and the
host-to-host
essentially unchanged since.
II1-63
~ t. ,
Report No.
4799
1.4.4.2
The Evolution of TELNET became clear that
Early in the development of the ARPANET it
a major function of the network would be to provide remote use of interactive systems. his local host) To allow a user at a terminal (connected to a remote host, as
to control and use a process in
if
he were a local user of that remote host,

The problems to be overcome
a special mechanism
are legion: for
was required. example,
the typical host expects its attached to the
interactive terminals to be ports of its hardware
physically
individual
terminal scanner rather than logically attached via a multiplexed connection to the network; a given host expects to communicate
only
with
terminals
with
certain
characteristics
(e.g.,
half-duplex, 134.5 baud) different
line-at-a-time,
physical echo,
EBCDIC character set, completely full-duplex, 300
while a remote user's terminal might have characteristics no character echo, (e.g.,
character-at-a-time, baud).
ASCII character set,
The TELNET protocol was an Pttempt to provide the special
mechanism necessary to permit such communication. As early as 1969 a few hosts had been programmed on an Ad In 1971
hoc basis to permit terminal access from another host.
an NWG subcommittee was formed to consider the general problem of supporting interactive use of arbitrary hosts by users in at the
arbitrary remote terminals.
There was great controversy
111-64
Report No. 4799
committee
discussions,
focusing on four issues: echoing, enough
character set, By
connection establishment, late 1972 there was
and interrupt capability. consensus the so that
widespread had
implementation of an early version of been accomplished. Despite protocol, declare widespread
TELNET
protocol
implementation
of
the
early
TELNET to
its heavy and effective use it complete, discussion of
and numerous it continued.
attempts
There were
several problems with the early version: 1. Despite the attempt to permit a minimal
well suited to
implementation
there if
the constraints of small hosts, implementation. not be desired provided use. For for in
was no well-defined minimal some TELNET feature it was
Even a case
given some
implementation,
had to
other implementation commanded its 2. The control structure was
inadequate.
example,
unless made, it
some
exceedingly constraining assumptions were two ends

each
was possible for the

to loop,
of
other
TELNET
to take
connection
commanding
opposite actions. 3. The asymmetry of TELNET connections precluded

from initiating certain functions, such
one
end
as echoing
111-65
S"
"
""
"
nl n w i ~lW I Hi{iW mln i ilill~lrl,
Report No.
4799
Bolt Beranek and Newman inc.
behavior.
This seriously constrained the use of TELNET processes it it would was
protocol for character communication between not serving terminals, a role for which which
otherwise have been well suited and for already protocol. 4. frequently used
in the absence of any better
The issue of interfacing character-at-a-time line-at-a-time hosts was poorly handled.
hosts
to
By
early 1973 it
had become apparent that minor adjustments problems and
to the early TELNET protocol would not solve these that some fundamental changes were needed. guide
A new subcommittee them, developed when added
met and, with the previous experience to several fundamental principles.
These new principles,
to the earlier principles of the Network Virtual Terminal and the remote interrupt (synch) mechanism, of the resulted in a revised TELNET earlier problems that had
protocol which solved most
precluded universal acceptakice of the protocol. There was such enthusiasm for the new version was that a laid
schedule for "rapid" (within the year) out. However, the implementation of
implementation
the new TELNET protocol have
proceeded more slowly than expected. implementations been widely available. several reasons
Only in the past year In retrospect,
there were 1) at the
for the delay in the implementation:
111-66
. .. *z ,r'.,,- .t
" "-iillb 'ti i
i -i iii = -
-- -:
. . . . . .
. .
. (.. . _.. _. .!..
_ . . . _. . _ .
_ .._.. . . . .
Report No.
4799
time
the
r-vised
protocol
implementation
was
scheduled,
implementation of the initial version had been completed and host

system managers 2) had not budgeted resources for a second in
implementation;
about this time DARPA's research interest
the
network
was declining and the network was entering a period 3) despite initial belief that a clean
of status quo operation; method protocol of
phasing over from the initial protocol to the revised existed, most none was found by most implementors and
consequently
chose to provide a complete implementation of in parallel for with the initial
the revised protocol to operate protocol; host, and 4)
implementation
the most prevalent user TIP's
the TIP, proved to be very difficult (because of the memory) and time-consuming,
limited
thus implicitly relieving revised protocol.
pressure on the server hosts to implement the The new TELNET protocol has been the
accepted standard for
several years,
and it
is widely implemented and used.
III-67
Report No.
4799
1.4.4.3
The Evolution of the Other Host Protocols host protocols the evolution of
There are several other
which should be briefly mentioned. The File Transfer Protocol started out as two protocols, a
Data
Transfer
Protocol
the Data
and
File
Transfer
Protocol.
To
over-simplify,
Transfer
Protocol
was to specify the Transfer Eventually, Protocol the File and a
format of data being transferred and the File was to specify how it was transferred.
Transfer Protocol alone was defined with a control portion. After the final push
data to
portion
specify the FTP, a
relatively little little effort bit to
additional work was done,
consisting only of
clean up fundamental aspects of the protocol, work reconciling the "reply codes" that
and a good
of
different hosts used to indicate FTP-related events. Before a Remote Job Entry protocol could be defined by the UCLA's IBM 360/91 host, a batch oriented host,
NWG as a whole,
needed some RJE-like protocol with which to serve a few users who wanted host. early Thus, access to the computing power of that particular a protocol called the Remote The NWG
led by the UCLA group,
Job Service or RJS protocol was defined and implemented. eventually got
around to working on the problem of a Remote Job undertook a relatively massive effort to
Entry protocol and define such a
protocol.
However,
by the time the RJE protocol
1-68
Report No.
4799
definition was finished, implemented to
half a doz i or
so
hosts
had
already
interim RJS protocol. the network
Since these included most in supporting remote
of the hosts on batch, RJE there
interested
was little Thus,
incentive for them to implement the new today the RJE protocol is carefully and
protocol. but
specified
to our knowledge is
not implemented anywhere,
the RJS protocol prevails. Moving upward in the subject of sophistication, another protocol that was
early discussion was one for graphics.
Several
versions of a graphics protocol were specified but until recently there was never as part widespread of the implementation ACCAT of any an of them.
Recently,
experiment,
operational
graphics protocol has been developed. In addition to the host-to-host protocol which specified after much iteration, were suggested by various was finally
a number of alternative protocols of the NWG. Before the David
members
host-to-host protocol was settled upon, Walden each suggested
Richard Kaline and
an alternative protocol.
Even after the discussion the Walden
adoption of the host-to-host protocol, of experiments More with a protocol as part
there was some derived of the from
suggestion.
recently,
DARPA-sponsored Stuart Schaffner,
National Software works project,
Robert Thomas,
and their colleagues have designed and implemented a host-to-host
111-69
Report No.
4799
protocol
known 3s MSG.
Another protocol,
known as TCP,
deserves
special mention.
Near the time of the formation of the International Working interest, Group, as network interconnection Network
began to be of great
discussions began on 3 -t;idard inter-network protocol, ;ore of the shortcomings zrret A-,. the AFIPS 1973 NCC in ideas for a of New new
particularly one which ootld the ARPANET host-to-host protocol,
York City a meeting was held at which certain host-to-host correspondence, Stanford, got protocol were discussed.
After Vinton
some additional Cerf, then of
Robert Kahn of DARPA and together and designed
a protocol known as TCP.
Other members of INWG,
perhaps not satisfied that TCP represented continued also developing participated the still in another this later host-to-host
an international standard, host-to-host effort). protocol protocol
(Cerf
TCP quickly became DARPA's choice of to be used in
situations where the ARPANET host-to-host
protocol was insufficient or where inter-networking was required. With DARPA support, protocol has come ARPANET. and its several TCP implementations were done and the into use relatively is still widespread use within the
spreading.
TCP is
scheduled to
replace the ARPANET host-to-host protocol throughout the net by I January 1983. of Meanwhile the host-to-host protocol that the and documented, submitted rest
INWG was working on was finished, North American common
just as the the X.25
PTTs and
carriers
111-70
iA
Report No.
4799
standard
to
CCITT;
so
the
INWG
consensus protocol will most

elsewhere.
likely play little
operational role in the ARPANET or
I1
III-71
Report No. 4799
1.4.5
Network Growth
--
A Summary
In the following three subsections we consider tnree aspects of the growth of the network: the traffic growth, the growth of of
the network topology, hosts on the network. 1.4.5.1
and the increase in
the number and type
Traffic Growth
In internode
early
1973,
Roberts
presented a curve of average host
traffic growth for the network* which showed the level at a rate of a
of internode network traffic to be increasing factor of ten every ten months.
Internode traffic means traffic
sent from a host on one node to a host on a different node; i.e., it does not include traffic sent between hosts on the same node.
Based on this rapid rate of growth, would run out of capacity in
Roberts predicted the network nine months. As shown in rate the of
following figure,
shortly after Roberts'
prediction the
internode traffic growth decreased sharply to roughly a factor of two every twenty months. It is interesting to speculate on the
reason for this sharp decrease.
L.G. Roberts, *Network Rationale: A 5-Year Proceedings COHPCON 1973, February 1973, pp. 3-6.
Reevaluation,"
111-72
Report No. 4799
ARPANET HOST INTERNODE TRAFFIC
I 106
JAN
72
JAN 73
JAN 74
JAN 75
JAN,
76
JAN 7Y
Figure 4I- Growth in Average Host Internode Traffic
111-73
Report No.
4799
It new
can be hypothesized that the existing hosts (and the that were added)
few
hosts
were used remotely more and more and more, hosts) until began the to hosts run (at
network traffic increased more and least the popular time-sharing
out of attempt
capacity; this made it to get service, traffic out of out and
pointless for new remote users to resulted, in turn,
in a leveling off of of the it network
network running
growth.
Therefore,
instead
capacity as predicted by Roberts, of capacity while the
seems that still has
the hosts ran capacity left. As in two
network
already
stated,
the traffic shown in
Roberts'
curve and There are
the figure above includes only internode traffic. reasons for excluding intranode traffic. First.
intranode
traffic puts a burden on only one node rather than on the network as a whole. calculate Thus when Roberts, the effects of for instance, was attempting to he
host traffic on network capacity, traffic. Second, the
naturally excluded intranode
intranode
available
traffic statistics
include some amount of test traffic to the same
being looped from a host through its node and back host, and there is from It is
no convenient way to separate this looped test data traffic between two hosts on the same however, real that there is actually a
traffic node.
actual
believed, of
significant
amount
traffic
between hosts on the same
III-74
NE
Report No.
4799
node.
For instance, the
Kleinrock reports* that during
week-long
measurement,
level of intranode tr-ffic
amounted to a daily and
average of twenty percent of the level of internode traffic, in some one-hour intervals
the intranode traffic level was as A scan of traffic
much as eighty percent of the internode traffic level. available long term statistics on intershows and intranode
that intranode traffic levels have averaged between twenty Thus the traffic
and forty percent of internode traffic levels. curve given in the figure above
should be scaled up by this
factor if
all traffic is
to be included. is a significant portion of all
That intranode traffic network traffic First, is is
interesting and probably indicative of four a handy interhost interface, and
phenomena. once one
the IMP is
installed in there is
a computer center to connect some host very soon pressure center to to connect other
onto the network, computers in the
computer
the IMP so that desired possible. Second, when
communication between the computers is two computers are connected to
the same IMP so they may both the network, communication
communicate with other computers in between the two it computers was not
themselves comes free and begins to initially thought to be desired.
happen even if
* L. Kleinrock and W. Naylor, "On Measured Behavior of the ARPA AFIPS Conference Proceedings, Volume 43, May 1974, pp. Network,"
767-780.
111-75
Report No.
4799
Third,
the
TIP (a host) has been chosen by several sites as the available terminal multiplexor and TIP-to-host Fourth, there to be
most flexible traffic
at these sites is likely to be intranode. weak, a
is a (as yet still concentrated IMP. would at
but definite) tendency for hosts
certain site and therefore often on the same that, while some cynics
The reason for this tendency is have
guessed that every computer center manager is trying in fact the world of
to build his empire as large as possible, computer center managers appears
to include not only managers also many who
whose inclinations are as the cynics guessed but dislike
running computer centers but do so because they need the Once the network became other sites that
service supplied by the computer center. available, one site's
some sites have arranged with some computer
was moved to a second site, and the second computer over
site managed it
for the first site which used the
the network via a simple terminal concentrator. for this
A further reason
tendency (for hosts to be clustered) is the economy of required for
scale possible when only one facility and staff is the operation of several computers. 1.4.5.2 The Topology first ARPANET
node was installed at the University of three nodes
California at Los Angeles in late 1969 and the next were installed in California and Utah.
111-76
Report No.
4799
i
1
UA?
Figure 5:
The ARPANET in
December 1969
S"111-77
Il
Report No. 4799 Bolt Beranek and Newman Inc.
By
June 1970 three East Coast and two more West Coast nodes
were added,
as well as two cross-country lines.
SR
HARVA
Figure 6:
June 1970
111-78
Report No.
4799
IMPs continued to be delivered to the field rate of approximately one per month,
at
an
average
so that by late 1970 there The IMPs the were all 516
were thirteen IMPs installed in entirely computer. compatible, all
the network. based on
being
Honeywell
MIT~
Figure 7:
December 1970
III-79
Report No. 4799
By two-thirds of the way through 1971, IMPs had been
two
additional
516
installed, the prototype TIP was rinning at BBN,

at MITRE and
and two TIPs were operational within the network, AMES.
I
WCOLN
S41
ANDILLINOIS
CREI
iuN
Figure 8:
September 1971
111-80
Report No.
4799
The
TIPs
were
based a
on
Honeywell a
316
instead IMP
of
516 was By
computers and had as
component
316-based
which
completely compatible with the 516 IMP but half as expensive. early 1972 several
additional IMPs and TIPs had been installed the East and West
and the central part of the network between
Coast clusters was beginning to fill
out.
JTAN
AFG K
......
AESILNOSEI UC8
S~Figure
9: March 1972
111-.81
Report No.
4799
By August 1972 a third cross-country line had been added and it was clear that in addition to the IMPs scattered throughout there were actually clusters Boston, Washington. of D.C., IMPs San
the center of the country, in four geographic
areas,
Francisco,
and Los Angeles.
S
McCLELLAN UTNCASE
UTAI
,MIT
)89N AFGWCso
AMES
NOA
ILLINOIS
U
UNL
TIKE
IT:R.
A RPAT
Figure 10:
August 1972
111-82
Report No.
4799
'
v
There follow once-yearly maps for the with which the reader can
years
1973
to
1977
follow the continued growth of the
ARPANET topology.
SIMT
IE ,. ,I''
I
l Figure 11 : September 1973
III-83
Report No. 41799
Bolt Beranek arid Newman Inc.
F~gue Jun 12197 111.811C
Report No. 4799
Mo AM AMES STAN EX HAWAN UCSD RAN10 US0.1 Usc-ISI SRI UYAN GWC ARGONNE PURR !UR WPAFB SELVOIR SDAC SOAC MITRE APA GUNTER EGLIN RML 0 IMP s TIP SATELLITE CIRCUIT
LINCOLN MIT-0q MIT-MAC CCA lox
TYMSHARE FNWC OCLA AFWL us ILLIWIS
NYU ASEROM IWRSAR N ETA LONDON
Figure 13:
July 19T5
111-85
Report No. J4799
TAWM PU*SuS
* fWMEXTIIMaOESmT@wMFgVFIha
OTPO
vSCC)
ReportBolt
Beranek and Newman
lnc.
fPS x~~~(?4 (b~~~~~~~qrt~~WC~
flifuAkk'$
01FiSO Ors#t
SATCLT(
C,,F4CIOIV UAiCS NUE UECSSM~flNOB SOWW1*1IM #4? NAMS
"Fi4r 15:
V111-8?e silts
Jul
1977
Report No.
4799
Bolt Beranek and Newman Inc,
Having shown the growth of the ARPANET series of geographic maps, it is
topology
through
interesting to consider the We use
evolution of the topology on a more quantitative basis. the topologies given in
the eleven maps shown above as the basis the Figure 16 chart. six entries exist at Columns
for the quantitative data shown in 6 and 7 are missing the first
because the HAWAII, the times the six
NORSAR, earlier
and LONDON nodes did not maps were made.
The first
three entries in
columns 8 kept in
through 11 are missing because that information was not the early days of the network.
There are several interesting First, the number of
facts that should be noted from the chart. network this, nodes has stayed about
the same since 1975. to increase.
Despite Next,
the network throughput has continued
note that intranode throughput actually is of total network throughput. length reached in path 1974-75, Also,
a significant fraction
note the peak in average path
and the subsequent decrease in average 1975-76 in
length; selected lines were added to the network in
as a direct response to network delay problems which occurred 1974-75. from Finally, note that in July 1975 and July 1977,
the path
HLWAII
to LONDON is
equaled by other paths in the network; was 15 hops from both UCSB in (Santa and
the NCC (in Barbara, in
the Boston area)
California)
and FNWC (Monterey,
California) is
1975,
1977 SRI2 (near San Francisco, D.C.).
California)
eleven hops from
NRL (near Washington,
111-88
Report No.
4799
1 DEC69 JUN70
DEC70
9 10 11 21 3 I 4 1 51 6 1 71 8 1 ----------------------------------------- ---------- -------41 2.001 1.331 21

I I I
---
, .....
III
1 91 2.221 2.311 41
.-.--.--!--I --
1131 I I 2.461I 2.761I 61II --!,
II
SEP71 1181 2.441 3.321 71 ..

I I
1-13.27% --14.00%1
2,8921 11,6331 682,5021
3,1211 21,0731 287,9531
6,013 32,706 970,455
MAR72 1231 2.351 5.041111 .

I III III
AUG72 1291 2.211 4.68; 91 --- 1-11.79%1

I II
SEP73 1401 2.201 5.611131 5.4011113.53%1 2,893,1301 I I
742,7461 3,635,876
JUN74 1461 2.171 6.141131 5.9811211.19%1 3,125,9551 1,513,7771 4,639,732 I III III I JUL75 1571 2.281 6.791151 6.681151 .67%1 5,179,3611 1,018,5381 7,097,899 JUL76 1581 2.451 5.261111 5.131101 .5851 111 2.41111 'It 1 5.271111 1 1 .9451 JUL77 158, 5.371111 6,627,9681 1,961,7261 8,589,694 7,051,9221112,706,054; 9,757,976
where the columns contain the following information: Column Column Column Column Column Column Column Column Column Column Column 1: Date of Map 2: Number of Nodes 3: Average Connectivity 4: Average Path Length ;: Maximum Path Length 6: Average Path Length, Minus 3AWAII, NORSAR, 7: Maximum Path Length, Minus HAWAII, NORSAR, 8: Percentage of Node Unavailability 9: Internode Throughput 10: Intranode Throughput 11: Sum of Internode and Intranode Throughput
LONDON LONDON
Figure 16:
Some Quantitative Data
111-89
Report No.
4799
There
has
been
good
deal of actual measurement of the
behavior of the ARPANET,
and the most detailed discussion of this of the 1975
is presented in the paper entitled "On Measured Behavior ARPA Network" (L. Kleinrock Vol. and W.E. 767-780). Naylor,
AFIPS
Conference Proceedings,
43, pp. 9
Report No.
4799
1.4.5.3
Hosts
four hosts connected to the ARPANET were an SDS
The first
SIGMA-7
at UCLA,
an SDS-940 at SRI,
an IBM 360/75 at UCSB,
and a
DEC PDP-1O at the University of Utah.

indication of the diversity of host
This beginning gave a go.d

manufacturer types and
operating
recent*
systems
schematic
which would use the ARPANET.

map of the
There follows a
showing the
ARPANET (Figure 17)
various hosts.
Notice that the hosts range from small PDP-lls to hosts systems to such from very
large IBM systems, with a scattering of very special as ILLIAC-IV, running a variety provided of by operating
relatively
standard
ones
manufacturers
special ones constructed by university researchers. Figure 18 provides a breakdown of the numbers and kinds of It is based on information compiled by the Some of these Also, each of hosts the
hosts on the network. NIC for inclusion in share a single
the ARPANET directory. port on an IMP.
host
twenty-three TIPs
in
the
ARPANET
logically
provides
host
function although no physical host separate from the network node

is required.
* A sampling of such schematic maps covering the of the ARPANET is provided in Appendix B.
entire
history
111-91
-Report
No. 4799
MOFFET
*FW
EA
CUTAH
ILINOS
WTREas
O-
T IMP
.1
P LL POORAT1O
FOPL-11~
CAM-1 ca -aa A LE OP-11 PO -1 NOSYCCOUPSITER COIPIGIRAIO CENTER1
A MCAC
UR C ET
M 10
SPOPUE BY HE
HFigure
ARPCE S17 DE-100
Logical Nap--
une197
111-92PP-1
Report No. 4799
Mr
V r40-
4 C 0 f-in 04040-1a
r4A
IV
q 4
- Cqr4 04 #4 rq0 0 10
0O in'
iO in
N. N.1-1
00.000;D
r-4 004000 0000 0 u Q
I Cn MCa424
14
4. 0 il -4 1 0
-40 0 %
0
S
C
1
ooT no
tnoo00MC
A0 : r.4r~ 904 ti m4
r4Mr44
%%NIII 1%. * NI rqviAr 4 - HC'4 4A r4 in r4 r4 f
40r 4i C, . to%00 4
qMr 44 41 s:0: 03
40 14 0~~~~e o -444U) 0 000 tin.000'%'
(D 0 a 0 M I VA-N%" 40 9.4 U0.4r0~
CO (
~'7
44
0.t0
00
aO0
>
0 62 a 000 $4 02 W
00 M 0 4r 00000@ 44 A4 P40
0 E4 40
0
V0
000 0
0 A P
W '4 Dt 01 230 304 d 1VV 40 n 04 ,4 J0
r4e
.E14Ca0~~H
0.i.
00
111-93
Report No.
4799
i11-9
11_!91
Report No.
4799
Bolt. Beranek ana Newman Inc.
1.5
The Impact of the ARPANET The ARPANET a new has served well its original function as a technology. More
testbed for
computer
communications
recently the ARPAKET has also given good operational service to a number of users who have come to depend on it However, for their computer program it
communications service. plan for
a part of the original
the ARPANET was technology transfer. of three interactive forms:
For instance, computer
was thought that the transfer technology would occur in
network
(1) Dissemination cf open scientific
techniques and experimental results through the and technical literature. (2) Through
the common carriers or transfer and
other commercial organizations concerned with data dissemination, and (3)
Through the military command and control Command System Support
centers for which the national Military Center
in the Pentagon serves as the focal point. in this area
The ARPANET's of technology
greatest siccess has perhaps been transfer. Being
an unclassified effort, implemented for the most part there have
by individuals with an academic or research leaning, naturally sets of been papers were
numerous papers written on the ARPANET. written a set relatively of early in the
Two key XRPANET
development
five presented in a session at the another set of
AFIPS 1970 Spring Joint Computer Conference and
111-95
Report No.
4799
five
presented
in
session
at
the
AFIPS 1972 Spring Joint IPTO
Computer Conference. and the two sets
Both these sessions were organized by
of five papers were specially bound together and a distributed number of widely. papers In 1975 We in have the IPTO
under DARPA-provided covers
"already listed
these
and
other
bibliographies provided elsewheie in commissioned Becker and Hayes,
this history.
Inc , of Los Angeles,
California, ARPANET
to prepare a bibliography of publications related to the (Selected Bibliography Inc.,
and Index to P'ublications about ARPANET, February 1976,

1 8 5p.).
Becker and Hayes, lists
This bibliography index. The number
561 relevant documents and includes a stlbject is available from NTIS under
document AD-A026900.
accession
A complete set of the papers in
the bibliography was number of
also collected on microfiche. informal
There was also a large
working papers distributed among the various groups and Many of these The
individuals working on the ARPANET development. are also covered in the Becker
and Hayes bibliography.
National Bureau of Standards has also constructed a on computer communications which includes
bibliography hundreds of
PRPANET-related publications. In mid possibility Spring Joint instead 1971, Robert Kahn, then at BBN, suggested the
of h public demonstration of the ARPANET at the 1972 Computer Conference. Lawrence Roberts arranged
for this demonstration to be held in
October 1972 at the
111-96
"Report No.
4799
first This
Internaticnal demonstration It debug It
Conference on Computer Communication marked all a key turning in point the in
(ICCC). ARPANET to
development. thoroughly protocols.
forced
participants
project
and test their network support and application gave international visibility to the packet
switching concept which, scepticism by the
until then, had been viewed largely with communications community. and Robert personnel Kahn and
undertook the task of marshalling with several key members
resources
of the ARPANET community planned and culminated lines in were the a successful leased from
managed the full year effort which demonstration. Fifty kilobit
phone
existing network sites to the conference site at Hilton room in Hotel, and an ARPANET TIP was set up in
Washington
a demonstration Dozens of
the hotel for the duration of the conference.
members of the ARPANET community were involved. all manner of
Manufacturers of
computer terminals were invited to connect their Throughout the conference
terminals to the demonstration TIP.
hours, each day of the conference, there were individuals available to demonstrate the use of programs on ARPANET hosts from the manufacturer-provided and many terminals. copies made A relatively thick available at the
booklet was written, confaeence,
by means of which visitors to the demonstration area yourself" directions to use programs on many
could follow "do it network hosts. A
twenty or thirty minute motion picture about
III-97
Report No.
4799
the ARPANET produced
and
the
promise
of
computer
communications
was
and shown at the conference.
Coming at a time when the long time, when only a and the
TIP had not been available for a very limited
number of terminals had been tried with the ARPANET, of
when many hosts had completed the fnitial implementation necessary host software but few had had it the ICCC demonstration provided
running for very long,
an important stimulus for the network in true
ARPANET community to pull together and get the operational shape. The demonstration itself
was a spectacular many visitors
success; with everything working amazingly
well,
remarked that the ARPANET technology "really is this impression back home with them.
real" and carried
The assurance with which in which
Roberts promised the demonstration and the routine way he spoke of it while it the of
was happening no doubt enhanced the visitors, of and belied the crash
impression taken home by efforts and feelings
panic
the members of the ARPANET
community who were called upon to execute the demonstration. There technology. have Of been numerous many other of demonstrations of the
course,
these
have been informal or several instances Once for ARPANET
relatively low key or relatively short, the demonstrations IPTO,
but in
have been truly major productions. several members of the
example,
with help from
community,
took a demonstration team to Europe where a series of
demonstrations was given for members of the NATO community over a two-week period.
111-98
Report No.
4799
There has been good technology Defense to other
success of
in
transferring
the
ARPANET The
parts
the Department of Defense. procured two small
Communications
Agency
networks,
essentially identical to the ARPANET in of gaining experience
function,
for the purpose Called the the WWMCCS successor
with the ARPANET technology. the first of these was used in connection with the
PWIN and EDCN networks,
effort and the second was used in to AUTODIN I.
Two other networks essentiaily identical to the by other parts of
ARPANET but smaller have also been procured DoD.
Where direct copies of the ARPANET were not appropriate, ARPANET technology
the
has nonetheless affected the characteristics built. II, For instance, the new DoD is
of new DoD networks being common user network,
AUTODIN
being constructed by DCA,
explicitly a second generation ARPANET. Outside the U.S. use the ARPANET military, the commercial world has begun to or variations on it. Several
technology
companies
have filed with the F.C.C.
or already been licensed to the
offer communications services based more or less directly on packet-switching technology developed in ARPANET. which
Among these BBN arranged Tymnet,
are Telenet Communications Corporation (for the financing and Lawrence Roberts was
President,.
* Now with GTE Subscriber Network Products.
111-99
Report No.
4799
Graphnet,
IT&T,
and AT&T.
Because of its access to substantial common carriers Telenet has
ARPANET expertise, used about the ARPANET
of the several
technology most directly. in the to continental
Telenet now serves U.S. and has made
eighty
cities to
arrangements
connect
several foreign networks and serve in parallel
several foreign cities. to ARPANET as a means to
Tymnet initially developed
of making the time-sharing services of a wide geographic area, and used a
Tymshare
available
substantially
different
although
related Tymnet
communications built uses
technology; however,
techniques IT&T, closer
a new version of
to those
being
developed their
for ARPANET. intention to
Graphnet, provide
and AT&T all
have
announced
public packet-switching services. A number of U.S. companies have also procured many it or are of the
procuring techniques
private
corporate
networks
utilizing
developed for ARPANET. York
For instance, City has
was recently (by
announced that Citibank of New contract to BBN)
constructed
a private network very similar to the ARPANET.
An increasing number of commercial RFPs call for packet switching or for functions A which of can only be provided using packet
switching.
number
companies have taken advantage of the is in the public domain to
fact that the ARPANET technology btain
the listings of the ARPANET software.
1II-100
Report No.
4799
Several
PTTs
(the
foreign national Postal,
Telephone,
and
Telegraph authorities) have made a commitment to the of packet-switching networks, there
development
have been several foreign are being of
research networks, developed or are
and several international networks under consideration.
There follows a list
some of these networks:* CIGALE -an operational network developed by a French
government research agency. RCP -built by the French PTT and operational as a teatbed. -under construction by the French PTT 1978. and
TRANSPAC
scheduled to become operational for public use in EPSS -an
experimental packet-switching service built by 1976. the Spanish
the UK PTT which became operational in CTNE -PTT. Datapac -a packet-switching
a packet-switching service operated by
network in the
built early
by
the
Trans-Canada Telephone System which is of operation.
phases
-------------------
* More detail on this list
may be found in "Planned New Public Data Networks", P.T. Kirstein, Computer Networks, Volume 1, Number 2, September 1976, pp. 79-94; Kirstein is himself a member of the ARPANET community and was instrumental in arranging the installation of the London node of the ARPANET.
III-101
S.
Report No.
4799
JIPNET EIN -the
--
practically a copy of the'ARPANET built in built Italy
Japan. by
the European Information Network, Switzerland, France. and
jointly and
U.K.,
strongly
influenced by CIGALE. EURONET a network under discussion by the European
Eco'romic Cmmuri!,, No doubt therf'
initially to use the EIN technology. are other networks besides those mentioned With so many
above in the planning phase or under construction. networks coming into being, From
technology exchange and standards the time of the 19,72 ICCC,
become important
representatives in and
issues.
cf various countries and institutions ipterested their eiperience
computer networks met informally to discuss to consider possible standards. was formed.
In 1972 the International Modeled on the ARPANET
Network Working Group (INWG) Network Working Group, INWG's
Vinton Cerf of the ARPANET community was first chairman and DARPA offered the
selected to be
services of the the ARPANET NIC to coordinate and distribute INWG working notes. Later INWG became associated Processing, with DARPA the cut
International Federation for Information
back
its
its
NIC support,
and DARPA's role in INWG decreased.

techniques other
From
than the
beginning, used in
INWG was a forum at which the ARPANET were
those
considered; nonetheless, big, existing
ARPANET for a long time remained the one against which new ideas were compared. 111-102
network
Report No.
4799
The
international
packet-switching With UK PTT, the
standardization efforL urging of Date'ac,
has been especially Transpac, Telenet,
effective. and the
CCITT (the international
communications standards organization at which all of the world's communications authorities are represented) speed has with remarkable
adopted standards for connecting hosts to packet-switching networks to each other. Known as
networks and packet-switching X.25' and X.75,
these standards clearly address, issues which were first development,
for purposes of seen to be
international communication, of importance in the
ARPANET
perhaps where the
ARPANET was seen to be deficient. While today the operational primary of purpose traffic, of it the is ARPANET still in For is the
transmission
the main example,
stream of packet-switching ARPANET research is
network
development.
underway to develop:
- more efficient and loop-free rcuting algorithms - multi-destination, capabilities improved mechanisms host attachment to more than one node networ!k flow control and congestion control broadcast, and group addressing
III-103
lel
l I:n
lu
11l i
~
I
lin
li
lm
il
II
Il
II
Report No. 4799
logical host naming (i.e., more than one logical name)
to permit a single host to have
host
interface
enhancements
to
permit
internetwork
routing.
"11-lO0
Report No. 4799
1.6
Maturity and Handover to DCA A memorandum of agreement was worked out between DARPA and of
DCA for management of the ARPANET to be transferred to DCA as July 1, 1975, with a
six-month phase-over period from July 1 DCA
until December 31,
during which DARPA would continue to help
with
ARPANET
management while DCA acclimated itself to the job.

to be
The memorandum also called for a detailed transition plan written which was completed by June 1975. Along DCA,
with the transfer of ARPANET management from DARPA to
the technical functions that had been being performed at RML functions were
were also transferred to DCA and the procurement transferred from RHL to DECCO, which is
a field activity of DCA.
There are several aspects of the memorandum of agreement and the transition plan network which are worthy of mention here. The
was to be an operational DoD facility,
to be used solely sponsors" was
for government business. invented (e.g.,
The concept of "ARPANET
with sponsors being those users or collections of users NBS) who originally owned ARPANET equipment it was turned over to DCA. DCA before
DARPA, of
management
Ownership of the was to finance
equipment was to remain with the sponsors. the operation
and maintenance of the network through use of the which would recover
DCA managed Communications Industrial Fund, its costs by a pro-rated
allocation to sponsors based on the
111-105
Report No. 4~799
equipment used by the sponsors. with

miitr
DCA was the and
to
contract
initially and if
BBN
and and
SRI NIC
to
perform
ARPANET with NAC
operations initially
network
maintenance topological
functions, was
consulting
needed; it was clearly implied that to the perform first these year. functions DCA was to
DCA could retain other contractors eventually and certainly after
and thereafter if operate the network for a period of three years be provided on a necessary until equivalent service could
S111i10
= = =-
Report No. 4799
2.
OBSERVATIONS For many of the people in government, at and the major
contractors, centers
and in
the participating universities
research
the development of the ARPANET has been an exciting time their professional careers.
which will rank as a high point in In
1969 the ARPANET project represented a high risk, research useful form effort. has not The existence provided but it of
potentially the net in
high impact practical
only
communications represents a
technology to meet many short term needs,
formidable communications technology and experience base on which the Defense Department as well as the entire public and private depend diverse for advanced communications generated needs. The
sectors will strong and
experience
base
by the ARPANET in advanced
project has placed this country ahead of all others digital communications science and technology.
111-107
boo
Report No.
4799
2.1
Social Issues Somewhat expectedly, the network has facilitated a social It has
change in become
the United States computer research community. convenient for geographically
more
separated groups to The ability to
perform collaborative research and development. easily send
files of text between geographically
remote groups, ea3ily, and
the ability to'communicate via messages quickly and the
ability to collaboratively use powerful editing and document has chauged significantly the "feel" of
production facilities .ollaborative improvements in a change in
research
with remote groups.
Just as other major in
human communication in the rate of progress,
the past have resulted
this social effect of the the ARPANET
ARPANET may finally be the largest single impact of dcvelopment. A non-trivial. question of
considerable importance to the so successful. It
country is would
why the ARPANET project has been be nice if
certainly
the same formula could be applied to While timing, is possible accident, and luck
other pressing national needs. must not be discounted, it
to identify several
possible contributing factors: o Despite the fact project and that the ARPANET was a government was run at least
further
despite it
the fact that it was possible,
within the Defense Deoartment,
111-108
Report No.
4799
initially, some other of
to free the the
research
and
development
from
constraints First,
which often seriously hamper the project was entirely
activities.
unclassified. was for a
Second, very as a long
the provision of network service time provided to government
contractors
"free
good"; this allowed people to the and Third, network without being
experiment with the use of forced to make early
probably despite
ill-advised a valid about was
cost/benefit government unauthorized possible to
decisions. and use Defense of
Department
concern it
government the
facilities, without
build
ARPANET
complex Finally,
administrative procedures for access control. the ARPANET
did not have to interconnect directly with was possible to nova, the
other existing communication systems; it
explore line protocols and interface standards dL in the best ways was that could be devised. free of
Thus,
ARPANET program requirements
incredibly
"artificial"
and was able to concentrate intensively on research and development. Much it
the primary required later in was the project,
after success had been assured,
relatively
easy to reopen consideration of some of for example, the
these issues; and at the current time, Defense Communications Agency is
charging user groups
111-109
Report No.
4799
for network access, (using private
and
there
have
been
experiments
line interfaces) in the transmission of and research was etc., support done etc. of
classified data over the ARPANET,
on how to implement network login procedures, o A very convenient fact was the common DARPA
both the "network authority" and the initial early group of network users.
encourage engineering a at
It was possible for DARPA to strongly

attitude in the and cooperative when such
cooperative the time
project
cooperation was most critically necessary. In sum, the project with was an illustration of what can be
accomplished
strong
technically
sophisticated
central
management,
adequate
resources,
and
a clearheaded undeviating
concentration on the central research and development issues.

The largest single surprise of the ARPANET program has been
the
little
incredible popularity and success of network mail.

doubt that the techniques of with the ARPANET network are mail going
There is
in
developed
connection country and
program the and
to sweep the used sectors. for By
drastically in
change the public
techniques private
intercommunication
hindsight, one can easily see the reasons for this success. primary prior existing communications techniques (the U.S.
service and the telephone)
The postal
have certain serious deficiencies:
III-110
Report No. 4799
The postal service has become more expensive and its in measured in days for delivery of letters.
performance
In the case of the difficult to any
telephone, reach case), of the
our increasingly mobile society makes it desired
person (busy people are hard to reach in short
and reaching 10 distributed people within a is a essentially impossible. careful checks but it system back is is
period
time
Leaving telephone messages and a travelling
works if individual
established
with his answering service or secretary usually limited To find
frequently,
often inconvenient and is
to the prime shift working day of the secretarial world.
a busy person able to accept a phone call at the time you make it is little for truly unusual, and some officials have desks covered with with requests
pink slips reporting on telephone messages return calls.
Into this milieu was dropped a technique of
network mail where at any time of the day or night one can send a message to any number of other people and expect that message semi-instantaneously the recipients. part of all be available in to
the computer mailbox of all the habit on the
Then one only has to assume
individuals using the system to occasionally check and the
their mailboxes when they are free and not at a meeting, performance of the communications represents
an immeasurable With the
improvement over the postal service or the telephone. addition messages, of sophisticated
tools for answering messages, and categorizing
filing the
forwarding messages,
messages,
III-111
Report No.
4799
system takes on yet another step function of performance over the alternate possibilities. In the space of just a couple of years
this "computer center curiosity" became a smashing success on the ARPANET; there was a sufficiently large community of who wished to communicate, and they all individuals
were relatively mobile, The implications
and the system overnight became a way of life. of this kind of success are enormous.
Perhaps such advances no question that
would have eventually come anyway, the
but there is
ARPANET program provided a truly convincing demonstration of The change will upon the not be of overnight, terminals
the power of this approach. because it does depend
availability
accessible to wider and wider populations,
but commercial systems
are already available and substantial DoD experiments are already under way.
111-112
"Report No.
4799
2.2
Technical Lessons Leaving the broad social plane, the ARPANET program provided
several technical lessons which are worthy of general comment:.
111-113
Report No.
4799
2.2.1
Terminal Handling Rather early in the ARPANET program, the many it became clear that
terminal inadequate terminal locations.
access
to
net via the main host computers was an classes of users required direct
approach; access
to the net in
order to use major hosts at other
The first
response to this pressure was the design of (TIP) Newman problem: only by Inc. the ARPANET
the Terminal Interface Message Processor prime contractor, to Bolt Beranek a and
The TIP was to handle to be an
designed
address
limited
character-oriented
asynchronous
terminals
and
integral part of the network authority and not available for user programming or special user hard-nosed TIP design, features. This limited goal and
attitude permitted the rather rapid completion of the the fielding of many TIPs, the and the rapid availability network. Thus, the TIP
of widespread terminal access to effort was extremely successful in Unfortunately, goal and absolute but perhaps
reaching its not on
limited goal. the limited created user
surprisingly, user of
restriction in
programming the
considerable community, terminal Justified; terminals
unhappiness
portions
potential other
and created considerable pressure for access this techniques. approach to
"better"
Some of the complaining was fully servicing interactive character
had "leapfrogged"
a whole segment cf the industry that
I11-114
Report No.
4799
was concerned with batch processing and the line disciplines from such batch
use
of
synchronous Other some
processing
units. where
complaints were less rational and more self serving,
groups really wanted "a computer of their own" under the guise of obtaining terminal access to the ARPANET. Still other criticism the relative
was based on an honest difference of opinion as to ease of designing and
deploying a terminal access device that
would permit user programming and would handle a broader class of terminals. sophisticated Finally, users some who criticism were used was to provided the by highly support
terminal
"services" provided by the most advanced large hosts,
and did not
like the limited services provided by the tiny mini-host resident in the TIP. In response to this pressure, DARPA for a time supported the
development of a device called the "ARPA Network Terminal System" (ANTS). to This was a system based on a PDP-11 which was intended
provide user programming ability,
the handling of synchronous and a more powerful the goals put into the and
terminals as well as asynchronous terminals, set of services to the terminal user.
Unfortunately, were
were somewhat ambitious and, the field, the
although a few ANTS management versions of of
configuration fielded
the program, the system,
difficulty in delays in
debugging
implementation eventually led to a cessation of DARPA In response to a somewhat different set
support for the effort.
111-115
Report No. 4799
of
requirements,
another
attempt was made with a system called try to standardize,
"ELF*. improve,
Here DARPA support was provided to and deploy a PDP-11
based terminal support software for a particular
system which had been independently developed project. Again,
the hope was to permit user programming and the From the viewpoint of
handling of a wider class of terminals. deployment, the efforts to
use ELF were much more successful; and more attention However, was paid to
goals were far more limited, orderly development
and maintenance.
ELF has probably serving
been more useful as a base for individualized mini-hosts local specialized host functions than as a
means of widely terminal users.
distributed network access for large numbers of At the time the ARPANET was transferred to DCA.
primary terminal
access was still
either through the main network hosts or via the There are several morals to this
many TIPs in the network. history. First, it is
extremely
difficult to build a system is a bit like the
which can handle all possible terminals; it "everything" problem. machine
and leads to an unlimited expansion of the to software
Second,
very great attention must be paid central program
configuration
management,
design and release, close control of
central maintenance and software support, and program changes if an
evolving computer-based device is to be network. There is
deployed in considerable numbers around the still an
open technical question whether such a device could be
111-116
Report No.
4799
sensibly and cost-effectively
fielded in
a way which kwgld permit the functions of
both some level of user programming to tailor the device and
a standard set of controlled basic services; at technology a conservative to be
this point in approach
the development of the such user
precludes
programming if
a device is
widely deployed. Another related aspect of the terminal handling problem to do with the management extent of the network authority. an unsophisticated user typed at has It a
was discovered that when terminal in
a remote location and something went wrong (that is, the user typically "blamed
the proper response was not received),
the network" despite the fact that any number of possible things: the terminal itself, at the local modem, the local line, the modem
the other end of the local line. TIP), the network itself,
the terminal handling device computer, or
(e.g., any Thus,
the eventual host
similar it is
point on the return path,
could have been at fault. authority have
extremely important that the network control over
adequate
administrative
the entire collection of host computers
equipment from the terminal right through to the if it is to be in
a position to respond to such unstructured During the ARPANET
outcries of rage from the end terminal user. program, numerous "crisis" incidents
were precipitated by the the control
failure of equipment which was not in any way under of the network authority. (Perhaps
the best single example was
III-117
Report No.
4799
Bolt Ber3nek and Newman Inc.
difficulties in the local on-base telephone system at Ames it took a massive effort
where
to eventually uncover the offending its own
equipment and where the network authority was forced in
defense to participate and lead in the massive debugging activity even though the offending device, eventually found was clearly control.] The generalizable
outside the lesson networks from
network
authority's
this kind of history is that devices that attach to be extremely Either the clearly device in- somebgdy'.1 camp of
must
responsibility.
must clearly belong to the
network authority and must have built-in techniques for debugging and failure location, host organization or or the device must clearly some other well for in belong to the who
identified
group and
understands its l')cation; authorities.
responsibilities cannot sit
maintenance cracks
trouble different it is
devices
between
Although this idea is really quite
simple,
frequently overlooked. A final point on the general terminal handling problem has for dealing with
to do with the location of the "intelligence" terminal related matters. In general,
the data processing power the terminal handling
can either be in the terminal itself, in network port (e.g., or, way. of course, the TIP),
in the eventual final host computer
distributed among these three locations in some more and more
As the cost of data processing is dropping,

is appearing in the terminal itself
intelligence
and this entire
111-118
"R9
the reviewed to ensure that periodically be must matter of technological change. performance can take advantage
system
1-
III-119
Report No.
4799
2.2.2 At
Reliability and Fault Isolation the outset of the ARPANET design considerable toward For built-in example, techniques IMP-to-IMP of- fault circuits effort was and cross fail
expended recovery.
isolation could be power
patched for fault isolation, recovery neighbor. surprise enough. mechanisms
and IMPs themselves had
and mechanisms for reloading one IMP from a it was therefore somewhat of a
As the network grew, that the initial
efforts down this path were not nearly there was a nearly improve existing
Over the life of the ARPANET program, effort for to add techniques and
continuous techniques of failures.
fault isolation,
rapid recovery, that it and slowly is
and containment
The lesson probably is
difficult to have mechanisms.
too much attention to fault isolation Many interesting techniques were
recovery
added to improve the
network's ability to cope with trouble: o For critical pieces the of code such as the routing
computation, was operated.
code itself Similarly, they
was checksummed before it key data structures were
checksummed
before
were was
accessed.
This kind of that the
protection was added when it trouble in these particular
discovered
classes
of computations than simply
could cause network-wide
failures
rather
local difficulties.
111-120
Report No. 4799
It
was
discovered
that
dial-in
modems
for
remote
terminals
could break or "hang" and there %as no simple had a happened. centrally A technique was
way to discover this designed wherein
located used an
autodialer out WATS
controlled by the network authority
line to periodically dial and test 311 dial-in ports all over the network (at least in the continental United
States). o It was discovered that when a difficulty occurred in IMP which caused an automatic program reload, an the
necessary debugging information was lost and the trouble

would likely recur. dump A technique was added to
automatically attempted,
offending
code before a reload was
which then permitted comparison with a master
copy and improved capability for debugging. o The ARPANET program need was for forced a to cope with hour
the
the a day
same
simultaneous
twenty-four
continuously operating reliable system and at time relatively constant levels of growth,
modification,
and
change.
After, some early false starts when large a
changes introduced periods of substandard performance,
technique was evolved whereby greater attention was paid to dividing a large change into small incremental
III-121
Report No.
4799
changes Then,
that when
were compatible with the previous system. trouble occurred, debugging could be
concentrated
on the small incremental change or retreat
taken to the previous release. o As network users began to depend upon a "service" hosts for a wide it variety became few of more particular services, important
including message services, `hat such hosts
maintain availability
to the network. adequately as
In some cases,
a host might be operating
perceived by its own local operators and yet in not be properly servicirnZ
some way A
the network connection. the network these position
technique was added
evolved tools was
whereby to then
authority particular to urge and
software
"watch" in a
critical hosts and corrective action
by the local host authorities if
when necessary.
111-122
ki'
Report No.
4799
2.2.3
Maintenance Management In the early years of the ARPANET program, the IMPs and TIPs
of the network were maintained by subcontract to the manufacturer of the basic cost-effective mini computer (Honeywell). because However, simply of This represented had a
approach
Honeywell
maintenance
facilities in many cities. computer maintenance was
this rather standard form of inadequate for After the a high time, Bolt and the
reliability
requirements
the
ARPANET.
maintenance of' the network nodes was undertaken directly by Beranek and Newman Inc., the network prime contractor,
special new techniques were developed which greatly improved average nodal reliability. In particular,
techniques of central team
maintenance management were developed wherein a very strong of hardware
and s3ftware experts at the central Network Control close concert with a small number of field
Center acted in personnel who
became highly expert in
the IMP and TIP machines. itself it to could observe talk the
The central staff could use the network behavior of an offending node and
through the
difficulties with the local maintenance engineer. people ARPANET in
Further,
the field became much more dedicated and responsive to as compared to time-shared Honeywell
difficulties
personnel who had to take responsibility of equipment in their geographical
for many different kinds This approach to
territory.
maintenance probably has important benefits for other distributed
111-123
Report No.
4799
systems,
especially in
as
those and
systems thereby
will
increasingly
be
interconnected maintenance.
networks
accessible to central
III-124
4. ----
'~'
Report No.
4799
A. A.1
BBN ARPANET Bibliography Technical Reports BBN Report No. 1763, Message Processors January 1969. "lnitial for the Design for Interface ARPA Computer Network",
AD682905
*ADAO19160 BBN
Sinterconnection
Report
No.
of
1822, "Specifications for the a Host and an IMP", revision of
January 1976. AD730725 BBN Report No. 2161, "A Study of the ARPA Network Design and Performance", Kahn and Crowther, August 1971.
*ADA014398 BBN Report No. 2183, "Terminal Interface Message Processor User's Guide," updated version of August 1975. *ADA002481 *AD776995 BBN Report No. 2184, of November 1974. "TIP Hardware Manual," revision
BBN Report No. 2277, "Specifications for the Interconnection of Terminals and the Terminal IMP," Rettberg, revision of June 1973. BBN Report No. 2491, "Throughput in the ARPA Network S-Analysis and Measurement," McQuillan. January 1973 (text also contained in QTR No. 16, January 1973).
ADA025358
BBN Technical Information Report (TIR) Interface Message Processor Program," of June 1976 (Version 3231).
No. 89, "The updated version
"
BBN TIR No. 90, "The Network Control Center Program," updated versiQn of November 1976 (Version 131). ADA031617 BBN TIR No. 91, "The Terminal Interface Message ~Processor Program," updated version of August 19T6 (Version 400). AD781467 BBN Report No. 2831, "Adaptive Routing Algorithms for Distributed Computer Networks," McQuillan, May 1974.
ADA033351
!
A-1 Srl
!!i
llll
l! I
!11
lll~iAr
Report No.
4799
BBN TIR No. 93, "The Remote Job Entry Mini-Host," August 1974 (text also contained in QTR No. 6, July 1974). BBN Report No. 2891, "A Proposed Experiment in Packet Broadcast Satellite Communications," Rettberg and Walden, September 1974. BBN Report No. 2918, "Network Design Issues," November 1974 (text also contained in QTR No. 7, October 1974). ADA022040 BBN Report No. May 1975. 2999, "Pluribus Document 1: Document Overview," 2: System 3: Basic Advanced Functional 7"
BBN Report No. 2930, "Pluribus Handbook," January 1975. BBN Report Configurator,"
No. 3000, "Pluribus in production.
Document 4:
BBN Report No. 3001, "Pluribus Software," December 1975. BBN Report No. 2931, Software," April 1975.
Document
"Pluribus Document 5:
BBN Report No. 3002, "Pluribus Document 6: Specifications," February 1976. BBN Report Maintenance," No. 3004, "Pluribus September 1976.
Document
ADA018341
BBN Report No. 3056, "The Atlantic Satellite Packet Broadcast and Gateway Experiments," R. Binder, R. Rettberg, and D. Walden. April 1975. BBN Report No. 3126. "A Multiprocessor Design," W. Barker, September 1975.
A-2
Report No.
4799
A.2
Published Papers*
W. Teitleman and RE. Kahn, "A Network Simulation and Display Program," Proceedings of the Third Annual Princeton Conference on Information Sciences and Systems, March 1969. F.E. Heart, R.E. Kahn, S.M. Ornstein, W.R. Crowther, and D.C. Walden, "The Interface Message Processor for the ARPA Computer Network," AFIPS Conference Proceedings 36, June 1970, pp. 551-567; also in Advances in Computer Communications, W.W. Chu (ed.), Artech House Inc., 1974, pp. 300-316; also in Computer Communications, P.E. Green and R.W. Lucky (eds.), IEEE Press, 1975, pp. 375-391; also in Computer Networking, R.P. Blanc and I.W. Cotton (eds.), IEEE Press, 1976, pp. 60-76. F.E. Heart and S.M. Ornstein, "Software and Logic Design Interaction in Computer Networks," International Computer State of the Art Report No. 6: Computer NetworkS, Infotech Information Ltd., Maidenhead, Berkshire, England, pp. B23-462. R.E. Kahn, "Terminal Access to the ARPA Computer Network," in Courant Computer Science Symposium 3 -Computer Networks, R. Rustin (ed.), Prentice-Hall, Englewood Cliffs, N.J., 1972, pp. 147-166. R.E. Kahn and W.R. Crowther, "Flow Control in a Resource-Sharing Computer Network," Proceedings of the Second ACM/IEEE Symposium on Problems in the Optimization of Data Communications Systems, Palo Alto, California. October 1971, pp. 108-116; also in IEEE Transactions on Communications, Vol. COM-20, No. 3, Part II, June 1972, pp. 539-546; also in Advances in Computer Communications, Chu (ed.), Artech House Inc., 1974, pp. 230-237; also in W.W. Computer Networking, R.P. Blanc and I.W. Cotton (eds.), IEEE Press, 1976, pp. 117-125. D.C. Walden, "A System for Interprocess Communication in a Resource-Sharing Computer Network," Communications of the- ACM, Vol. 15, No. 4, April 1972, pp. 221-230; also in Advances in Computer Communications, W.W. Chu (ed.), Artech House Inc., 1974, pp. 340-349.
Ordered according to date of writing.
A-3
Report No.
4799
R.H. Thomas and D.A. Henderson, "McROSS -A Multi-Computer Programming System," AFIPS Conference Proceedings, Vol. 40, June 1972, pp. 281-293; also in Computer Networking, R.P. Blanc and I.W. Cotton (eds.), IEEE Press, 1976, pp. 246-258. S.. Ornstein, F.E. Heart, W.R. Crowther, S.B. Russell, H.K. Rising, and A. Michel, "The Terminal IMP for the ARPA Computer Network," AFIPS Conference Proceedings 40, June 1972, pp. 243-254; also in Advances in Computer Communications, W.W. Chu (ed.), Artech House Inc., 1974, pp. 317-328; also in Computer Communications, P.E. Green and R.W. Lucky (eds.), IEEE Press, 1975, pp. 354-365. H. Frank*, R.E. Kahn, and L. Kleinrock"*, "Computer Communications Network Design -Experience with Theory and Practice," AFIPS Conference Proceedings, Vol. 40, June 1972, pp. 255-270; also in Networks, Vol. 2, No. 2, 1972, pp. 135-166; also in Advances in Computer Communications, W.W. Chu (ed.), Artech House Inc., 1974, pp. 254-269. A.A. McKenzie, B.P. Cosell, J.M. McQuillan, and H.J. Thrope, "The Network Control Center. for the ARPA Network," Proceedings of the First International Conference on Computer Communication, Washington, D.C., October 1972, pp. 185-191; also in Computer Networking, R.P. Blanc and I.W. Cotton (eds.), IEEE Press, 1976, pp. 319-325. R.E. Kahn, "Resource-Sharing Computer Communications Networks," Proceedings of the IEEE, Vol. 60, No. 11, November 1972, pp. 1397-1407; also in Advances in Computer Communications, W.W. Chu (ed.), Artech House Inc., 1974, pp. 208-218; also in Computer Communications, P.E. Green and R.W. Lucky (eds.), IEEE Press, 1975, pp. 537-547. J.M. McQuillan, W.R. Crowther, B.P. Cosell, D.C. Walden, and F.E. Heart, "Improvements in the Design and Performance of the ARPA Network," AFIPS Conference Proceedings 41, December 1972, pp. 741-754.
*Network Analysis Corporation.
"**University of California at Los Angeles.
A-4
Report No.
4799
W.R.
Crowther,
R.D.
Rettberg,
D.C.
Walden,
S.M.
Ornstein,
and
F.E.
Heart.
"A
System
Reservation-ALOHA,"
for
Broadcast pp.
Conference on System Sciences,
Proceedings of the Sixth Hawaii International
Communication:
January 1973,
371-374.
D.C. Walden, "Host-to-Host Protocols," International ComputerState of the Art Report No. 24: Network Systems and Software, Infotech, Maidenhead, England, pp. 287-316. N.W. Mimno, B.P. Cosell, D.C. Walden, S.C. Butterfield, and J.B. Levin, "Terminal Access to the ARPA Network -Experience and Improvements," Proceedings of the Seventh Annual IEEE Computer Society International Conference, San Francisco, California, February 1973, pp. 39-43; also in Computer Networking, R.P. Blanc and I.W. Cotton (eds.), IEEE Press, 1976, pp. 287-291.
E.W.
Wolf,
"An
Advanced
Computer Network Systems Conference, 73-414.
Computer Communication Network," AIAA

April 1973, AIAA Paper No.
F.E. Heart,
S.M. Ornstein, W.R.
Crowther,
and W.B.
Barker,
Minicomputer/Multiprocessor for the ARPA Network," AFIPS Conference Proceedirgs 42, June 1973, pp. 529-537; also in Advances in Computer Communications, W.W. Chu (ed.), Artech House Inc., 1974, pp. 329-337; also in Computer Communication Networks, R.L. Grimsdale and F.F. Kuo (eds.), Proceedings of the NATO Advanced Study Institute of September 1973, Sussex, England, published by Noordhoff International Publishing, Leyden, The Netherlands, 1975, pp. 159-180; also in Computer Communications, P.E. Green and R.W. Lucky (eds), IEEE Press, 1975, pp. 366-374. R.H. Thomas, "A Resource Sharing Executive for the ARPANET," AFIPS Conference Proceedings 42, June 1973, pp. 155-163; also in Advances in Computer Communications, W.W. Chu (ed.), Artech House
"A New
Inc.,
1974,
pp. 359-367.
F.E. Heart, "The ARPA Network," in Computer Communication Networks, R.L. Grimadale and F.F. Kuo (eds.), Proceedings of the NATO Advanced Study Institute of September 1973, Sussex, England,
published by Noordhoff International Netherlands, 1975, pp. 19-33. Publishing, Leyden, The
W.R. Crowther, J.M. McQuillan, and D.C. Walden, "Reliability Issues in the ARPA Network," Proceedings of the ACM/IEEE Third Data Communications Symposium, November 1973, pp. 159-160; also in Computer Networking, R.P. Blanc and I.W. Cotton (eds.), IEEE Press, 1976, pp. 142-143.
A-5
Report No.
4799
Bolt Beranez and Newman Inc.
and I.W.
J.M. McQuillan, "Design Considerations for Routing Algorithms in Computer Networks," Proceedings of the Seventh Annual Hawaii International Conference on System Sciences. Honolulu, Hawaii, January 1974, pp. 22-24; also in Computer Networking, R.P. Blanc
Cotton (eds.), IEEE Press, 1976, pp. 108-110.
S.M. Ornstein, W.B. Barker, R.D. Bressler, W.R. Crowther, F.E. Heart, M.F. Kraley, A. Michel, and M.J. Thrope, "The BBN Multiprocessor," Proceedings of the Seventh Annual Hawaii International Conference on System Sciences, Honolulu, Hawaii, January 1974, Computer Nets Supplement, pp. 92-95. A.A. McKenzie, "Some Computer Nptwork Interconnection Issues." AFIPS Conference Proceedings 43, May 1974, pp. 857-859. E.A. Akkoyunlu', A.J. Bernstein*, and R.E. Schantz, "Interprocess Communication Facilities for Network Operating Systems," IEEE Compute, Vol. 7, No. 6, June 1974, pp. 46-55. F.E. Heart, "Implications of the Computer-Communication Partnership," in Preprints of Papers, MEDINFO 74: The First World Conference on Medical Informatics, Stockholm, Sweden, August 1974, pp. 21-27; proceedings to be published by North-Holland, The Netherlands. F.E. Heart. "Networks and the Life Sciences: the ARPA Network and Telenet," Federation Proceedings, Federation of American Societies for Experimental Biology (FASEB), Vol. 33, No. 12, December 1974, pp. 2399-2402; also in Computers in Life Science Research, W. Siler and D.A.B. Lindberg (eds), FASEB and Plenum Press, 1975, pp. 209-215. J.M. McQuillan, "The Evolution of Message Processing Techniques in the ARPA Network," International Computer State of the Art
Report No. 24: Network Systems
Maidenhead,
and
Software,
England,
pp.
Infotech,
541-578.
R.H. Thomas, "JSYS Traps - A TENEX Mechanism for Encapsulation of User Processes," AFIPS Conference Proceedings 44, May 1975, pp. 351-360.
*State University of New York at Stony Brook.
A-6
Report No.
4799
A. R.D. Bressler, M.F. Kraley, S.M. Ornstein, W.R. Crowther, Michel, and F.E. Heart, "Pluribus -- A Reliable Multiprocessor," AFIPS Conference Proceedings 44, May 1975, pp. 551-559. F.E. Heart, S.M. Ornstein, W.R. Crowther, W.B. Barker, M.F. "The Pluribus A. Michel, Bressler, and Kraley, R.D. Multiprocessor System." in Multiprocessor Systems: Infotech State of the Art Report, Infotech International Ltd., Maidenhead, Berkshire, England, 1976, pp. 307-330. W.R. Crowther, F.E. Heart, A.A. McKenzie, J.M. MeQuillan. and D.C. Walden, "Issues in Packet-Switching Network Design," AFIPS Conference Proceedings 44, May 1975, pp. 161-175; also in Cotton (eds.), IEEE Computer Networking, R.P. Blanc and I.W. Press, 1976, pp. 182-196. R.S. Tomlinson, "Selecting Sequence Numbers," ACM SIGCOMM-SIGOPS Interface Workshop Communications, March 1975, pp. 11-23. Proceedings of the on Interprocess
J.M. McQuillan and D.C. Walden, "Some Considerations for a High Performance Message-Based Interprocess Communication System," Proceedings of the ACM SIGCOMM-SIGOPS Interface Workshop on Interprocess Communications, March 1975, pp. 77-86. High "The Evolution of a Walden, S.M. Ornstein and D.C. Performance Modular Packet-Switch," Conference Record of the 1975 International Conference on Communications, June 1975, Vol. I, pp. 6-17 to 6-21.
R.D. Bressler, M.F. Kraley, and A. Michel, "Pluribus: a Multiprocessor for Communications Networks," Fourteenth Annual an the mid-70's: Computing in ACM/NBS Technical Symposium --
Assessment.
June 1975,
pp.
13-19.
D.C. Walden, "Experiences in Building, Operating, and Using the USA-Japan Computer Proceedings of the 2nd ARPA Network," Conference, Tokyo, Japan, August 1975, pp. 453-458. R.D. Rettberg and D.C. Walden, "Gateway Design for Computer
Networks: Communications in: Interconnection," Network on Conference Computing European the of Proceedings Communications Networks, London. England, September 1975, published by Online Conferences Limited, Uxbridge, England, 'p.
113-128.
A-7
Report No.
4799
M.F. Kraley, "The Pluribus Multiprocessor," Digest of the 1975 International Symposium on Fault-Tolerant Computing, Paris, France, June 18-20. 1975, p. 251 (abstract only). B.P. Cosell, J.M. McQuillan, and D.C. Walden, "Techniques for
Detecting and Preventing Multiprogramming Bugs," in: Minicomputer Software, J.R. Bell and C.G. Bell (eds.), North-Holland Publishing Co., 1976. pp. 301-308.
A.A. the McKenzie, "The ARPA Network Control Center," Fourth ACM Data Communications Symposium, Proceedings of Quebec City,
Canada,
October 1975,
pp. 5-1 to 5-6.
B.P. Cosell, P.R. Johnson, J.H. Malman, R.E. Schantz, J. Sussman. R.H. Thomas, and D.C. Walden, "An Operational System for Computer Resource Sharing," Proceedings of the Fifth Symposium on Operating System Principles, Austin, Texas, November 1975, pp. 75-81.
R.D.
Bressler
and
R.H.
Thomas,
"Design Issues in Distributed
Computing," in Distributed Systems: Infotech State of the Art Report, Infotech International Ltd., Maidenhead, Berkshire, England, 1976, pp. 215-222. V. Cerft, A. McKenzie, R. Scantlebury"*, and H. Zimmermann***, "Proposal for an International End to End Protocol," ACM Computer Communication Review, Vol. 6, No. 1, January 1976, pp. 63-89. W.F. Mann, S.M. Ornstein, and M.F. Kraley, "A Network-Oriented Multiprocessor Front-End Handling Many Hosts and Hundreds of Terminals", AFIPS Conference Proceedings 45, June 1976, pp.
533-540. Distributed
Technical 143-148. P.J. Santos, "Software Instrumentation for Maintainability of
Computer
Networks,"
and
Fifteenth
Annual
ACM/NBS
pp.
Symposium--Directions
Challenges,
June 1976,
J.M.
Computer Society/International Federation for Information Processing Joint International Symposium on Data Communications Technology and Practice, August 1976, pp. 13.1-13.7.
McQuillan,
"A Status
Report
on
the
ARPANET,"
Australian
*Defense Advanced Research Projects Agency
"**Institut de Recherche d'Informatique et d'Automatique

***National Physical Laboratories (U.K.)
(France)
A-8
Report No.
4799
J.M. McQuillan, "Strategies for Implementation of Multi-Host Computer Networks," ACS/IFIP Joint International Symposium on Data Communications Technology and Practice, August 1976, pp. 26.1-26.6; also in Computer Communication Review, Vol. 6, No. 4, October 1976, pp. 19-24. F.E. Heart and D.C. Walden, "Communications Applications of the Pluribus Computer," Conference Record of the 1976 IEEE National Telecommunications Conference, Dallas, Texas, 29 November-1 December 1976, pp. 7.1-1 to 7.1-5. R. Levin*, J.M. McQuillan, and R. Schantz, "Distributed Systems," a section of "New Directions for Operating Systems: Report," J.C. Browne, Operating Systems Review, Vol. A11, Workshop No. 1, January 1977, pp. 14-19. J.M. McQuillan and D.C. Walden, "Issues in Packet Switching Network Design and the ARPANET Design Decisions," submitted to Computer Networks. J. Davidson, W. Hathaway*, N. Mimno, J. Postel'*, R. Thomas, and D. Walden, "The ARPANET TELNET Protocol: Its Purpose, Principles, Implementation. and Impact on Host Operating System Design," submitted for presentation at the ACM/IEEE Fifth Data Communications Symposium, Snowbird, Utah, September 27-29, 1977.
I
";C negi e-Mllon University
*NASA Ames Research Center
USC Information Sciences Institute
A-9
Report No.
4799
B.
Selection of ARPANET Logical Maps The following logical maps of the ARPANET are included:
December 1970 April 1971 August 1971

March 1972
August 1972 September 1973 June 1974

November 1974 January 1975 June 1975 October 1975 July 1976 October 1976
January 1977
March 1977
B-i
ej
'a .
I.
0 h-0..
0.00
to'
II
400
to-
a.a
'5-
0 0
IL
1-1
0
0
I I I Iw 0.
O I
~)to
CiL
I.
(L
*
I /8
IIL
JIA
WE
IoL
IL~
4L4
CL,
Q3
Rt
inio
-- v
W I
q7
;7I-
CL
a. CL
wr
Z~~
Nlo
s.0
c.:
XLz 0.0
A.0
~o
9_0
0~ I.
-0_
L0
zI
Oc
I- W
47j
: (a cc0
0.03
f--I,
w
0.
ICI
aWc
C0
--
I.-l
0.g
CI L CL
C.
a 4 M.
1.w IL-
aacal a
IL
0a~aCl
MrI
0 .z
U))
jf I% a.
U 5
ff~
100
CL)
I4
LC
CL 0
0.
9L AL)
awL
(D
4L
~
40
-0
9LL)
0
t; CL
0
a = CL
00
cL 0 &
IL
UO UV) a: 0 qr z
CL
cL 0
a a-.
ob I
CLAL
to of w 0
0 a fn z
40 a. 00 t. "r 0 a. OU -j u u U ow 2 0 0 C% u u 4-1 Inc
0 one
000 0000
in 0 N W,
7o13
in u v
w a 0.
CL
cc u w cc 4
CL
0- a. IL 0 w v
t c 0 o 0 o
w La w 0 - 0 w w -4 1 CL.
Q
CL
us a.
.9 w z
CL 0 CL
CL CL
CL
1A
CL ca
-3 0 It
w cr< 0
a. U$ 0 il z
a7
31:
0 u
IL 43
LL U
in
W Z 0 0 z U, 0 Z
4n 49 ob 0 CL 010 0.1 10 Ion Q x u u on IL 0.
C03
x w 10-
W 00 X.C u x 04 x 0 z
8
Mc a 0. co 0. x 0 z
F.
3 [. AM
x
w V
in 2
-K w WS I-U; U) 0 z Lu i; u z Z X'd 3: CL 4L o 2
a MA
CC
X
I-
39
z
M u vi
qj
P10 % 0 0 Fm
CL CL M w
0 00to W.,
IL
00
'u
w ki IL
44
CL IL 0 IL ICL & sn a
0 x GM U, ir W 44 0 OX
-ildraiffmifl-

A History of The ARPANET The First Decade (Report) - Arlington, VA Bolt, Beranek & Newman Inc.. 1 April 1981.

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

A History of The ARPANET The First Decade (Report) - Arlington, VA Bolt, Beranek & Newman Inc.. 1 April 1981.

Diunggah oleh

Hak Cipta:

Format Tersedia

jr

"DEFENSE kDVANCED RESEARCH <PROJECTS AGENCY

The First Decade

(Prepared for DARPA by ,-- ,ranek

1400 WILSON BOULEVARD ARLINGTON, VIRGINIA 22203

Report No. 4799

A HISTORY OF THE ARPANET

The First Decade

AMOVED&'Cl YFUBLIC RWX I'0?rsGAZ SaL.UUI.IMID

Bolt Beranek and Newman Inc.

Table of Contents I. EXECUTIVE SUMMARY ARPANET PROJECT

OBJECTIVES AND RESULTS'

11-28 11-28 II-28 11-31 11-31 11-31 11-32 11-32 11-33

5. 5.1 5.2 5.3 5.4 6.

Bolt Beranek and Newman Inc.

III! A HISTORY OF THE ARPANET PROJECT,

111-2 111-5 I1I-5

1.1.1 1.1.2 1.1.3 1.2 1.3 1.4

1.4.5,:Network 1.4.5.1 1.4.5.2 1.4.5.3 1.5 1.6

Traffic Growth Topology Hosts

The Impact of the ARPANET Maturity and Handover to DCA

Report No. 4799

Bolt Beranek and Newman Inc.

2.2 2.2.1 2.2.2 2.2.3

BBN ARPANET Bibliography A.1 A.2 Technical Reports Published Papers

A-1 A-1 A-3 B-1 j

Selection of ARPANET Logical Maps

Bolt Beranek and Newman Inc.

Bolt Beranek and Newman

The research carried famous as

of the most successful program has initiated

projects ever undertaken by DARPA! extensive changes in well as in

the Defense Department's use of computers as

effects on human intercommunication,

the widespread the the

The full impact of the technical understood for

motion by this project may not be

Defense Communications Agency which has operated time.

* Defense Advanced Research Projects Agency (DARPA)

Beranek and Newman Inc.

THE ARPANET PROJECT

OBJECTIVES AND RESULTS

Bolt Beranek and Newman Inc.

productivity through resource sharing. establishing

both goals would be achieved. develop the thought in to techniques needed

prototype activity. groups of

such systems would permit users. Each system, by

resource sharing between thousands of virtue of being time-shared,

could offer any of its services to The most important criterion

another computer system on demand.

Bolt Beranek and Newman Inc.

Defense Department and society at large. computer centers in the

thousands of computer centers in operate

almost completely autonomously.

Each computer center is wishes

complete This time such of

duplicative efforts creating and

There had been other problem, such as at

standardizing the types of hardware, translation between computer

automatic each trying such to

approach had some value and utility,

the scientific certain special