As per Relevance of the word operating, we have this rfc below:
---------
< INC-PROJECT, MAP-PERSPECTIVE.NLS.14, >, 12-Aug-83 11:34
;;;;
RFC 871 September 1982
M82-47
A PERSPECTIVE ON THE ARPANET REFERENCE
M.A.
THE MITRE
Bedford, Massachusetts
The paper, by one of its developers, describes
conceptual framework in which the ARPANET
networking protocol suite, including the DoD
Transmission Control Protocol (TCP) and Internet Protocol (IP),
were designed. It also compares and contrasts several aspects
the ARPANET Reference Model (ARM) with the more widely
International Standards Organization's Reference Model for
System Interconnection (ISORM).
i
"A PERSPECTIVE ON THE ARPANET REFERENCE MODEL
M. A.
Despite the fact that "the ARPANET" stands as
proof-of-concept of intercomputer networking and, as discussed
more detail below, introduced such fundamental notions
Layering and Virtualizing to the literature, the
availability of material which appeals to the
Standards Organization's Reference Model for Open
Interconnection (ISORM) has prompted many new- comers to
field to overlook the fact that, even though it was
tacit, the designers of the ARPANET protocol suite have had
reference model of their own all the long. That is, since
before ISO even took an interest in "networking", workers in
ARPA-sponsored research community have been going about
business of doing research and development in
networking with a particular frame of reference in mind.
have, unfortunately, either been so busy with their work or
perhaps somehow unsuited temperamentally to do learned papers
abstract topics when there are interesting things to be said
specific topics, that it is only in very recent times that
has been much awareness in the research community of the
of the ISORM on the lay mind. When the author is asked to
solemn memoranda comparing such things as the ARPANET
of "internetting" with that of CCITT employing the ISORM "as
frame of reference," however, the time has clearly come
attempt to enunciate the ARPANET Reference Model (ARM
publicly--for such comparisons are painfully close to
an orange with an apple using redness and smoothness as
dominant criteria, given the philosophical closeness of the
and ISO models and their mutual disparities from the
model
This paper, then, is primarily intended as a perspective
the ARM. (Secondarily, it is intended to point out some of
differences between the ARM and the ISORM. For a perspective
this subtheme, please see Note [1]) It can't be "the official
version because the ARPANET Network Working Group (NWG),
was the collective source of the ARM, hasn't had an
general meeting since October, 1971, and can scarcely
resurrected to haggle over it. It does, at least, represent
some degree of fidelity the views of a number of NWG members
those views were expressed in NWG general meetings, NWG
design committee meetings, and private conversations over
intervening years. (Members of the current ARPA Internet
Group, which
1
RFC 871 September 1982
and adapted the original model to a broader arena than
initially been contemplated, were also consulted.) That
not sound so impressive as a pronunciamento from an
standards organization, but the reader should be
consoled by the consideration that not only are the
expressed here purported to be those of the primary workers
the field, but also at least one Englishman helped out in
review process
Historical/Philosophical
Although rigorous historians of science might quibble as
whether they were "invented" by a particular group, it is
historical fact that many now widely-accepted,
concepts of intercomputer networking were original to the
Network Working Group. [2] Before attempting to appreciate
implications of that assertion, let's attempt to define its
key terms and then cite the concepts it alludes to
By "intercomputer networking" we mean the attachment
multiple, usually general-purpose computer systems--in the
of Operating Systems of potentially different manufacture (i.e.,
"Heterogeneous Operating Systems")--to some
network, or communications networks somehow interconnected,
the purpose of achieving resource sharing amongst
participating operating systems, usually called Hosts. (
"resource sharing" we mean the potential ability for programs
each of the Hosts to interoperate with programs on the
Hosts and for data housed on each of the Hosts to be
available to the other Hosts in a more general and
fashion than merely enabling users on each of the Hosts to
able to login to the other Hosts as if they were local; that is
we expect to do more than mere "remote access" to
networked Hosts.) By "the ARPANET Network Working Group,"
mean those system programmers and computer scientists
numerous Defense Advanced Research Projects Agency-
installations whose home operating systems were intended
become early Hosts on the ARPANET. (By "the ARPANET" we mean
depending on context, either that communications
sponsored by DARPA which served as proof-of-concept for
communications technology known as "packet switching," or
consistent with common usage, the intercomputer network which
evolved by the NWG that uses that communications network--
"comm subnet"--as its inter-Host data transmission medium.)
The concepts of particular interest are as follows:
analogy to the use of the term in traditional communications,
NWG decided that the key to the mechanization of
resource-sharing goal (which in turn had been posited in
informal charter
2
RFC 871 September 1982
would be "protocols" that Hosts would interpret both
communicating with the comm subnet and in communicating with
other. Because the active entities in Hosts (the programs
execution) were widely referred to in Computer Science
"processes," it seemed clear that the mechanization of
sharing had to involve interprocess communication; protocols
enabled and employed interprocess communication became,
axiomatically, the path to the goal. Perhaps because
limitations of mere remote access were perceived early on,
perhaps simply by analogy to the similar usage with regard
distinguishing between physical tape drives and tape
associated with some conventionally-defined function like
System Input stream or the System Output stream in
operating systems, the discernible communications paths (
"channels") through the desired interprocess
mechanism became known as "logical connections"--the intent
the term being to indicate that the physical path didn't
but the designator (number) of the logical connection could
an assigned meaning, just like logical tape drive numbers
Because "modularity" was an important issue in Computer
at the time, and because the separation of Hosts and
Message Processors (IMP's) was a given, the NWG realized that
protocols it designed should be "layered," in the sense that
given set of related functions (e.g., the
communication mechanism, or "primitives," as realized in
Host-to-Host protocol) should not take special cognizance of
detailed internal mechanics of another set of related
(e.g., the comm subnet attachment mechanism, as realized in
Host-Comm Subnet Processor protocol), and that, indeed,
may be viewed as existing in a hierarchy
With the notion of achieving resource sharing via
protocols for interprocess communication over logical
fairly firmly in place, the NWG turned to how best to achieve
first step of intercomputer networking: allowing a distant
to login to a Host as if local--but with the clear
that the mechanisms employed were to be generalizable to
types of resource sharing. Here we come to the final
concept contributed by the NWG, for it was observed that if
different types of Host (i.e., different operating systems)
to be made aware of the physical characteristics of m
types of terminal in order to exercise physical control
them--or even if n different kinds of Host had to become aware
the native terminals supported by m other kinds of Hosts
physical control were to remain local--there would be
administratively intractable "n x m problem." So the notion
creating a "virtual terminal" arose, probably by analogy
"virtual memory" in the sense of something that "wasn't
there" but could be used as if
3
RFC 871 September 1982
were; that is, a common intermediate representation (CIR)
terminal characteristics was defined in order to allow the
to which a terminal was physically attached to map the
characteristics of the terminal into a CIR, so that the
being logged into, knowing the CIR as part of the
protocol, could map out of it into a form already acceptable
the native operating system. And when it came time to develop
File Transfer Protocol, the same virtualizing or CIR trick
clearly just as useful as for a terminal oriented protocol,
virtualizing became part of the axiom set too
The NWG, then, at least pioneered and probably invented
notion of doing intercomputer networking/resource sharing
hierarchical, layered protocols for interprocess
over logical connections of common intermediate representations
virtualizations. Meanwhile, outside of the ARPA
community, "the ARPANET" was perceived to be a
technological advance. "Networking" became the "in" thing.
along with popular success came the call for standards;
particular, standards based on a widely-publicized "
Model for Open System Interconnection" promulgated by
International Standards Organization. Not too surprisingly,
System Interconnection looks a lot like resource sharing,
ISORM posits a layered protocol hierarchy, "connections"
frequently, and emerging higher level protocols tend
virtualize; after all, one expects standards to reflect the
of the art in question. But even if the ISORM, suitably refined
does prove to be the wave of the future, this author feels
the ARM is by no means a whitecap, and deserves explication--
in its role as the ISORM's "roots" and as the basis of
still-viable alternative protocol suite
Let's begin with the axioms of the ARPANET Reference Model
Indeed, let's begin by recalling what an axiom is, in
usage: a principle the truth of which is deemed self-evident
Given that definition, it's not too surprising that axioms
get stated or examined in non-mathematical discourse. It
out, however, that the axiomatization of the ARM--as best we
recall and reconstruct it--is not only germane to the
of the ARM, but is also a source of instructive contrasts
our view of the axiomatization of the ISORM. (See [1] again.)
Resource
The fundamental axiom of the ARM is that
networking protocols (as distinct from communications
4
RFC 871 September 1982
protocols) are to enable heterogeneous computer operating
("Hosts") to achieve resource sharing. Indeed, the session
the 1970 SJCC in which the ARPANET entered the open
was entitled "Resource Sharing Computer Networks".
Of course, as self-evident truths, axioms rarely
much scrutiny. Just what resource sharing is isn't easy to
down--nor, for that matter, is just what Open
Interconnection is. But it must have something to do with
ability of the programs and data of the several Hosts to be
by and with programs and data on other of the Hosts in some
of cooperative fashion. It must, that is, confer
functionality upon the human user than merely the ability to
in/on to a Host miles away ("remote access").
A striking property of this axiom is that it
protocol suites such as "X.25"/"X.28"/ "X.29"
uninteresting for our purposes, for they appear to have as
fundamental axiom the ability to achieve remote access only. (
might even be a valid rule of thumb that any "network"
physically interfaces to Hosts via devices that resemble
machines--that is, which attach as if they were just a group
locally-known types of terminals--isn't a resource
network.)
Reference [3] addresses the resource sharing vs.
access topic in more detail
Interprocess
The second axiom of the ARM is that resource sharing will
achieved via an interprocess communication mechanism of
sort. Again, the concept isn't particularly well-defined in
"networking" literature. Here, however, there's
justification, for the concept is fairly well known in
Operating Systems branch of the Computer Science literature
which was the field most of the NWG members came from
Unfortunately, because intercomputer networking
communications devices of several sorts, many whose primary
is Communications became involved with "networking" but were
in a position to appreciate the implications of the axiom
A process may be viewed as the active element of a Host,
as an address space in execution, or as a "job", or as a "task",
or as a "control point"--or, actually, as any one (or more) of
least 29 definitions from at least 28 reputable
scientists. What's important for present purposes isn't
precise definition (even if there were one), but the fact
the axiom's presence dictates the absence of at least one
axiom at the same level
5
RFC 871 September 1982
abstraction. That is, we might have chosen to attempt to
resource sharing through an explicitly
communication oriented mechanism of some sort--wherein
entities being enabled to communicate were subroutines, or
of address spaces--but we didn't. Whether this was
somebody realized that you could do interprocedure
(or achieve a "virtual address space" or "distributed
system" or some such formulation) on top of an
communication mechanism (IPC), or whether "it just
obvious" to do IPC doesn't matter very much. What matters
that the axiom was chosen, assumes a fair degree of
with Operating Systems, doesn't assume extremely close
of Hosts, and has led to a working protocol suite which
achieve resource sharing--and certainly does appear to be
axiom the ISORM tacitly accepted, along with resource sharing
Logical
The next axiom has to do with whether and how to
IPC "channels", "routes", "paths", "ports", or "sockets".
is, if you're doing interprocess communication (IPC), you
have to decide whether a process can communicate with more
one other process, and, if so, how to distinguish between the
streams. (Indeed, even choosing streams rather than blocks is
decision.) Although it isn't treated particularly explicitly
the literature, it seems clear that the ARM axiom is to do
over logical connections, in the following sense: Just as
oriented operating systems found it useful to allow
(usually thought of as jobs--or even "programs") to be
from the details of which particular physical tape drives
working well enough at a particular moment to spin the
Input and Output reels, and created the view that a reference
a "logical tape number" would always get to the right
drive for the defined purpose, so too the ARM's IPC
creates logical connections between processes. That is, the
addressing mechanism has semantics as well as syntax
"Socket" n on any participating Host will be defined as
"Well-Known Socket" (W-KS) where a particular service (
mechanized by a program which follows, or "interprets",
particular protocol [4]) is found. (Note that the W-KS
defined for the "side" of a connection where a given
resides; the user side will, in order to be able to
its network-using processes, of course assign different
to its "sides" of connections to a given W-KS. Also, the
side takes cognizance of the using side's Host designation
well as the proferred socket, so it too can demultiplex.)
Clearly, you want free sockets as well as Well-Known ones, and
have them. Indeed, at each level of the
6
RFC 871 September 1982
hierarchy the addressing entities are divided into assigned
unassigned sets, and the distinction has proven to be
useful to networking researchers in that it confers upon them
ability to experiment with new functions without interfering
running mechanisms
On this axiom, the ISORM differs from the ARM.
"peer-peer" connections (or "associations") appear to be
only for demultiplexing, with the number assigned by the
side rather than the send side. That is, a separate protocol
intro- duced to establish that a particular "transport
connection will be used in the present "session" for
particular service. At the risk of editorializing,
connections seem much cleaner than "virtual" connections (
virtual in the sense of something that "isn't really there"
can be used as if it were, by analogy to virtual memory, as
above, and in deference to the X.25 term "virtual circuit",
appears to have dictated the receiver-assigned posture the
takes at its higher levels.) Although the ISORM view "works",
W-KS approach avoids the introduction of an extra protocol
The next axiom is perhaps the best-known, and
certainly the worst-understood. As best we can
things, the NWG was much taken with the Computer Science
of the times, "modularity". "Everybody knew" modularity was
Good Thing. In addition, we were given a head start because
IMP's weren't under our direct control anyway, but could
change at some future date, and we didn't want to be "locked in
to the then-current IMP-Host protocol. So it was enunciated
protocols which were to be members of the ARM suite (ARMS,
future reference, although at the time nobody used "ARM",
less "ARMS") were to be layered. It was widely agreed that
meant a given protocol's control information (i.e., the
information exchanged by counterpart protocol interpreters,
"peer entities" in ISORM terms) should be treated strictly
data by a protocol "below" it, so that you could invoke
protocol interpreter (PI) through a known interface, but
either protocol changed there would not be any dependencies
the other on the former details of the one, and as long as
interface didn't change you wouldn't have to change the PI of
protocol which hadn't changed
All well and good, if somewhat cryptic. The important
for present purposes, however, isn't a seemingly-
definition of Layering, but an appreciation of what the
meant in the evolution of the ARM. What it meant was that
tried to come
7
RFC 871 September 1982
with protocols that represented reasonable "packagings"
functionality. For reasons that are probably unknowable,
about which some conjectures will be offered subsequently,
ARM and the ISORM agree strongly on the presence of Layering
their respective axiomatizations but differ strikingly as to
packagings of functionality are considered appropriate.
anticipate a bit, the ARM concerns itself with three layers
only one of them is mandatorily traversed; whereas the ISORM
again as everybody knows, has, because of emerging "sub-layers",
what must be viewed as at least seven layers, and many who
studied it believe that all of the layers must be traversed
each transmission/reception of data
Perhaps the most significant point of all about Layering
that the most frequently-voiced charge at NWG protocol
design meetings was, "That violates Layering!" even though
had an appreciably-clearer view of what Layering meant than
been presented here, yet the ARMS exists. We can only guess
goes on in the design meetings for protocols to become members
the ISORM suite (ISORMS), but it doesn't seem likely that
more layers could possibly decrease the number of arguments....
Indeed, it's probably fair to say that the ARM view
Layering is to treat layers as quite broad functional
(Network Interface, Host-Host, and Process-Level,
Applications), the constituents of which are to be modular
E.g., in the Host-Host layer of the current ARMS, the
Protocol, IP, packages internet addressing--among
things--for both the Transmission Control Protocol, TCP,
packages reliable interprocess communication, and UDP--the
well-known User Datagram Protocol--which packages
demultiplexable interprocess communication ... and for any
IPC packaging which should prove desirable. The ISORM view,
the other hand, fundamentally treats layers as rather
functional groupings, attempting to force modularity by
additional layers for additional functions (although
"classes" view of the proposed ECMA-sponsored ISORM
protocol tends to mimic the relations between TCP, UDP, and IP).
It is, by the way, forcing this view of modularity
multiplying layers rather than by trusting the designers of
given protocol to make it usable by other protocols within
own layer that we suspect to be a major cause of the
between the ISORM and the ARM, but, as indicated, the
almost certainly is not susceptible of proof. (The
structured view of modularity will be returned to in the
major section.) At any rate, the notion that "N-entities"
communicate with one another by means of "N-1 entities" does
to us to take the ISORM out of
8
RFC 871 September 1982
intended sphere of description into the realm of prescription
where we believe it should not be, if for no other reason
that for a reference model to serve a prescriptive role
unrealizable requirements of precision, and of familiarity
all styles of operating systems, on its expositors. In
words, as it is currently presented, the ISORM hierarchy
protocols turns out to be a rather strict hierarchy,
required, "chain of command" implications akin to the
World Picture's Great Chain of Being some readers might recall
they've studied Shakespeare, whereas in the ARM a cat can
invoke a king, much less look at one
Common Intermediate
The next axiom to be considered might well not be an
in a strict sense of the term, for it is susceptible of "proof
in some sense. That is, when it came time to design the
Process-Level (roughly equivalent to ISORM Level 5.3 [5]
7) ARMS protocol, it did seem self-evident that a "
terminal" was a sound conceptual model--but it can also
demonstrated that it is. The argument, customarily
as "the N X M Problem", was sketched above; it goes as follows
If you want to let users at remote terminals log in/on to
(and you do--resource sharing doesn't preclude remote access,
subsumes it), you have a problem with Hosts' native
control software or "access methods", which only "know about
certain kinds/brands/types of terminals, but there are many
terminals out there than any Host has internalized (even
whose operating systems take a generic view of I/O and don'
allow applications programs to "expect" particular terminals).
You don't want to make N different types of Host/
System have to become aware of M different types of terminal
You don't want to limit access to users who are at one
type of terminal even if all your Hosts happen to have one
common. Therefore, you define a common
representation (CIR) of the properties of terminals--or create
Network Virtual Terminal (NVT), where "virtual" is used
analogy to "virtual memory" in the sense of something that isn'
necessarily really present physically but can be used as if
were. Each Host adds one terminal to its set of supported types
the NVT--where adding means translating/mapping from the CIR
something acceptable to the rest of the programs on your
when receiving terminal-oriented traffic "from the net",
translating/mapping to the CIR from whatever your
native representation was when sending terminal-oriented
"to the net". (And the system to which the terminal
physically attached does the same things.)
9
RFC 871 September 1982
"Virtualizing" worked so well for the protocol in
("Telnet", for TELetypewriter NETwork) that when it came time
design a File Transfer Protocol (FTP), it was employed again--
two ways, as it happens. (It also worked so well that in
circles, "Telnet" is used as a generic term for "Virtual
Protocol", just like "Kleenex" for "disposable handkerchief".)
The second way in which FTP (another generic-specific)
Common Intermediate Representations is well-known: you can
your FTP protocol interpreters (PI's) use certain "virtual"
types in ARMS FTP's and in proposed ISORMS FTP's. The first
a CIR was used deserved more publicity, though: We decided
have a command-oriented FTP, in the sense of making it
for users to cause files to be deleted from remote directories
for example, as well as simply getting a file added to a
directory. (We also wanted to be able to designate some files
be treated as input to the receiving Hosts' native "mail" system
if it had one.) Therefore, we needed an agreed-
representation of the commands--not only spelling the names,
also defining the character set, indicating the ends of lines
and so on. In less time than it takes to write about,
realized we already had such a CIR: "Telnet".
So we "used Telnet", or at any rate the NVT aspects of
protocol, as the "Presentation" protocol for the control
of FTP--but we didn't conclude from that that Telnet was a
layer than FTP. Rather, we applied the principles of
to make use of a mechanism for more than one purpose--and
didn't presume to know enough about the internals of
else's Host to dictate how the program(s) that conferred the
functionality interfaced with the program(s) that conferred
Telnet functionality. That is, on some operating systems
makes sense to let FTP get at the NVT CIR by means of
subroutine calls, on others through native IPC, and on
others by open subroutine calls (in the sense of replicating
code that does the NVT mapping within the FTP PI).
decisions are best left to the system programmers of the
Hosts. Although the ISORM takes a similar view in principle,
practice many ISORM advocates take the model
rather than descriptively and construe it to require that PI's
a given level must communicate with each other via an "N-1
entity" even within the same Host. (Still other
construe the model as dictating "monolithic" layers--i.e.,
protocols per level--but this view seems to be abating.)
One other consideration about virtualizing bears mention
it's a good servant but a bad master. That is, when you'
dealing with the amount of traffic that traverses
terminal-oriented logical (or even virtual) connection, you don'
worry much about how many CPU cycles you're "wasting" on
into and out of the NVT CIR;
10
RFC 871 September 1982
when you're dealing with files that can be millions of bits long
you probably should worry--for those CPU cycles are in a
real sense the resources you're making sharable. Therefore,
it comes to (generic) FTP's, even though we've seen it in one
two ISORM L6 proposals, having only a virtual file
model is not wise. You'd rather let one side or the other
directly between native representations where possible,
eliminate the overhead for going into and out of the CIR--
long enough files, anyway, and provided one side or the other
both willing and able to do the mapping to the
recipient's native representation
The last point leads nicely into an axiom that is
acknowledged explicitly, but does belong in the ARM list
axioms: Efficiency is a concern, in several ways. In the
place, protocol mechanisms are meant to follow the
principle of Parsimony, or Least Mechanism; witness the
immediately above about making FTP's be able to avoid the
mapping of a Virtual File approach when they can. In the
place, witness the argument further above about
implementation decisions to implementers. In the author'
opinion, the worst mistake in the ISORM isn't defining seven (
more) layers, but decreeing that "N-entities" must
via "N-1 entities" in a fashion which supports the
that it applies intra-Host as well as inter-Host. If you
the ISORM as a highrise apartment building, you are
to climb down the stairs and then back up to visit a
whose apartment is on your own floor. This might be
exercise, but CPU's don't need aerobics as far as we know
Recalling that this paper is only secondarily about
"vs." ISORM, let's duly note that in the ARM there is a
for efficiency from the perspective of participating Hosts
resources (e.g., CPU cycles and, it shouldn't be overlooked
"core") expended on interpreting protocols, and pass on to
final axiom without digressing to one or two proposed
ISORM mechanisms which seem to be extremely inefficient
The least known of the ARM axioms has to do with a
over whether particular protocol mechanisms would entail
perturbation of native mechanisms if implemented in
Hosts. That is, however reluctantly, the ARMS designers
willing to listen to claims that "you can't implement that in
system" when particular tactics were proposed and,
11
RFC 871 September 1982
grudgingly, retreat from a mechanism that seemed
natural on their home systems to one which didn't
discommode a colleague's home system. A tacit design
based on equity was employed. The classic example had to do
"electronic mail", where a desire to avoid charging for
mail led some FTP designers to think that the
mandatory "login" commands of the protocol shouldn't be
after all. But the commands were needed by some
systems to actuate not only accounting mechanisms
authentication mechanisms as well, and the process
"fielded" FTP connections was too privileged (and too busy)
contain the FTP PI as well. So (to make a complex
cryptic), a common name and password were advertised for a "free
account for incoming mail, and the login commands
mandatory (in the sense that any Host could require
issuance before it participated in FTP).
Rather than attempt to clarify the example, let's get to
moral: The point is that how well protocol mechanisms
with particular operating systems can be extremely subtle, so
order to be equitable to participating systems, you must
have your designers be sophisticated implementers or subject
designs to review by sophisticated implementers (and grant
power to them in some sense).
It is important to note that, in the author's view,
ISORM not only does not reflect application of the Principle
Equity, but it also fails to take any explicit cognizance of
necessity of properly integrating its protocol interpreters
continuing operating systems. Probably motivated by
considerations, ARMS protocols, on the other hand, represent
result of intense implementation discussion and testing
Given the foregoing discussion of its axioms, and a
that we find it impossible in light of the existence of dozens
definitions of so fundamental a notion as "process" to believe
rigorous definitions, the ARPANET Reference Model is not going
require much space to articulate. Indeed, given further
observation that we believe reference models are supposed to
descriptive rather than prescriptive, the articulation of the
can be almost terse
In order to achieve efficient, equitable resource
among dissimilar operating systems, a layered set of
communication oriented protocols is posited which
employ common intermediate representations over
connections.
12
RFC 871 September 1982
layers are distinguished, each of which may contain a number
protocols
The Network Interface layer contains those protocols
are presented as interfaces by communications
processors ("CSNP"; e.g., packet switches, bus interface units
etc.) The CSNP's are assumed to have their own protocol
protocols among themselves, which are not directly germane to
model. In particular, no assumption is made that CSNP's
different types can be directly interfaced to one another;
is, "internetting" will be accomplished by Gateways, which
special purpose systems that attach to CSNP's as if they
Hosts (see also "Gateways" below). The most significant
of the Network Interface layer is that bits presented to it by
attached Host will probably be transported by the
CSNP's to an addressed Host (or Hosts) (i.e., "reliable"
subnets are not posited--although they are, of course, allowed).
A Network layer protocol interpreter ("module") is
invoked by a Host-Host protocol PI, but may be invoked by
Process Level/Applications protocol PI, or even by a Host
interpreting no formal protocol whatsoever
The Host-Host layer contains those protocols which
interprocess communication functionality. In the
"internet" version of the ARM, the most significant property
such protocols is the ability to direct such IPC to processes
Hosts attached to "proximate networks" (i.e., to CSNP's
various autonomous communications subnetworks) other than that
the Host at hand, in addition to those on a given proximate net
(You can, by the way, get into some marvelous
arguments over whether there should be a separate Internet layer
for present purposes, we assume that the Principle of
dominates.) Another significant property of Host-Host protocols
although not a required one, is the ability to do such IPC
logical connections. Reliability, flow control, and the
to deal with "out-of-band signals" are other properties
Host-Host protocols which may be present. (See also "TCP/
Design Goals and Constraints", below.) A Host-Host PI is
invoked by a Process Level/Applications PI, but may also
invoked by a Host process interpreting no formal
whatsoever. Also, a Host need not support more than a single
possibly notional, process (that is, the code running in
"intelligent terminal" might not be viewed by its user--or
its creator--as a formal "process", but it stands as a de
one).
The Process Level/Applications layer contains
protocols which perform specific resource sharing and
access functions such as allowing users to log in/on to
Hosts, transferring files, exchanging messages, and the like
Protocols in this
13
RFC 871 September 1982
will often employ common intermediate representations,
"virtual- izations", to perform their functions, but this is
a necessary condition. They are also at liberty to use
functions performed by other protocols within the same layer
invoked in whatever fashion is appropriate within a
operating system context
Orthogonal to the layering, but consistent with it, is
notion that a "Host-Front End" protocol (H-FP), or "Host-
Processing Environment" protocol, may be employed to
Network and Host-Host layer PI's from Hosts, to
Processing Environments (e.g., to "Network Front Ends", or
BIU's, where the actual PI's reside, to be invoked by the H-FP
a distributed processing mechanism), as well as portions
Process Level/Applications protocols' functionality. The
significant property of an H-FP attached Host is that it
functionally identical to a Host with inboard PI's in operation
when viewed from another Host. (That is, Hosts which
PI's will be attached to in a flexible fashion via an
protocol, rather than in a rigid fashion via the emulation
devices already known to the operating system in question.)
Whether inboard or outboard of the Host, it is
assumed that PI's will be appropriately integrated into
containing operating systems. The Network and Host-Host
are, that is, effectively system programs (although
observation should not be construed as implying that any of
PI's must of necessity be implemented in a particular
system's "hard-core supervisor" or equivalent) and their PI'
must be able to behave as such
Figures 1 and 2 (adapted from [6]) present, respectively,
abstract rendition of the ARPANET Reference Model and
particular version of a protocol suite designed to that model
Just as one learns in Geometry that one cannot "prove"
from the figures in the text, they are intended only
supplement the prose description above. (At least they bear
resemblance to highrise apartment houses.)
TCP/IP Design Goals and
The foregoing description of the ARM, in the interests
conciseness, deferred detailed discussion of two rather
topics: just what TCP and IP (the Transmission Control
and the Internet Protocol) are "about", and just what
Gateways
14
RFC 871 September 1982
expected to play in the model. We turn to those topics now
under separate headings
As has been stated, with the success of the ARPANET [7]
both a proof-of-concept of intercomputer resource sharing via
packet-switched communications subnetwork and a (still
functional resource sharing network, a number of other bodies
research and commercial, developed "their own networks."
just the communications subnetwork was intended, with the
being to achieve remote access to attached Hosts rather
resource sharing among them, but nonetheless new
abounded. Hosts attached to the original ARPANET or to DoD
meant to be transferences of ARPANET technology should, it
perceived in the research community, be able to do
sharing (i.e., interpret common high level protocols) with
attached to these other networks. Thus, the first
goal of what was to become TCP/IP was to develop a protocol
achieve "internetting".
At roughly the same time--actually probably
prior, but not logically prior--the research community came
understand that the original ARPANET Host-Host Protocol or AH-
(often miscalled NCP because it was the most visible component
the Network Control Program of the early literature) was
flawed, particularly in the area of "robustness." The
subnet was not only relied upon to deliver messages
and in order, but it was even expected to manage the transfer
bits from Hosts to and from its nodal processors over a
interface and "link protocol" that did no error checking. So
although the ARPANET-as-subnet has proven to be quite good
managing those sorts of things, surely if internetting were to
achieved over subnets potentially much less robust than
ARPANET subnet, the second discernible goal must be
reliability of the Host-to-Host protocol. That is,
of the properties of the communications subnetworks involved
internetting, TCP is to furnish its users--whether they
processes interpreting formal protocols or simply
communicating in an ad hoc fashion--with the ability
communicate as if their respective containing Hosts were
to the best comm subnet possible (e.g., a hardwired connection).
The mechanizations considered to achieve reliability
even those for internetting were alien enough to AH-HP's style
though, and the efficiency of several of AH-HP's
mechanisms (particularly Flow Control and the notion of a
Link) had been questioned often enough, that a good Host-
protocol could not be a simple extension of AH-HP. Thus,
with the desire for reliability came a necessity to furnish
good Host-Host protocol,
15
RFC 871 September 1982
design goal easy to overlook. This is a rather subtle issue
that it brings into play a wealth of prior art. For
purposes, in practical terms it means that the "good"
(according to the technical intuition of the designers)
AH-HP--such as sockets, logical connections, Well-Known Sockets
and in general the interprocess communication premise--
retained in TCP without much discussion, while the "bad"
are equally tacitly jettisoned in favor of ones deemed
more appropriate in their own right or more consistent with
other two goals
It could be argued that other goals are discernible, but
three cited--which may be restated and compressed as a desire
offer a good Host-Host protocol to achieve
internetting--are challenging enough, when thought about hard
a few years, to justify a document of even more than this one'
length. What of the implied and/or accepted design constraints
though
The first discernible design constraint borders on
obvious: Just as the original ARPANET
packet-switching (and, unfortunately to a lesser extent,
sharing), its literature popularized the notion of "Layering."
Mechanistically, layering is easy to describe: the
information of a given protocol must be treated strictly as
by the next "lower" protocol (with processes "at the top,"
the/a transmission medium "at the bottom"), as discussed earlier
Philosophically, the notion is sufficiently subtle that
today researchers of good will still argue over what "proper
layering implies, also as discussed earlier. For
purposes, however, it suffices to observe the following
Layering is a useful concept. The precise set of
offered by a given layer is open to debate, as is the
number of layers necessary for a complete protocol suite
achieve resource sharing. (Most researchers from the
"world" tend to think of only three layers--the process
applications, or user level; the Host-Host level; and the
level--though if pressed they acknowledge that "the IMPs
have a protocol too." Adherents of the International
Organization's "Open System Interconnection" program--
appears to be how they spell resource sharing--claim that
is the right number of levels--though if pressed they
that "one or two of them have sublevels." And adherents of
Consultative Committee for International Telephony and
don't seem particularly concerned with resource sharing to
with.) At any rate, TCP and IP are constrained to operate in
(or possibly in more than one) layered protocol hierarchy
Indeed, although it is not the sole reason, this fact is
primary rationale for separating the internetting
into a discrete protocol (the Internet Protocol: IP). In
words, although
16
RFC 871 September 1982
"for" the ARM, TCP and IP are actually so layered as to be
even outside the ARM
It should be noted that as a direct consequence of
Layering constraint, TCP must be capable of operating "above"
functionally- equivalent protocol other than IP (e.g.,
interface protocol directly into a proximate comm subnet,
internetting is not being done), and IP must be capable
supporting user protocols other than TCP (e.g., a non-
"Real-Time" protocol).
Resisting the temptation to attempt to do justice to
complexities of Layering, we move on to a second
constraint, which also borders on the obvious: Only
assumptions can be made about the properties of the
communications subnetworks in play. (The "network" composed
the concatenation of such subnets is sometimes called "
catenet," though more often--and less picturesquely--merely "
internet.") After all, the main goal is to let processes
Hosts attached to, essentially, "any old (or new) net
communicate, and to limit that communication to processes
Hosts attached to comm subnets that, say, do
acknowledgments of message delivery would be remiss. [8]
Given this constraint, by the way, it is quite natural
see the more clearly Host-to-Host functions vested in TCP and
more clearly Host-to-catenet functions vested in IP. It is
however, a misconception to believe that IP was designed in
expectation that comm subnets "should" present only the "
common denominator" of functionality; rather, IP furnishes
with what amounts to an abstraction (some would say
virtualization--in the ARPANET Telnet Protocol sense
virtualizing as meaning mapping from/to a common
representation to/from a given native representation) of
properties of "any" comm subnet including, it should be noted
even one which presents an X.25 interface. That is, IP
for the application to a given transmission of whatever
properties its proximate subnet offers equivalents for;
design neither depends upon nor ignores the presence of
property other than the ability to try to get some packet of
to some destination, which surely is an irreducible minimum
the functionality of anything one would be willing to call
network
Finally, we take note of a design constraint
enunciated in the literature, but still a potent factor in
design process: Probably again stemming from the popularity
the original ARPANET, as manifested in the number of types
Hosts (i.e., operating systems) attached to it,
assumptions are made about the nature or even the "power" of
Hosts which could implement TCP/IP. Clearly, some notion
process is necessary if there is
17
RFC 871 September 1982
be interprocess communication, but even here the entire
might constitute a single process from the perspective of
catenet. Less clearly, but rather importantly, Hosts must
"be able to tell time" or at least be able to "fake"
ability; this is in order to achieve the reliability goal,
leads to a necessity for Hosts to retransmit messages (which
have gotten lost or damaged in the catenet), which in turn
to a necessity to know when to retransmit. It should be noted
however, that this does not preclude a (presumably quite
endowed) Host's simply going into a controlled loop
transmissions and retransmitting after enough megapasses
the loop have been made--if, of course, the acknowledgment
receipt of the transmission in question has not already
"in the meantime."
To conclude with a formulation somewhere between the
and the terse, TCP/IP are to constitute a means for processes
Hosts about which minimal assumptions are made to do
interprocess communication in a layered protocol suite over
catenet consisting of communications subnetworks about
minimal assumptions are made. Though it nearly goes
saying, we would probably be remiss not to conclude by
that that's a lot harder to do than to say
One other aspect of the ARPANET Reference Model
separate mention. Even though it is an exceedingly fine point
to whether it's actually "part" of the Model or merely a sine
non contextual assumption, the role of Gateways is
considerable importance to the functioning of the
Protocol, IP
As noted, the defining characteristic of a Gateway is
it attaches to two or more proximate comm subnets as if it were
Host. That is, from "the network's" point of view, Gateways
not distinguished from Hosts; rather, "normal" traffic will go
them, addressed according to the proximate net's
protocol. However, the most important property of Gateways
that they interpret a full version of IP which deals
internet routing (Host IP interpreters are permitted to take
static view of routing, sending datagrams which are destined
Hosts not directly attached to the proximate net to a
Gateway, or Gateways, addressed on the proximate net), as well
course, as with fragmentation of datagrams which, although
permissible size on one of their proximate nets, are too
for the next proximate net (which contains either the target
or still another Gateway).
18
RFC 871 September 1982
Aside from their role in routing, another property
Gateways is also of significance: Gateways do not deal
protocols above IP. That is, it is an explicit assumption of
ARM that the catenet will be "protocol compatible", in the
that no attempt will be made to translate or map
dissimilar Host-Host protocols (e.g., TCP and AH-HP)
dissimilar Process-level protocols (e.g., ARPANET FTP and
FTP) at the Gateways. The justifications for this position
somewhat complex; the interested reader is encouraged to
Reference [10]. For present purposes, however, it should
to note that the case against translating/mapping Gateways is
sound one, and that, as with the ARMS protocols, the
practical virtue of what are sometimes called "IP Gateways"
that they are in place and running
"Architectural"
As was implied earlier, one of the problems with viewing
reference model prescriptively rather than descriptively is
the articulation of the model must be more precise than
to be humanly possible. That the ISORM, in striving
superhuman precision, fails to achieve it is not grounds
censure. However, by reaching a degree of apparent
that has enticed at least some of its readers to attempt to
it in a prescriptive fashion, the ISORM has introduced a
of ambiguities which have been attributed as well to the ARM
relative laymen in intercomputer networking whose
exposure to the field was the ISORM. Therefore, we conclude
not-very-rigorous paper with a highly informal treatment
various points of confusion stemming from attempting to apply
ISORM to the ARM
(It should be noted, by the way, that one of the
striking ambiguities about the ISORM is just what role X.25
in it: We have been informed by a few ISORMites that X.25 "is
Levels 1-3, and we accepted that as factual until we were
during the review process of the present paper that "that's
what we believe in the U.K." What follows, then, is
on the assumption that the earlier reports were probably but
definitely accurate--and if it turns out to be in time to
prevent ISO from embracing X.25 exclusively by pointing out
of the problems entailed, so much the better.)
"Customized Parking Garages
The typical picture of the ISORM shows what looks like
highrises with what looks like two parking garages between them
(That is, seven layers of protocol per "Data Terminal Equipment",
three layers per "Data Circuit Terminating Equipment".)
19
RFC 871 September 1982
is that only one "style" of parking garage--i.e., one
presents an X.25 interface--is commonly understood to
available to stand beside an ISORM DTE by those who believe
ISO has adopted X.25 as its L1-3. In the ARM, on the other hand
no constraints are levied on the Communications
Processors. Thus, satellite communications, "Packet Radios",
"Ethernets" and the like are all accommodated by the ARM
Also, the sort of Outboard Processing Environment
earlier in which networking protocols are interpreted on
of the Host in a distributed processing fashion is
comfortably accommodated by the ARM. This is not to say that
couldn't develop an OPE for/to the ISORM, but rather that
so does not appear to us to be natural to it, for at least
reasons: 1. The Session Level associates sockets with processes
hence it belongs "inboard". The Presentation Level
considerable bit-diddling, hence it belongs "outboard".
Presentation Level is, unfortunately, above the Session Level
This seems to indicate that outboard processing wasn't taken
account by the formulators of the ISORM. 2. Although
ISORMites have claimed that "X.25 can be used as a Host-Front
Protocol", it doesn't look like one to us, even if the ability
do end-to-end things via what is nominally the Network
is somewhat suggestive. (Those who believe that you need
protocol as strong as TCP below X.25 to support the
circuit illusion might argue that you've actually outboarded
Host-Host layer, but both the X.25 spec and the ISORM appeal
protocols above X.25 for full L II functionality.) Perhaps,
sufficient ingenuity, one might use X.25 to convey an H-FP,
it seems clear it isn't meant to be one in and of itself
"Plenty of Roads
Based upon several pictures presented at conferences and
articles, DCE's in the X.25-based ISORM appear to many to
required to present X.25 interfaces to each other as well as
their DTE's. Metaphorically, the parking garages have
bridges between them. In the ARM, the CSNP-CSNP protocol
explicitly outside the model, thus there can be as many "roads
as needed between the ARM equivalent to ISORM parking garages
This also allays fears about the ability to take advantage
alternate routing in X.25 subnets or in X.75 internets (
both X.25 and X.75 are "hop-by-hop" oriented, and would not
to allow for alternate routing without revision).
20
RFC 871 September 1982
"Multiple Apartments Per Floor
As noted, the ISORM's strictures on inter-
communication within each "highrise" are equivalent to having
climb downstairs and then back up to visit another apartment
your own floor. The ARM explicitly expects PI's within a
to interface directly with one another when appropriate
metaphorically giving the effect of multiple apartments on
floor off a common hallway. (Also, for those who believe
ISORM implies only one protocol/apartment per layer/story,
the ARM is more flexible.)
"Elevators
The ISORM is widely construed as requiring each layer to
traversed on every transmission (although there are rumors of
forthcoming introduction of "null layers"), giving the effect
having to climb all seven stories' worth of stairs every time
enter the highrise. In the ARM, only Layer I, the
Interface layer, must be traversed; protocols in Layers II and/
III need not come into play, giving the effect of being able
take an elevator rather than climb the stairs
"Straight Clotheslines
Because they appear to have to go down to L3 for
initiation, the ISORM's Session and Transport connections are,
us, metaphorically tangled clotheslines; the ARM's
connections are straight (and go from the second floor to
second floor without needing a pole that gets in the way of
folks on the third floor--if that doesn't make a weak
totally feeble.)
"Townhouse Styles Available
Should ISORM Level 6 and 7 protocols eventuate which
desirable, the "two-story townhouse style apartments"
represent can be erected on an ARM L I - L II (Network
and Host-Host Layers) "foundation". With some clever carpentry
even ISORM L5 might be cobbled in
"Manned Customs Sheds
Although it's straining the architectural metaphor
hard, one of the unfortunate implications of the ISORM's
to address operating system integration issues is that the
of "Expedited Data" exchanges between "peer entities" might
amount to an SST flight to a foreign land where there's no one
duty
21
RFC 871 September 1982
the Customs Shed (and the door to the rest of the airport
locked from the other side). By clearly designating
Host-Host (L II) mechanism(s) which are to be used by Layer
(Process-Level/ Applications) protocols to convey "out-of-
signals", the ARM gives the effect of keeping the Customs
manned at all times. (It should be noted, by the way, that
acknowledge the difficulty of addressing system
issues without biasing the discussion toward particular systems
we feel, however, that not trying to do so is far worse
trying and failing to avoid all parochialism.)
"Ready For Immediate Occupancy
The ARM protocol suite has been implemented on a number
different operating systems. The ISORM protocol
"officially" offers at most (and not in the U.K., it should
recalled) only the highly constraining functionality of X.25
L1-L3; L4-L7 are still in the design and agreement processes
after which they must presumably be subjected to
checkout in multiple implementations before becoming
standards. The metaphorical highrises, then, are years away
being fit for occupancy, even if one is willing to accept
taste of the interior decorators who seem to insist on
in numerous features of dubious utility and making you take
furnished apartments whether you like it or not; the
buildings, on the other hand, offer stoves and refrigerators,
there's plenty of room for your own furniture-- and they're
for immediate occupancy
The architectural metaphor might have been overly
as it was, but it could have been drawn out even further to
up more issues on which the ARM appears to us to be superior
the ISORM, if our primary concern were which is "better".
fairness, the one issue it omitted which many would take to be
the ISORM's favor is that "vendor support" of interpreters of
ISORM protocols will eventually amount to a
"prefabrication", while the building of the ARM PI's is
to be labor-intensive. That would indeed be a good point, if
were well-founded. Unfortunately for its proponents, however
close scrutiny of the vendor support idea suggests that it
largely illusory (vide [11]), especially in light of the
of time it will take for the international
process to run its course, and the likelihood that
ambiguities and optional features will handicap interoperability
Rather than extend the present paper even further, then, it
fair to conclude that with the possible exception of "
support" (with which exception we
22
RFC 871 September 1982
exception, for it should be noted that a number of vendors
already offering support for TCP/IP), the ARPANET Reference
and the protocols designed in conformance with it are at
worthy of consideration by anybody who's planning to do
inter- computer networking in the next several years--
if they have operating systems with counterparts on the
ARPANET, so that most if not all of the labor intensive part
been taken care of already--irrespective of one's views on
good the ISORM protocols eventually will be
Although it has seldom been more germane to observe
"any remaining shortcomings are the author's responsibility",
this paper has benefited tremendously from the close scrutiny
constructive comments of several distinguished members of
the research community and the (DoD) Protocol Standards
Panel. The author is not only extremely grateful to, but is
extremely pleased to acknowledge his indebtedness to
following individuals (cited in alphabetical order): Mr.
Benjamin, Royal Signals and Radar Establishment (U.K.); Mr
Edward Cain, Chairman of the PSTP; Dr. Vinton Cerf, DARPA/
(at the time this was written); Dr. David Clark, M.I.T
Laboratory for Computer Science (formerly Project MAC); and Dr
Jonathan Postel, U.S.C. Information Sciences Institute
Posterity may or may not thank them for their role in turning
act of personal catharsis into a fair semblance of a "real
paper, but the author emphatically does
Notes and
[1] It almost goes without saying that the subtheme is
not intended to be a definitive statement of the
merits of the two approaches, although, as will be seen,
ARM comes out ahead, in our view. But then, the
might well say, what else should I expect from a
written by one of the developers of the ARM? To attempt
dispel thoughts of prejudgment, the author would
that although he is indeed an Old Network Boy of
ARPANET, he was not a member of the TCP/IP (the keystone
the current ARM) design team, and that he began looking
ARM "vs." ISORM from the position of "a plague on both
houses". That he has concluded that the differences
TCP/IP-based ARM intercomputer networking and X.25-
ISORM intercomputer networking are like day and night may
taken as indicative of something, but that he also
that the day is at least partly cloudy and the night is
altogether moonless should at least meliorate fears
prejudice. That is, of course
23
RFC 871 September 1982
ISORM has its merits and the ARM its demerits neither
which are dealt with here. But "A Perspective" really
"My Perspective", and the author really is more concerned
this context with exposition of the ARM than with
the ISORM, even if he couldn't resist including
comparisons subtheme because of the one-sidedness of
ISORM publicity he has perceived of late
[2] Source material for this section was primarily drawn
the author's personal experience as a member the NWG
from numerous conversations with Dr. Jonathan B. Postel
long-time Chairman of the NWG and participant in the
meetings prior to the author's involvement. (See
Acknowledgments.)
[3] Padlipsky, M. A. "The Elements of Networking Style", M81-41,
The MITRE Corporation, Bedford, MA, October 1981
[4] Yes, the notion of using "protocols" might well count as
axiom in its own right, but, no, we're not going to
to be that rigorous
[5] That is, about three tenths of the possible span
"Session" functionality, which has to do with making up
the lack of Well-Known Sockets, isn't subsumed by the
Process-Level protocols, but the rest is, or could be
[6] Davidson, J., et al., "The ARPANET Telnet Protocol:
Purpose, Principles, Implementation, and Impact on
Operating System Design," Proc Fifth Data
Symposium, ACM/IEEE, Snowbird, Utah, September, 1977.
[7] See Proceedings of the 1970 SJCC, "Resource Sharing
Networks" session, and Proceedings of the 1972 SJCC, "
ARPA Network" session for the standard open
references to the early ARPANET. Other source material
this chapter is drawn from the author's
conversations with TCP/IP's principal developers; see
Acknowledgments
[8] A strong case can be made for desiring that the comm
make a "datagram" (or "connectionless") mode of
available, based upon the desire to support
functionality as Packetized Speech, broadcast addressing
and mobile subscribers, among other things. For a
complete description of this point of view, see [9].
24
RFC 871 September 1982
purposes, we do not cite the presentation of a datagram
interface as a design constraint because it
possible--albeit undesirable--to operate IP "on top of"
comm subnet which does not present such an interface
[9] Cerf, V. G. and R. E. Lyons, "Military Requirements
Packet-Switched Networks and for Their
Standardization" Proc EASCON 1982.
[10] Padlipsky, M. A., "Gateways, Architectures and Heffalumps",
M82-51, The MITRE Corporation, Bedford, MA, September 1982.
[11] ---------- "The Illusion of Vendor Support", M82-49,
MITRE Corporation, Bedford, MA, September 1982.
NOTE: Figure 1: ARM in the Abstract, and Figure 2: ARMS
Somewhat Particularized, may be obtained by writing to:
Padlipsky, MITRE Corporation, P.O. Box 208, Bedford
Massachusetts 01730, or sending computer mail
Padlipsky@USC-ISIA
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
<