doc: Add RFC documents

1 files changed, 1583 insertions, 0 deletions

diff --git a/doc/rfc/rfc871.txt b/doc/rfc/rfc871.txt
new file mode 100644
index 0000000..b423214
--- /dev/null
+++ b/doc/rfc/rfc871.txt
@@ -0,0 +1,1583 @@
+
+
+
+
+
+---------
+
+
+     < INC-PROJECT, MAP-PERSPECTIVE.NLS.14, >, 12-Aug-83 11:34 AMW
+     ;;;;
+     
+     
+
+
+
+     RFC 871                                            September 1982
+                                                                M82-47
+
+
+
+
+
+
+
+               A PERSPECTIVE ON THE ARPANET REFERENCE MODEL
+     
+
+
+
+     
+     
+
+     
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              M.A. PADLIPSKY
+                           THE MITRE CORPORATION
+                          Bedford, Massachusetts
+     
+     
+
+
+
+                                 Abstract
+     
+
+     
+
+          The paper, by one of its developers, describes the
+     conceptual framework in which the ARPANET intercomputer
+     networking protocol suite, including the DoD standard
+     Transmission Control Protocol (TCP) and Internet Protocol (IP),
+     were designed.  It also compares and contrasts several aspects of
+     the ARPANET Reference Model (ARM) with the more widely publicized
+     International Standards Organization's Reference Model for Open
+     System Interconnection (ISORM).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                     i
+          
+     
+     
+     
+              "A PERSPECTIVE ON THE ARPANET REFERENCE MODEL"
+
+                              M. A. Padlipsky
+     
+     
+     
+
+                               Introduction
+
+          Despite the fact that "the ARPANET" stands as the
+     proof-of-concept of intercomputer networking and, as discussed in
+     more detail below, introduced such fundamental notions as
+     Layering and Virtualizing to the literature, the wide
+     availability of material which appeals to the International
+     Standards Organization's Reference Model for Open System
+     Interconnection (ISORM) has prompted many new- comers to the
+     field to overlook the fact that, even though it was largely
+     tacit, the designers of the ARPANET protocol suite have had a
+     reference model of their own all the long.  That is, since well
+     before ISO even took an interest in "networking", workers in the
+     ARPA-sponsored research community have been going about their
+     business of doing research and development in intercomputer
+     networking with a particular frame of reference in mind.  They
+     have, unfortunately, either been so busy with their work or were
+     perhaps somehow unsuited temperamentally to do learned papers on
+     abstract topics when there are interesting things to be said on
+     specific topics, that it is only in very recent times that there
+     has been much awareness in the research community of the impact
+     of the ISORM on the lay mind.  When the author is asked to review
+     solemn memoranda comparing such things as the ARPANET treatment
+     of "internetting" with that of CCITT employing the ISORM "as the
+     frame of reference," however, the time has clearly come to
+     attempt to enunciate the ARPANET Reference Model (ARM)
+     publicly--for such comparisons are painfully close to comparing
+     an orange with an apple using redness and smoothness as the
+     dominant criteria, given the philosophical closeness of the CCITT
+     and ISO models and their mutual disparities from the ARPANET
+     model.
+
+          This paper, then, is primarily intended as a perspective on
+     the ARM.  (Secondarily, it is intended to point out some of the
+     differences between the ARM and the ISORM. For a perspective on
+     this subtheme, please see Note [1])  It can't be "the official"
+     version because the ARPANET Network Working Group (NWG), which
+     was the collective source of the ARM, hasn't had an official
+     general meeting since October, 1971, and can scarcely be
+     resurrected to haggle over it.  It does, at least, represent with
+     some degree of fidelity the views of a number of NWG members as
+     those views were expressed in NWG general meetings, NWG protocol
+     design committee meetings, and private conversations over the
+     intervening years. (Members of the current ARPA Internet Working
+     Group, which applied
+
+
+                                     1
+     RFC 871                                            September 1982
+
+
+     and adapted the original model to a broader arena than had
+     initially been contemplated, were also consulted.)  That might
+     not sound so impressive as a pronunciamento from an international
+     standards organization, but the reader should be somewhat
+     consoled by the consideration that not only are the views
+     expressed here purported to be those of the primary workers in
+     the field, but also at least one Englishman helped out in the
+     review process.
+
+                     Historical/Philosophical Context
+
+          Although rigorous historians of science might quibble as to
+     whether they were "invented" by a particular group, it is  an
+     historical fact that many now widely-accepted, fundamental
+     concepts of intercomputer networking were original to the ARPANET
+     Network Working Group. [2]  Before attempting to appreciate the
+     implications of that assertion, let's attempt to define its two
+     key terms and then cite the concepts it alludes to:
+
+          By "intercomputer networking"  we mean the attachment of
+     multiple, usually general-purpose computer systems--in the sense
+     of Operating Systems of potentially different manufacture (i.e.,
+     "Heterogeneous Operating Systems")--to some communications
+     network, or communications networks somehow interconnected, for
+     the purpose of achieving resource sharing amongst the
+     participating operating systems, usually called Hosts.  (By
+     "resource sharing" we mean the  potential ability for programs on
+     each of the Hosts to interoperate with programs on the other
+     Hosts and for data housed on each of the Hosts to be made
+     available to the other Hosts in a more general and flexible
+     fashion than merely enabling users on each of the Hosts to be
+     able to login to the other Hosts as if they were local; that is,
+     we expect to do more than mere "remote access" to intercomputer
+     networked Hosts.)  By "the ARPANET Network Working Group," we
+     mean those system programmers and computer scientists from
+     numerous Defense Advanced Research Projects Agency-sponsored
+     installations whose home operating systems were intended to
+     become early Hosts on the ARPANET.  (By "the ARPANET" we mean,
+     depending on context, either that communications network
+     sponsored by DARPA which served as proof-of-concept for the
+     communications technology known as "packet switching," or,
+     consistent with common usage, the intercomputer network which was
+     evolved by the NWG that uses that communications network--or
+     "comm subnet"--as its inter-Host data transmission medium.)
+
+          The concepts of particular interest are as follows:  By
+     analogy to the use of the term in traditional communications, the
+     NWG decided that the key to the mechanization of the
+     resource-sharing goal (which in turn had been posited in their
+     informal charter)
+
+
+
+
+
+                                     2
+     RFC 871                                            September 1982
+
+
+     would be "protocols" that Hosts would interpret both in
+     communicating with the comm subnet and in communicating with each
+     other.  Because the active entities in Hosts (the programs in
+     execution) were widely referred to in Computer Science as
+     "processes," it seemed clear that the mechanization of resource
+     sharing had to involve interprocess communication; protocols that
+     enabled and employed interprocess communication became, almost
+     axiomatically, the path to the goal.  Perhaps because the
+     limitations of mere remote access were perceived early on, or
+     perhaps simply by analogy to the similar usage with regard to
+     distinguishing between physical tape drives and tape drives
+     associated with some conventionally-defined function like the
+     System Input stream or the System Output stream in batch
+     operating systems, the discernible communications paths (or
+     "channels") through the desired interprocess communication
+     mechanism became known as "logical connections"--the intent of
+     the term being to indicate that the physical path didn't matter
+     but the designator (number) of the logical connection could have
+     an assigned meaning, just like logical tape drive numbers.
+     Because "modularity" was an important issue in Computer Science
+     at the time, and because the separation of Hosts and Interface
+     Message Processors (IMP's) was a given, the NWG realized that the
+     protocols it designed should be "layered," in the sense that a
+     given set of related functions (e.g., the interprocess
+     communication mechanism, or "primitives," as realized in a
+     Host-to-Host protocol) should not take special cognizance of the
+     detailed internal mechanics of another set of related functions
+     (e.g., the comm subnet attachment mechanism, as realized in a
+     Host-Comm Subnet Processor protocol), and that, indeed, protocols
+     may be viewed as existing in a hierarchy.
+
+          With the notion of achieving resource sharing via layered
+     protocols for interprocess communication over logical connections
+     fairly firmly in place, the NWG turned to how best to achieve the
+     first step of intercomputer networking:  allowing a distant user
+     to login to a Host as if local--but with the clear understanding
+     that the mechanisms employed were to be generalizable to other
+     types of resource sharing.  Here we come to the final fundamental
+     concept contributed by the NWG, for it was observed that if n
+     different types of Host (i.e., different operating systems) had
+     to be made aware of the physical characteristics of m different
+     types of terminal in order to exercise physical control over
+     them--or even if n different kinds of Host had to become aware of
+     the native terminals supported by m other kinds of Hosts if
+     physical control were to remain local--there would be an
+     administratively intractable "n x m problem."  So the notion of
+     creating a "virtual terminal" arose, probably by analogy to
+     "virtual memory" in the sense of something that "wasn't really
+     there" but could be used as if it
+
+
+
+
+
+
+                                     3
+     RFC 871                                            September 1982
+
+
+     were; that is, a common intermediate representation (CIR) of
+     terminal characteristics was defined in order to allow the Host
+     to which a terminal was physically attached to map the particular
+     characteristics of the terminal into a CIR, so that the Host
+     being logged into, knowing the CIR as part of the relevant
+     protocol, could map out of it into a form already acceptable to
+     the native operating system.  And when it came time to develop a
+     File Transfer Protocol, the same virtualizing or CIR trick was
+     clearly just as useful as for a terminal oriented protocol, so
+     virtualizing became part of the axiom set too.
+
+          The NWG, then, at least pioneered and probably invented the
+     notion of doing intercomputer networking/resource sharing via
+     hierarchical, layered protocols for interprocess communication
+     over logical connections of common intermediate representations/
+     virtualizations.  Meanwhile, outside of the ARPA research
+     community, "the ARPANET" was perceived to be a major
+     technological advance. "Networking" became the "in" thing.  And
+     along with popular success came the call for standards; in
+     particular, standards based on a widely-publicized "Reference
+     Model for Open System Interconnection" promulgated by the
+     International Standards Organization.  Not too surprisingly, Open
+     System Interconnection looks a lot like resource sharing, the
+     ISORM posits a layered protocol hierarchy, "connections" occur
+     frequently, and emerging higher level protocols tend to
+     virtualize; after all, one expects standards to reflect the state
+     of the art in question.  But even if the ISORM, suitably refined,
+     does prove to be the wave of the future, this author feels that
+     the ARM is by no means a whitecap, and deserves explication--both
+     in its role as the ISORM's "roots" and as the basis of a
+     still-viable alternative protocol suite.
+
+                              Axiomatization
+
+          Let's begin with the axioms of the ARPANET Reference Model.
+     Indeed, let's begin by recalling what an axiom is, in common
+     usage: a principle the truth of which is deemed self-evident.
+     Given that definition, it's not too surprising that axioms rarely
+     get stated or examined in non-mathematical discourse.  It turns
+     out, however, that the axiomatization of the ARM--as best we can
+     recall and reconstruct it--is not only germane to the enunciation
+     of the ARM, but is also a source of instructive contrasts with
+     our view of the axiomatization of the ISORM.  (See [1] again.)
+
+     Resource Sharing
+
+          The fundamental axiom of the ARM is that intercomputer
+     networking protocols (as distinct from communications network
+
+
+
+
+
+
+
+                                     4
+     RFC 871                                            September 1982
+
+
+     protocols) are to enable heterogeneous computer operating systems
+     ("Hosts") to achieve resource sharing.  Indeed, the session at
+     the 1970 SJCC in which the ARPANET entered the open literature
+     was entitled "Resource Sharing Computer Networks".
+
+          Of course, as self-evident truths, axioms rarely receive
+     much scrutiny.  Just what resource sharing is isn't easy to pin
+     down--nor, for that matter, is just what Open System
+     Interconnection is. But it must have something to do with the
+     ability of the programs and data of the several Hosts to be used
+     by and with programs and data on other of the Hosts in some sort
+     of cooperative fashion.  It must, that is, confer more
+     functionality upon the human user than merely the ability to log
+     in/on to a Host miles away ("remote access").
+
+          A striking property of this axiom is that it renders
+     protocol suites such as "X.25"/"X.28"/ "X.29" rather
+     uninteresting for our purposes, for they appear to have as their
+     fundamental axiom the ability to achieve remote access only.  (It
+     might even be a valid rule of thumb that any "network" which
+     physically interfaces to Hosts via devices that resemble milking
+     machines--that is, which attach as if they were just a group of
+     locally-known types of terminals--isn't a resource sharing
+     network.)
+
+          Reference [3] addresses the resource sharing vs. remote
+     access topic in more detail.
+
+     Interprocess Communication
+
+          The second axiom of the ARM is that resource sharing will be
+     achieved via an interprocess communication mechanism of some
+     sort.  Again, the concept isn't particularly well-defined in the
+     "networking" literature.  Here, however, there's some
+     justification, for the concept is fairly well known in the
+     Operating Systems branch of the Computer Science literature,
+     which was the field most of the NWG members came from.
+     Unfortunately, because intercomputer networking involves
+     communications devices of several sorts, many whose primary field
+     is Communications became involved with "networking" but were not
+     in a position to appreciate the implications of the axiom.
+
+          A process may be viewed as the active element of a Host, or
+     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 at
+     least 29 definitions from at least 28 reputable computer
+     scientists.  What's important for present purposes isn't the
+     precise definition (even if there were one), but the fact that
+     the axiom's presence dictates the absence of at least one other
+     axiom at the same level of
+
+
+
+
+
+                                     5
+     RFC 871                                            September 1982
+
+
+     abstraction.  That is, we might have chosen to attempt to achieve
+     resource sharing through an explicitly interprocedure
+     communication oriented mechanism of some sort--wherein the
+     entities being enabled to communicate were subroutines, or pieces
+     of address spaces--but we didn't.  Whether this was because
+     somebody realized that you could do interprocedure communication
+     (or achieve a "virtual address space" or "distributed operating
+     system" or some such formulation) on top of an interprocess
+     communication mechanism (IPC), or whether "it just seemed
+     obvious" to do IPC doesn't matter very much.  What matters is
+     that the axiom was chosen, assumes a fair degree of familiarity
+     with Operating Systems, doesn't assume extremely close coupling
+     of Hosts, and has led to a working protocol suite which does
+     achieve resource sharing--and certainly does appear to be an
+     axiom the ISORM tacitly accepted, along with resource sharing.
+
+     Logical Connections
+
+          The next axiom has to do with whether and how to demultiplex
+     IPC "channels", "routes", "paths", "ports", or "sockets".  That
+     is, if you're doing interprocess communication (IPC), you still
+     have to decide whether a process can communicate with more than
+     one other process, and, if so, how to distinguish between the bit
+     streams. (Indeed, even choosing streams rather than blocks is a
+     decision.) Although it isn't treated particularly explicitly in
+     the literature, it seems clear that the ARM axiom is to do IPC
+     over logical connections, in the following sense:  Just as batch
+     oriented operating systems found it useful to allow processes
+     (usually thought of as jobs--or even "programs") to be insulated
+     from the details of which particular physical tape drives were
+     working well enough at a particular moment to spin the System
+     Input and Output reels, and created the view that a reference to
+     a "logical tape number" would always get to the right physical
+     drive for the defined purpose, so too the ARM's IPC mechanism
+     creates logical connections between processes.  That is, the IPC
+     addressing mechanism has semantics as well as syntax.
+
+          "Socket" n on any participating Host will be defined as the
+     "Well-Known Socket" (W-KS) where a particular service (as
+     mechanized by a program which follows, or "interprets", a
+     particular  protocol [4]) is found.  (Note that the W-KS is
+     defined for the "side" of a connection where a given service
+     resides; the user side will, in  order to be able to demultiplex
+     its network-using processes, of course assign different numbers
+     to its "sides" of connections to a given W-KS.  Also, the serving
+     side takes cognizance of the using side's Host designation as
+     well as the proferred socket, so it too can demultiplex.)
+     Clearly, you want free sockets as well as Well-Known ones, and we
+     have them.  Indeed, at each level of the ARM
+
+
+
+
+
+
+                                     6
+     RFC 871                                            September 1982
+
+
+     hierarchy the addressing entities are divided into assigned and
+     unassigned sets, and the distinction has proven to be quite
+     useful to networking researchers in that it confers upon them the
+     ability to experiment with new functions without interfering with
+     running mechanisms.
+
+          On this axiom, the ISORM differs from the ARM.  ISORM
+     "peer-peer" connections (or "associations") appear to be used
+     only for demultiplexing, with the number assigned by the receive
+     side rather than the send side.  That is, a separate protocol is
+     intro- duced to establish that a particular "transport"
+     connection will be used in the present "session" for some
+     particular service.  At the risk of editorializing, logical
+     connections seem much cleaner than "virtual" connections (using
+     virtual in the sense of something that "isn't really there" but
+     can be used as if it were, by analogy to virtual memory, as noted
+     above, and in deference to the X.25 term "virtual circuit", which
+     appears to have dictated the receiver-assigned posture the ISORM
+     takes at its higher levels.) Although the ISORM view "works", the
+     W-KS approach avoids the introduction of an extra protocol.
+
+     Layering
+
+          The next axiom is perhaps the best-known, and almost
+     certainly the worst-understood.  As best we can reconstruct
+     things, the NWG was much taken with the Computer Science buzzword
+     of the times, "modularity".  "Everybody knew" modularity was a
+     Good Thing.  In addition, we were given a head start because the
+     IMP's weren't under our direct control anyway, but could possibly
+     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 that
+     protocols which were to be members of the ARM suite (ARMS, for
+     future reference, although at the time nobody used "ARM", much
+     less "ARMS") were to be layered.  It was widely agreed that this
+     meant a given protocol's control information (i.e., the control
+     information exchanged by counterpart protocol interpreters, or
+     "peer entities" in ISORM terms) should be treated strictly as
+     data by a protocol "below" it, so that you could invoke a
+     protocol interpreter (PI) through a known interface, but if
+     either protocol changed there would not be any dependencies in
+     the other on the former details of the one, and as long as the
+     interface didn't change you wouldn't have to change the PI of the
+     protocol which hadn't changed.
+
+          All well and good, if somewhat cryptic.  The important point
+     for present purposes, however, isn't a seemingly-rigorous
+     definition of Layering, but an appreciation of what the axiom
+     meant in the evolution of the ARM.  What it meant was that we
+     tried to come up
+
+
+
+
+
+
+                                     7
+     RFC 871                                            September 1982
+
+
+     with protocols that represented reasonable "packagings" of
+     functionality.  For reasons that are probably unknowable, but
+     about which some conjectures will be offered subsequently, the
+     ARM and the ISORM agree strongly on the presence of Layering in
+     their respective axiomatizations but differ strikingly as to what
+     packagings of functionality are considered appropriate.  To
+     anticipate a bit, the ARM concerns itself with three layers and
+     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 have
+     studied it believe that all of the layers must be traversed on
+     each transmission/reception of data.
+
+          Perhaps the most significant point of all about Layering is
+     that the most frequently-voiced charge at NWG protocol committee
+     design meetings was, "That violates Layering!" even though nobody
+     had an appreciably-clearer view of what Layering meant than has
+     been presented here, yet the ARMS exists.  We can only guess what
+     goes on in the design meetings for protocols to become members of
+     the ISORM suite (ISORMS), but it doesn't seem likely that having
+     more layers could possibly decrease the number of arguments....
+
+          Indeed, it's probably fair to say that the ARM view of
+     Layering is to treat layers as quite broad functional groupings
+     (Network Interface, Host-Host, and Process-Level, or
+     Applications), the constituents of which are to be modular.
+     E.g., in the Host-Host layer of the current ARMS, the Internet
+     Protocol, IP, packages internet addressing--among other
+     things--for both the Transmission Control Protocol, TCP, which
+     packages reliable interprocess communication, and UDP--the less
+     well-known User Datagram Protocol--which packages only
+     demultiplexable interprocess communication ... and for any other
+     IPC packaging which should prove desirable.  The ISORM view, on
+     the other hand, fundamentally treats layers as rather narrow
+     functional groupings, attempting to force modularity by requiring
+     additional layers for additional functions (although the
+     "classes" view of the proposed ECMA-sponsored ISORM Transport
+     protocol tends to mimic the relations between TCP, UDP, and IP).
+
+          It is, by the way, forcing this view of modularity by
+     multiplying layers rather than by trusting the designers of a
+     given protocol to make it usable by other protocols within its
+     own layer that we suspect to be a major cause of the divergence
+     between the ISORM and the ARM, but, as indicated, the issue
+     almost certainly is not susceptible of proof.  (The less
+     structured view of modularity will be returned to in the next
+     major section.)  At any rate, the notion that "N-entities" must
+     communicate with one another by means of "N-1 entities" does seem
+     to us to take the ISORM out of its
+
+
+
+
+
+
+                                     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 than
+     that for a reference model to serve a prescriptive role levies
+     unrealizable requirements of precision, and of familiarity with
+     all styles of operating systems, on its expositors.  In other
+     words, as it is currently presented, the ISORM hierarchy of
+     protocols turns out to be a rather strict hierarchy, with
+     required, "chain of command" implications akin to the Elizabethan
+     World Picture's Great Chain of Being some readers might recall if
+     they've studied Shakespeare, whereas in the ARM a cat can even
+     invoke a king, much less look at one.
+
+     Common Intermediate Representations
+
+          The next axiom to be considered might well not be an axiom
+     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 first
+     Process-Level (roughly equivalent to ISORM Level 5.3 [5] through
+     7) ARMS protocol, it did seem self-evident that a "virtual
+     terminal" was a sound conceptual model--but it can also be
+     demonstrated that it is.  The argument, customarily shorthanded
+     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 Hosts
+     (and you do--resource sharing doesn't preclude remote access, it
+     subsumes it), you have a problem with Hosts' native terminal
+     control software or "access methods", which only "know about"
+     certain kinds/brands/types of terminals, but there are many more
+     terminals out there than any Host has internalized (even those
+     whose operating systems take a generic view of I/O and don't
+     allow applications programs to "expect" particular terminals).
+
+          You don't want to make N different types of Host/Operating
+     System have to become aware of M different types of terminal.
+     You don't want to limit access to users who are at one particular
+     type of terminal even if all your Hosts happen to have one in
+     common.  Therefore, you define a common intermediate
+     representation (CIR) of the properties of terminals--or create a
+     Network Virtual Terminal (NVT), where "virtual" is used by
+     analogy to "virtual memory" in the sense of something that isn't
+     necessarily really present physically but can be used as if it
+     were.  Each Host adds one terminal to its set of supported types,
+     the NVT--where adding means translating/mapping from the CIR to
+     something acceptable to the rest of the programs on your system
+     when receiving terminal-oriented traffic "from the net", and
+     translating/mapping to the CIR from whatever your acceptable
+     native representation was when sending terminal-oriented traffic
+     "to the net".  (And the system to  which the terminal is
+     physically attached does the same things.)
+
+
+
+
+
+
+
+                                     9
+     RFC 871                                            September 1982
+
+
+          "Virtualizing" worked so well for the protocol in question
+     ("Telnet", for TELetypewriter NETwork) that when it came time to
+     design a File Transfer Protocol (FTP), it was employed again--in
+     two ways, as it happens.  (It also worked so well that in some
+     circles, "Telnet" is used as a generic term for "Virtual Terminal
+     Protocol", just like "Kleenex" for "disposable handkerchief".)
+     The second way in which FTP (another generic-specific) used
+     Common Intermediate Representations is well-known: you can make
+     your FTP protocol interpreters (PI's) use certain "virtual" file
+     types in ARMS FTP's and in proposed ISORMS FTP's.  The first way
+     a CIR was used deserved more publicity, though:  We decided to
+     have a command-oriented FTP, in the sense of making it possible
+     for users to cause files to be deleted from remote directories,
+     for example, as well as simply getting a file added to a remote
+     directory.  (We also wanted to be able to designate some files to
+     be treated as input to the receiving Hosts' native "mail" system,
+     if it had one.)  Therefore, we needed an agreed-upon
+     representation of the commands--not only spelling the names, but
+     also defining the character set, indicating the ends of lines,
+     and so on.  In less time than it takes to write about, we
+     realized we already had such a CIR: "Telnet".
+
+          So we "used Telnet", or at any rate the NVT aspects of that
+     protocol, as the "Presentation" protocol for the control aspects
+     of FTP--but we didn't conclude from that that Telnet was a lower
+     layer than FTP.  Rather, we applied the principles of modularity
+     to make use of a mechanism for more than one purpose--and we
+     didn't presume to know enough about the internals of everybody
+     else's Host to dictate how the program(s) that conferred the FTP
+     functionality interfaced with the program(s) that conferred the
+     Telnet functionality.  That is, on some operating systems it
+     makes sense to let FTP get at the NVT CIR by means of closed
+     subroutine calls, on others through native IPC, and on still
+     others by open subroutine calls (in the sense of replicating the
+     code that does the NVT mapping within the FTP PI).  Such
+     decisions are best left to the system programmers of the several
+     Hosts.  Although the ISORM takes a similar view in principle, in
+     practice many ISORM advocates take the model prescriptively
+     rather than descriptively and construe it to require that PI's at
+     a given level must communicate with each other via an "N-1
+     entity" even within the same Host.  (Still other ISORMites
+     construe the model as dictating "monolithic" layers--i.e., single
+     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're
+     dealing with the amount of traffic that traverses a
+     terminal-oriented logical (or even virtual) connection, you don't
+     worry much about how many CPU cycles you're "wasting" on mapping
+     into and out of the NVT CIR; but
+
+
+
+
+
+                                    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 fairly
+     real sense the resources you're making sharable.  Therefore, when
+     it comes to (generic) FTP's, even though we've seen it in one or
+     two ISORM L6 proposals, having only a virtual file conceptual
+     model is not wise.  You'd rather let one side or the other map
+     directly between native representations where possible, to
+     eliminate the overhead for going into and out of the CIR--for
+     long enough files, anyway, and provided one side or the other is
+     both willing and able to do the mapping to the intended
+     recipient's native representation.
+
+     Efficiency
+
+          The last point leads nicely into an axiom that is rarely
+     acknowledged explicitly, but does belong in the ARM list of
+     axioms: Efficiency is a concern, in several ways.  In the first
+     place, protocol mechanisms are meant to follow the design
+     principle of Parsimony, or Least Mechanism; witness the argument
+     immediately above about making FTP's be able to avoid the double
+     mapping of a Virtual File approach when they can.  In the second
+     place, witness the argument further above about leaving
+     implementation decisions to implementers.  In the author's
+     opinion, the worst mistake in the ISORM isn't defining seven (or
+     more) layers, but decreeing that "N-entities" must communicate
+     via "N-1 entities" in a fashion which supports the interpretation
+     that it applies intra-Host as well as inter-Host.  If you picture
+     the ISORM as a highrise apartment building, you are constrained
+     to climb down the stairs and then back up to visit a neighbor
+     whose apartment is on your own floor.  This might be good
+     exercise, but CPU's don't need aerobics as far as we know.
+
+          Recalling that this paper is only secondarily about ARM
+     "vs." ISORM, let's duly note that in the ARM there is a concern
+     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 the
+     final axiom without digressing to one or two proposed specific
+     ISORM mechanisms which seem to be extremely inefficient.
+
+     Equity
+
+          The least known of the ARM axioms has to do with a concern
+     over whether particular protocol mechanisms would entail undue
+     perturbation of native mechanisms if implemented in particular
+     Hosts.  That is, however reluctantly, the ARMS designers were
+     willing to listen to claims that "you can't implement that in my
+     system" when particular tactics were proposed and, however
+
+
+
+
+
+
+
+                                    11
+     RFC 871                                            September 1982
+
+
+     grudgingly, retreat from a mechanism that seemed perfectly
+     natural on their home systems to one which didn't seriously
+     discommode a colleague's home system.  A tacit design principle
+     based on equity was employed.  The classic example had to do with
+     "electronic mail", where a desire to avoid charging for incoming
+     mail led some FTP designers to think that the optionally
+     mandatory "login" commands of the protocol shouldn't be mandatory
+     after all.  But the commands were needed by some operating
+     systems to actuate not only accounting mechanisms but
+     authentication mechanisms as well, and the process which
+     "fielded" FTP connections was too privileged (and too busy) to
+     contain the FTP PI as well.  So (to make a complex story
+     cryptic), a common name and password were advertised for a "free"
+     account for incoming mail, and the login commands remained
+     mandatory (in the sense that any Host could require their
+     issuance before it participated in FTP).
+
+          Rather than attempt to clarify the example, let's get to its
+     moral:  The point is that how well protocol mechanisms integrate
+     with particular operating systems can be extremely subtle, so in
+     order to be equitable to participating systems, you must either
+     have your designers be sophisticated implementers or subject your
+     designs to review by sophisticated implementers (and grant veto
+     power to them in some sense).
+
+          It is important to note that, in the author's view, the
+     ISORM not only does not reflect application of the Principle of
+     Equity, but it also fails to take any explicit cognizance of the
+     necessity of properly integrating its protocol interpreters into
+     continuing operating systems.  Probably motivated by Equity
+     considerations, ARMS protocols, on the other hand, represent the
+     result of intense implementation discussion and testing.
+
+                               Articulation
+
+          Given the foregoing discussion of its axioms, and a reminder
+     that we find it impossible in light of the existence of dozens of
+     definitions of so fundamental a notion as "process" to believe in
+     rigorous definitions, the ARPANET Reference Model is not going to
+     require much space to articulate.  Indeed, given further the
+     observation that we believe reference models are supposed to be
+     descriptive rather than prescriptive, the articulation of the ARM
+     can be almost terse.
+
+          In order to achieve efficient, equitable resource sharing
+     among dissimilar operating systems, a layered set of interprocess
+     communication oriented protocols is posited which typically
+     employ common intermediate representations over logical
+     connections.  Three
+
+
+
+
+
+
+                                    12
+     RFC 871                                            September 1982
+
+
+     layers are distinguished, each of which may contain a number of
+     protocols.
+
+          The Network Interface layer contains those protocols which
+     are presented as interfaces by communications subnetwork
+     processors ("CSNP"; e.g., packet switches, bus interface units,
+     etc.)  The CSNP's are assumed to have their own protocol or
+     protocols among themselves, which are not directly germane to the
+     model.  In particular, no assumption is made that CSNP's of
+     different types can be directly interfaced to one another; that
+     is, "internetting" will be accomplished by Gateways, which are
+     special purpose systems that attach to CSNP's as if they were
+     Hosts (see also "Gateways" below). The most significant property
+     of the Network Interface layer is that bits presented to it by an
+     attached Host will probably be transported by the underlying
+     CSNP's to an addressed Host (or Hosts) (i.e., "reliable" comm
+     subnets are not posited--although they are, of course, allowed).
+     A Network layer protocol interpreter ("module") is normally
+     invoked by a Host-Host protocol PI, but may be invoked by a
+     Process Level/Applications protocol PI, or even by a Host process
+     interpreting no formal protocol whatsoever.
+
+          The Host-Host layer contains those protocols which confer
+     interprocess communication functionality.  In the current
+     "internet" version of the ARM, the most significant property of
+     such protocols is the ability to direct such IPC to processes on
+     Hosts attached to "proximate networks" (i.e., to CSNP's of
+     various autonomous communications subnetworks) other than that of
+     the Host at hand, in addition to those on a given proximate net.
+     (You can, by the way, get into some marvelous technicoaesthetic
+     arguments over whether there should be a separate Internet layer;
+     for present purposes, we assume that the Principle of Parsimony
+     dominates.)  Another significant property of Host-Host protocols,
+     although not a required one, is the ability to do such IPC over
+     logical connections. Reliability, flow control, and the ability
+     to deal with "out-of-band signals" are other properties of
+     Host-Host protocols which may be present.  (See also "TCP/IP
+     Design Goals and Constraints", below.) A Host-Host PI is normally
+     invoked by a Process Level/Applications PI, but may also be
+     invoked by a Host process interpreting no formal protocol
+     whatsoever.  Also, a Host need not support more than a single,
+     possibly notional, process (that is, the code running in an
+     "intelligent terminal" might not be viewed by its user--or even
+     its creator--as a formal "process", but it stands as a de facto
+     one).
+
+          The Process Level/Applications layer contains those
+     protocols which perform specific resource sharing and remote
+     access functions such as allowing users to log in/on to foreign
+     Hosts, transferring files, exchanging messages, and the like.
+     Protocols in this layer
+
+
+
+
+                                    13
+     RFC 871                                            September 1982
+
+
+     will often employ common intermediate representations, or
+     "virtual- izations", to perform their functions, but this is not
+     a necessary condition.  They are also at liberty to use the
+     functions performed by other protocols within the same layer,
+     invoked in whatever fashion is appropriate within a given
+     operating system context.
+
+          Orthogonal to the layering, but consistent with it, is the
+     notion that a "Host-Front End" protocol (H-FP), or "Host-Outboard
+     Processing Environment" protocol, may be employed to offload
+     Network and Host-Host layer PI's from Hosts, to Outboard
+     Processing Environments (e.g., to "Network Front Ends", or to
+     BIU's, where the actual PI's reside, to be invoked by the H-FP as
+     a distributed processing mechanism), as well as portions of
+     Process Level/Applications protocols' functionality.  The most
+     significant property of an H-FP attached Host is that it be
+     functionally identical to a Host with inboard PI's in operation,
+     when viewed from another Host. (That is, Hosts which outboard
+     PI's will be attached to in a flexible fashion via an explicit
+     protocol, rather than in a rigid fashion via the emulation of
+     devices already known to the operating system in question.)
+
+          Whether inboard or outboard of the Host, it is explicitly
+     assumed that PI's will be appropriately integrated into the
+     containing operating systems.  The Network and Host-Host layers
+     are, that is, effectively system programs (although this
+     observation should not be construed as implying that any of their
+     PI's must of necessity be implemented in a particular operating
+     system's "hard-core supervisor" or equivalent) and their PI's
+     must be able to behave as such.
+
+                               Visualization
+
+          Figures 1 and 2 (adapted from [6]) present, respectively, an
+     abstract rendition of the ARPANET Reference Model and a
+     particular version of a protocol suite designed to that model.
+     Just as one learns in Geometry that one cannot "prove" anything
+     from the figures in the text, they are intended only to
+     supplement the prose description above.  (At least they bear no
+     resemblance to highrise apartment houses.)
+
+                    TCP/IP Design Goals and Constraints
+
+          The foregoing description of the ARM, in the interests of
+     conciseness, deferred detailed discussion of two rather relevant
+     topics:  just what TCP and IP (the Transmission Control Protocol
+     and the Internet Protocol) are "about", and just what role
+     Gateways are
+
+
+
+
+
+
+
+                                    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] as
+     both a proof-of-concept of intercomputer resource sharing via a
+     packet-switched communications subnetwork and a (still)
+     functional resource sharing network, a number of other bodies,
+     research and commercial, developed "their own networks."  Often
+     just the communications subnetwork was intended, with the goal
+     being to achieve remote access to attached Hosts rather than
+     resource sharing among them, but nonetheless new networks
+     abounded.  Hosts attached to the original ARPANET or to DoD nets
+     meant to be transferences of ARPANET technology should, it was
+     perceived in the research community, be able to do resource
+     sharing (i.e., interpret common high level protocols) with Hosts
+     attached to these other networks. Thus, the first discernible
+     goal of what was to become TCP/IP was to develop a protocol to
+     achieve "internetting".
+
+          At roughly the same time--actually probably chronologically
+     prior, but not logically prior--the research community came to
+     understand that the original ARPANET Host-Host Protocol or AH-HP
+     (often miscalled NCP because it was the most visible component of
+     the Network Control Program of the early literature) was somewhat
+     flawed, particularly in the area of "robustness."  The comm
+     subnet was not only relied upon to deliver messages accurately
+     and in order, but it was even expected to manage the transfer of
+     bits from Hosts to and from its nodal processors over a hardware
+     interface and "link protocol" that did no error checking.  So,
+     although the ARPANET-as-subnet has proven to be quite good in
+     managing those sorts of things, surely if internetting were to be
+     achieved over subnets potentially much less robust than the
+     ARPANET subnet, the second discernible goal must be the
+     reliability of the Host-to-Host protocol.  That is, irrespective
+     of the properties of the communications subnetworks involved in
+     internetting, TCP is to furnish its users--whether they be
+     processes interpreting formal protocols or simply processes
+     communicating in an ad hoc fashion--with the ability to
+     communicate as if their respective containing Hosts were attached
+     to the best comm subnet possible (e.g., a hardwired connection).
+
+          The mechanizations considered to achieve reliability and
+     even those for internetting were alien enough to AH-HP's style,
+     though, and the efficiency of several of AH-HP's native
+     mechanisms (particularly Flow Control and the notion of a Control
+     Link) had been questioned often enough, that a good Host-Host
+     protocol could not be a simple extension of AH-HP.  Thus, along
+     with the desire for reliability came a necessity to furnish a
+     good Host-Host protocol, a
+
+
+
+
+
+
+                                    15
+     RFC 871                                            September 1982
+
+
+     design goal easy to overlook.  This is a rather subtle issue in
+     that it brings into play a wealth of prior art.  For present
+     purposes, in practical terms it means that the "good" ideas
+     (according to the technical intuition of the designers) of
+     AH-HP--such as sockets, logical connections, Well-Known Sockets,
+     and in general the interprocess communication premise--are
+     retained in TCP without much discussion, while the "bad" ideas
+     are equally tacitly jettisoned in favor of ones deemed either
+     more appropriate in their own right or more consistent with the
+     other two goals.
+
+          It could be argued that other goals are discernible, but the
+     three cited--which may be restated and compressed as a desire to
+     offer a good Host-Host protocol to achieve reliable
+     internetting--are challenging enough, when thought about hard for
+     a few years, to justify a document of even more than this one's
+     length.  What of the implied and/or accepted design constraints,
+     though?
+
+          The first discernible design constraint borders on the
+     obvious: Just as the original ARPANET popularized
+     packet-switching (and, unfortunately to a lesser extent, resource
+     sharing), its literature popularized the notion of "Layering."
+     Mechanistically, layering is easy to describe:  the control
+     information of a given protocol must be treated strictly as data
+     by the next "lower" protocol (with processes "at the top," and
+     the/a transmission medium "at the bottom"), as discussed earlier.
+     Philosophically, the notion is sufficiently subtle that even
+     today researchers of good will still argue over what "proper"
+     layering implies, also as discussed earlier.  For present
+     purposes, however, it suffices to observe the following:
+     Layering is a useful concept.  The precise set of functions
+     offered by a given layer is open to debate, as is the precise
+     number of layers necessary for a complete protocol suite to
+     achieve resource sharing.  (Most researchers from the ARPANET
+     "world" tend to think of only three layers--the process,
+     applications, or user level; the Host-Host level; and the network
+     level--though if pressed they acknowledge that "the IMPs must
+     have a protocol too."  Adherents of the International Standards
+     Organization's "Open System Interconnection" program--which
+     appears to be how they spell resource sharing--claim that seven
+     is the right number of levels--though if pressed they acknowledge
+     that "one or two of them have sublevels."  And adherents of the
+     Consultative Committee for International Telephony and Telegraphy
+     don't seem particularly concerned with resource sharing to begin
+     with.)  At any rate, TCP and IP are constrained to operate in a
+     (or possibly in more than one) layered protocol hierarchy.
+     Indeed, although it is not the sole reason, this fact is the
+     primary rationale for separating the internetting mechanization
+     into a discrete protocol (the Internet Protocol: IP).  In other
+     words, although designed
+
+
+
+
+                                    16
+     RFC 871                                            September 1982
+
+
+     "for" the ARM, TCP and IP are actually so layered as to be useful
+     even outside the ARM.
+
+          It should be noted that as a direct consequence of the
+     Layering constraint, TCP must be capable of operating "above" a
+     functionally- equivalent protocol other than IP (e.g., an
+     interface protocol directly into a proximate comm subnet, if
+     internetting is not being done), and IP must be capable of
+     supporting user protocols other than TCP (e.g., a non-reliable
+     "Real-Time" protocol).
+
+          Resisting the temptation to attempt to do justice to the
+     complexities of Layering, we move on to a second design
+     constraint, which also borders on the obvious:  Only minimal
+     assumptions can be made about the properties of the various
+     communications subnetworks in play.  (The "network" composed of
+     the concatenation of such subnets is sometimes called "a
+     catenet," though more often--and less picturesquely--merely "an
+     internet.")  After all, the main goal is to let processes on
+     Hosts attached to, essentially, "any old (or new) net"
+     communicate, and to limit that communication to processes on
+     Hosts attached to comm subnets that, say, do positive
+     acknowledgments of message delivery would be remiss. [8]
+
+          Given this constraint, by the way, it is quite natural to
+     see the more clearly Host-to-Host functions vested in TCP and the
+     more clearly Host-to-catenet functions vested in IP.  It is,
+     however, a misconception to believe that IP was designed in the
+     expectation that comm subnets "should" present only the "lowest
+     common denominator" of functionality; rather, IP furnishes TCP
+     with what amounts to an abstraction (some would say a
+     virtualization--in the ARPANET Telnet Protocol sense of
+     virtualizing as meaning mapping from/to a common intermediate
+     representation to/from a given native representation) of the
+     properties of "any" comm subnet including, it should be noted,
+     even one which presents an X.25 interface.  That is, IP allows
+     for the application to a given transmission of whatever generic
+     properties its proximate subnet offers equivalents for; its
+     design neither depends upon nor ignores the presence of any
+     property other than the ability to try to get some packet of bits
+     to some destination, which surely is an irreducible minimum for
+     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
+     RFC 871                                            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
+     RFC 871                                            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
+     RFC 871                                            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
+     RFC 871                                            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
+     RFC 871                                            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
+     RFC 871                                            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
+     RFC 871                                            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
+     RFC 871                                            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.
+
+     
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                    25
\ No newline at end of file