rfc872.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 549 行 · 第 1/2 页

     RFC 872                                            September 1982
                                                                M82-48







                               TCP-ON-A-LAN




     
     

     













                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts
     




                                 Abstract
     

     

          The sometimes-held position that the DoD Standard
     Transmission Control Protocol (TCP) and Internet Protocol (IP)
     are inappropriate for use "on" a Local Area Network (LAN) is
     shown to be fallacious.  The paper is a companion piece to
     M82-47, M82-49, M82-50, and M82-51.









































                                     i
     
     
     
     
                              "TCP-ON-A-LAN"

                              M. A. Padlipsky

     Thesis

          It is the thesis of this paper that fearing "TCP-on-a-LAN"
     is a Woozle which needs slaying.  To slay the "TCP-on-a-LAN"
     Woozle, we need to know three things:  What's a Woozle?  What's a
     LAN?  What's a TCP?

     Woozles

          The first is rather straightforward [1]:

               One fine winter's day when Piglet was brushing away the
          snow in front of his house, he happened to look up, and
          there was Winnie-the-Pooh.  Pooh was walking round and round
          in a circle, thinking of something else, and when Piglet
          called to him, he just went on walking.
               "Hallo!" said Piglet, "what are you doing?"
               "Hunting," said Pooh.
               "Hunting what?"
               "Tracking something," said Winnie-the-Pooh very
          mysteriously.
               "Tracking what?" said Piglet, coming closer.
               "That's just what I ask myself.  I ask myself, What?"
               "What do you think you'll answer?"
               "I shall have to wait until I catch up with it," said
          Winnie-the-Pooh.  "Now look there."  He pointed to the
          ground in front of him.  "What do you see there?
               "Tracks," said Piglet, "Paw-marks."  he gave a little
          squeak of excitement.  "Oh, Pooh!  Do you think it's a--a--a
          Woozle?"

          Well, they convince each other that it is a Woozle, keep
     "tracking," convince each other that it's a herd of Hostile
     Animals, and get duly terrified before Christopher Robin comes
     along and points out that they were following their own tracks
     all the long.

          In other words, it is our contention that expressed fears
     about the consequences of using a particular protocol named "TCP"
     in a particular environment called a Local Area Net stem from
     misunderstandings of the protocol and the environment, not from
     the technical facts of the situation.






                                     1
     RFC 872                                            September 1982


     LAN's

          The second thing we need to know is somewhat less
     straightforward:  A LAN is, properly speaking [2], a
     communications mechanism (or subnetwork) employing a transmission
     technology suitable for relatively short distances (typically a
     few kilometers) at relatively high bit-per-second rates
     (typically greater than a few hundred kilobits per second) with
     relatively low error rates, which exists primarily to enable
     suitably attached computer systems (or "Hosts") to exchange bits,
     and secondarily, though not necessarily, to allow terminals of
     the teletypewriter and CRT classes to exchange bits with Hosts.
     The Hosts are, at least in principle, heterogeneous; that is,
     they are not merely multiple instances of the same operating
     system.  The Hosts are assumed to communicate by means of layered
     protocols in order to achieve what the ARPANET tradition calls
     "resource sharing" and what the newer ISO tradition calls "Open
     System Interconnection."  Addressing typically can be either
     Host-Host (point-to-point) or "broadcast." (In some environments,
     e.g., Ethernet, interesting advantage can be taken of broadcast
     addressing; in other environments, e.g., LAN's which are
     constituents of ARPA- or ISO-style "internets", broadcast
     addressing is deemed too expensive to implement throughout the
     internet as a whole and so may be ignored in the constituent LAN
     even if available as part of the Host-LAN interface.)

          Note that no assumptions are made about the particular
     transmission medium or the particular topology in play.  LAN
     media can be twisted-pair wires, CATV or other coaxial-type
     cables, optical fibers, or whatever.  However, if the medium is a
     processor-to-processor bus it is likely that the system in
     question is going to turn out to "be" a moderately closely
     coupled distributed processor or a somewhat loosely coupled
     multiprocessor rather than a LAN, because the processors are
     unlikely to be using either ARPANET or ISO-style layered
     protocols.  (They'll usually -- either be homogeneous processors
     interpreting only the protocol necessary to use the transmission
     medium, or heterogeneous with one emulating the expectations of
     the other.)  Systems like "PDSC" or "NMIC" (the evolutionarily
     related, bus-oriented, multiple PDP-11 systems in use at the
     Pacific Data Services Center and the National Military
     Intelligence Center, respectively), then, aren't LANs.

          LAN topologies can be either "bus," "ring," or "star".  That
     is, a digital PBX can be a LAN, in the sense of furnishing a
     transmission medium/communications subnetwork for Hosts to do
     resource sharing/Open System Interconnection over, though it
     might not present attractive speed or failure mode properties.
     (It might, though.)  Topologically, it would probably be a
     neutron star.



                                     2
     RFC 872                                            September 1982


          For our purposes, the significant properties of a LAN are
     the high bit transmission capacity and the good error properties.
     Intuitively, a medium with these properties in some sense
     "shouldn't require a heavy-duty protocol designed for long-haul
     nets," according to some.  (We will not address the issue of
     "wasted bandwidth" due to header sizes. [2], pp. 1509f, provides
     ample refutation of that traditional communications notion.)
     However, it must be borne in mind that for our purposes the
     assumption of resource-sharing/OSI type protocols between/among
     the attached Hosts is also extremely significant.  That is, if
     all you're doing is letting some terminals access some different
     Hosts, but the Hosts don't really have any intercomputer
     networking protocols between them, what you have should be viewed
     as a Localized Communications Network (LCN), not a LAN in the
     sense we're talking about here.

     TCP

          The third thing we have to know can be either
     straightforward or subtle, depending largely on how aware we are
     of the context estabished by ARPANET-style prococols:  For the
     visual-minded, Figure 1 and Figure 2 might be all that need be
     "said."  Their moral is meant to be that in ARPANET-style
     layering, layers aren't monoliths.  For those who need more
     explanation, here goes:  TCP [3] (we'll take IP later) is a
     Host-Host protocol (roughly equivalent to the functionality
     implied by some of ISO Level 5 and all of ISO Level 4).  Its most
     significant property is that it presents reliable logical
     connections to protocols above itself.  (This point will be
     returned to subsequently.)  Its next most significant property is
     that it is designed to operate in a "catenet" (also known as the,
     or an, "internet"); that is, its addressing discipline is such
     that Hosts attached to communications subnets other than the one
     a given Host is attached to (the "proximate net") can be
     communicated with as well as Hosts on the proximate net.  Other
     significant properties are those common to the breed:  Host-Host
     protocols (and Transport protocols) "all" offer mechanisms for
     flow Control, Out-of-Band Signals, Logical Connection management,
     and the like.

          Because TCP has a catenet-oriented addressing mechanism
     (that is, it expresses foreign Host addresses as the
     "two-dimensional" entity Foreign Net/Foreign Host because it
     cannot assume that the Foreign Host is attached to the proximate
     net), to be a full Host-Host protocol it needs an adjunct to deal
     with the proximate net.  This adjunct, the Internet Protocol (IP)
     was designed as a separate protocol from TCP, however, in order
     to allow it to play the same role it plays for TCP for other
     Host-Host protocols too.




                                     3
     RFC 872                                            September 1982


          In order to "deal with the proximate net", IP possess the
     following significant properties:  An IP implementation maps from
     a virtualization (or common intermediate representation) of
     generic proximate net qualities (such as precedence, grade of
     service, security labeling) to the closest equivalent on the
     proximate net. It determines whether the "Internet Address" of a
     given transmission is on the proximate net or not; if so, it
     sends it; if not, it sends it to a "Gateway" (where another IP