rfc871.txt

RFC 的详细文档！

     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