the functionality of anything one would be willing to call a
network.
Finally, we take note of a design constraint rarely
enunciated in the literature, but still a potent factor in the
design process: Probably again stemming from the popularity of
the original ARPANET, as manifested in the number of types of
Hosts (i.e., operating systems) attached to it, minimal
assumptions are made about the nature or even the "power" of the
Hosts which could implement TCP/IP. Clearly, some notion of
process is necessary if there is to
17
RFC871 September 1982
be interprocess communication, but even here the entire Host
might constitute a single process from the perspective of the
catenet. Less clearly, but rather importantly, Hosts must either
"be able to tell time" or at least be able to "fake" that
ability; this is in order to achieve the reliability goal, which
leads to a necessity for Hosts to retransmit messages (which may
have gotten lost or damaged in the catenet), which in turn leads
to a necessity to know when to retransmit. It should be noted,
however, that this does not preclude a (presumably quite modestly
endowed) Host's simply going into a controlled loop between
transmissions and retransmitting after enough megapasses through
the loop have been made--if, of course, the acknowledgment of
receipt of the transmission in question has not already arrived
"in the meantime."
To conclude with a formulation somewhere between the concise
and the terse, TCP/IP are to constitute a means for processes on
Hosts about which minimal assumptions are made to do reliable
interprocess communication in a layered protocol suite over a
catenet consisting of communications subnetworks about which
minimal assumptions are made. Though it nearly goes without
saying, we would probably be remiss not to conclude by observing
that that's a lot harder to do than to say.
Gateways
One other aspect of the ARPANET Reference Model bears
separate mention. Even though it is an exceedingly fine point as
to whether it's actually "part" of the Model or merely a sine qua
non contextual assumption, the role of Gateways is of
considerable importance to the functioning of the Internet
Protocol, IP.
As noted, the defining characteristic of a Gateway is that
it attaches to two or more proximate comm subnets as if it were a
Host. That is, from "the network's" point of view, Gateways are
not distinguished from Hosts; rather, "normal" traffic will go to
them, addressed according to the proximate net's interface
protocol. However, the most important property of Gateways is
that they interpret a full version of IP which deals with
internet routing (Host IP interpreters are permitted to take a
static view of routing, sending datagrams which are destined for
Hosts not directly attached to the proximate net to a known
Gateway, or Gateways, addressed on the proximate net), as well of
course, as with fragmentation of datagrams which, although of
permissible size on one of their proximate nets, are too large
for the next proximate net (which contains either the target Host
or still another Gateway).
18
RFC871 September 1982
Aside from their role in routing, another property of
Gateways is also of significance: Gateways do not deal with
protocols above IP. That is, it is an explicit assumption of the
ARM that the catenet will be "protocol compatible", in the sense
that no attempt will be made to translate or map between
dissimilar Host-Host protocols (e.g., TCP and AH-HP) or
dissimilar Process-level protocols (e.g., ARPANET FTP and EDN
FTP) at the Gateways. The justifications for this position are
somewhat complex; the interested reader is encouraged to see
Reference [10]. For present purposes, however, it should suffice
to note that the case against translating/mapping Gateways is a
sound one, and that, as with the ARMS protocols, the great
practical virtue of what are sometimes called "IP Gateways" is
that they are in place and running.
"Architectural" Highlights
As was implied earlier, one of the problems with viewing a
reference model prescriptively rather than descriptively is that
the articulation of the model must be more precise than appears
to be humanly possible. That the ISORM, in striving for
superhuman precision, fails to achieve it is not grounds for
censure. However, by reaching a degree of apparent precision
that has enticed at least some of its readers to attempt to use
it in a prescriptive fashion, the ISORM has introduced a number
of ambiguities which have been attributed as well to the ARM by
relative laymen in intercomputer networking whose initial
exposure to the field was the ISORM. Therefore, we conclude this
not-very-rigorous paper with a highly informal treatment of
various points of confusion stemming from attempting to apply the
ISORM to the ARM.
(It should be noted, by the way, that one of the most
striking ambiguities about the ISORM is just what role X.25 plays
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 told
during the review process of the present paper that "that's not
what we believe in the U.K." What follows, then, is predicated
on the assumption that the earlier reports were probably but not
definitely accurate--and if it turns out to be in time to help
prevent ISO from embracing X.25 exclusively by pointing out some
of the problems entailed, so much the better.)
"Customized Parking Garages"
The typical picture of the ISORM shows what looks like two
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".) The
problem
19
RFC871 September 1982
is that only one "style" of parking garage--i.e., one which
presents an X.25 interface--is commonly understood to be
available to stand beside an ISORM DTE by those who believe that
ISO has adopted X.25 as its L1-3. In the ARM, on the other hand,
no constraints are levied on the Communications Subnetwork
Processors. Thus, satellite communications, "Packet Radios",
"Ethernets" and the like are all accommodated by the ARM.
Also, the sort of Outboard Processing Environment mentioned
earlier in which networking protocols are interpreted on behalf
of the Host in a distributed processing fashion is quite
comfortably accommodated by the ARM. This is not to say that one
couldn't develop an OPE for/to the ISORM, but rather that doing
so does not appear to us to be natural to it, for at least two
reasons: 1. The Session Level associates sockets with processes,
hence it belongs "inboard". The Presentation Level involves
considerable bit-diddling, hence it belongs "outboard". The
Presentation Level is, unfortunately, above the Session Level.
This seems to indicate that outboard processing wasn't taken into
account by the formulators of the ISORM. 2. Although some
ISORMites have claimed that "X.25 can be used as a Host-Front End
Protocol", it doesn't look like one to us, even if the ability to
do end-to-end things via what is nominally the Network interface
is somewhat suggestive. (Those who believe that you need a
protocol as strong as TCP below X.25 to support the virtual
circuit illusion might argue that you've actually outboarded the
Host-Host layer, but both the X.25 spec and the ISORM appeal to
protocols above X.25 for full L II functionality.) Perhaps, with
sufficient ingenuity, one might use X.25 to convey an H-FP, but
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 in
articles, DCE's in the X.25-based ISORM appear to many to be
required to present X.25 interfaces to each other as well as to
their DTE's. Metaphorically, the parking garages have single
bridges between them. In the ARM, the CSNP-CSNP protocol is
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 of
alternate routing in X.25 subnets or in X.75 internets (because
both X.25 and X.75 are "hop-by-hop" oriented, and would not seem
to allow for alternate routing without revision).
20
RFC871 September 1982
"Multiple Apartments Per Floor"
As noted, the ISORM's strictures on inter-entity
communication within each "highrise" are equivalent to having to
climb downstairs and then back up to visit another apartment on
your own floor. The ARM explicitly expects PI's within a layer
to interface directly with one another when appropriate,
metaphorically giving the effect of multiple apartments on each
floor off a common hallway. (Also, for those who believe the
ISORM implies only one protocol/apartment per layer/story, again
the ARM is more flexible.)
"Elevators"
The ISORM is widely construed as requiring each layer to be
traversed on every transmission (although there are rumors of the
forthcoming introduction of "null layers"), giving the effect of
having to climb all seven stories' worth of stairs every time you
enter the highrise. In the ARM, only Layer I, the Network
Interface layer, must be traversed; protocols in Layers II and/or
III need not come into play, giving the effect of being able to
take an elevator rather than climb the stairs.
"Straight Clotheslines"
Because they appear to have to go down to L3 for their
initiation, the ISORM's Session and Transport connections are, to
us, metaphorically tangled clotheslines; the ARM's logical
connections are straight (and go from the second floor to the
second floor without needing a pole that gets in the way of the
folks on the third floor--if that doesn't make a weak metaphor
totally feeble.)
"Townhouse Styles Available"
Should ISORM Level 6 and 7 protocols eventuate which are
desirable, the "two-story townhouse style apartments" they
represent can be erected on an ARM L I - L II (Network Interface
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 quite
hard, one of the unfortunate implications of the ISORM's failure
to address operating system integration issues is that the notion
of "Expedited Data" exchanges between "peer entities" might only
amount to an SST flight to a foreign land where there's no one on
duty at
21
RFC871 September 1982
the Customs Shed (and the door to the rest of the airport is
locked from the other side). By clearly designating the
Host-Host (L II) mechanism(s) which are to be used by Layer III
(Process-Level/ Applications) protocols to convey "out-of-band
signals", the ARM gives the effect of keeping the Customs Sheds
manned at all times. (It should be noted, by the way, that we
acknowledge the difficulty of addressing system integration
issues without biasing the discussion toward particular systems;
we feel, however, that not trying to do so is far worse than
trying and failing to avoid all parochialism.)
"Ready For Immediate Occupancy"
The ARM protocol suite has been implemented on a number of
different operating systems. The ISORM protocol suite
"officially" offers at most (and not in the U.K., it should be
recalled) only the highly constraining functionality of X.25 as
L1-L3; L4-L7 are still in the design and agreement processes,
after which they must presumably be subjected to stringent
checkout in multiple implementations before becoming useful
standards. The metaphorical highrises, then, are years away from
being fit for occupancy, even if one is willing to accept the
taste of the interior decorators who seem to insist on building
in numerous features of dubious utility and making you take fully
furnished apartments whether you like it or not; the ARM
buildings, on the other hand, offer stoves and refrigerators, but
there's plenty of room for your own furniture-- and they're ready
for immediate occupancy.
Conclusion
The architectural metaphor might have been overly extended
as it was, but it could have been drawn out even further to point
up more issues on which the ARM appears to us to be superior to
the ISORM, if our primary concern were which is "better". In
fairness, the one issue it omitted which many would take to be in
the ISORM's favor is that "vendor support" of interpreters of the
ISORM protocols will eventually amount to a desirable
"prefabrication", while the building of the ARM PI's is believed
to be labor-intensive. That would indeed be a good point, if it
were well-founded. Unfortunately for its proponents, however,
close scrutiny of the vendor support idea suggests that it is
largely illusory (vide [11]), especially in light of the amount
of time it will take for the international standardization
process to run its course, and the likelihood that specification
ambiguities and optional features will handicap interoperability.
Rather than extend the present paper even further, then, it seems
fair to conclude that with the possible exception of "vendor
support" (with which exception we take
22
RFC871 September 1982
exception, for it should be noted that a number of vendors are
already offering support for TCP/IP), the ARPANET Reference Model
and the protocols designed in conformance with it are at least
worthy of consideration by anybody who's planning to do real
inter- computer networking in the next several years--especially
if they have operating systems with counterparts on the present
ARPANET, so that most if not all of the labor intensive part has
been taken care of already--irrespective of one's views on how
good the ISORM protocols eventually will be.
Acknowledgments
Although it has seldom been more germane to observe that
"any remaining shortcomings are the author's responsibility",
this paper has benefited tremendously from the close scrutiny and
constructive comments of several distinguished members of both
the research community and the (DoD) Protocol Standards Technical
Panel. The author is not only extremely grateful to, but is also
extremely pleased to acknowledge his indebtedness to the
following individuals (cited in alphabetical order): Mr. Trevor
Benjamin, Royal Signals and Radar Establishment (U.K.); Mr.
Edward Cain, Chairman of the PSTP; Dr. Vinton Cerf, DARPA/IPTO
(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 an
act of personal catharsis into a fair semblance of a "real"
paper, but the author emphatically does.
Notes and References
[1] It almost goes without saying that the subtheme is certainly
not intended to be a definitive statement of the relative
merits of the two approaches, although, as will be seen, the
ARM comes out ahead, in our view. But then, the reader
might well say, what else should I expect from a paper
written by one of the developers of the ARM? To attempt to
dispel thoughts of prejudgment, the author would observe
that although he is indeed an Old Network Boy of the
ARPANET, he was not a member of the TCP/IP (the keystone of
the current ARM) design team, and that he began looking into
ARM "vs." ISORM from the position of "a plague on both your
houses". That he has concluded that the differences between
TCP/IP-based ARM intercomputer networking and X.25-based
ISORM intercomputer networking are like day and night may be
taken as indicative of something, but that he also holds
that the day is at least partly cloudy and the night is not
altogether moonless should at least meliorate fears of
prejudice. That is, of course the
23
RFC871 September 1982
ISORM has its merits and the ARM its demerits neither of
which are dealt with here. But "A Perspective" really means
"My Perspective", and the author really is more concerned in
this context with exposition of the ARM than with twitting
the ISORM, even if he couldn't resist including the
comparisons subtheme because of the one-sidedness of the
ISORM publicity he has perceived of late.
[2] Source material for this section was primarily drawn from
the author's personal experience as a member the NWG and
from numerous conversations with Dr. Jonathan B. Postel,
long-time Chairman of the NWG and participant in the design
meetings prior to the author's involvement. (See also
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 an
axiom in its own right, but, no, we're not going to pretend
to be that rigorous.
[5] That is, about three tenths of the possible span of
"Session" functionality, which has to do with making up for
the lack of Well-Known Sockets, isn't subsumed by the ARM
Process-Level protocols, but the rest is, or could be.
[6] Davidson, J., et al., "The ARPANET Telnet Protocol: Its
Purpose, Principles, Implementation, and Impact on Host
Operating System Design," Proc Fifth Data Communications
Symposium, ACM/IEEE, Snowbird, Utah, September, 1977.
[7] See Proceedings of the 1970 SJCC, "Resource Sharing Computer
Networks" session, and Proceedings of the 1972 SJCC, "The
ARPA Network" session for the standard open literature
references to the early ARPANET. Other source material for
this chapter is drawn from the author's personal
conversations with TCP/IP's principal developers; see also
Acknowledgments.
[8] A strong case can be made for desiring that the comm subnets
make a "datagram" (or "connectionless") mode of interface
available, based upon the desire to support such
functionality as Packetized Speech, broadcast addressing,
and mobile subscribers, among other things. For a more
complete description of this point of view, see [9]. For
present
24
RFC871 September 1982
purposes, we do not cite the presentation of a datagram mode
interface as a design constraint because it is
possible--albeit undesirable--to operate IP "on top of" a
comm subnet which does not present such an interface.
[9] Cerf, V. G. and R. E. Lyons, "Military Requirements for
Packet-Switched Networks and for Their Protocol
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, The
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: Mike
Padlipsky, MITRE Corporation, P.O. Box 208, Bedford,
Massachusetts 01730, or sending computer mail to
Padlipsky@USC-ISIA.