rfc871.txt

RFC 的详细文档！

     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 Sh