rfc875.txt

RFC 相关的技术文档

     RFC 875                                            September 1982
                                                                M82-51







                  Gateways, Architectures, and Heffalumps




     
     

     













                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts
     




                                 ABSTRACT
     

     

          The growth of autonomous intercomputer networks has led to a
     desire on the part of their respective proprietors to "gateway"
     from one to the other.  Unfortunately, however, the implications
     and shortcomings of gateways which must translate or map between
     differing protocol suites are not widely understood.  Some
     protocol sets have such severe functionality mismatches that
     proper T/MG's cannot be generated for them; all attempts to mesh
     heterogeneous suites are subject to numerous problems, including
     the introduction of "singularity points" on logical connections
     which would otherwise be able to enjoy the advantages of
     communications subnetwork alternate routing, loss of
     functionality, difficulty of Flow Control resolution, higher cost
     than non-translating/mapping Gateways, and the necessity of
     re-creating T/MG's when a given suite changes.  The preferability
     of a protocol-compatible internet is also touched upon, as is the
     psychology of those soi-disant architects who posit T/MG's.
































                                     i
          
     
     
     
                  Gateways, Architectures, and Heffalumps

                              M. A. Padlipsky
     
     
     

          In our collective zeal to remain (or become) abreast of the
     State of the Art, we sometimes fall into one or the other (or
     both) of a couple of pitfalls.  Only one of these pitfalls is
     particularly well-known:  "Buzzwords" -- and even here merely
     knowing the name doesn't necessarily effect a spontaneous
     solution.  The other deserves more attention:  inadequate
     familiarity with The Relevant Literature.

          The key is the notion of what's really relevant.  Often,
     it's the Oral Tradition that matters; published papers, in their
     attempts to seem scholarly, offer the wrong levels of abstraction
     or, because of the backgrounds of their authors, are so
     ill-written as to fail to communicate well.  Sometimes, however,
     that which is truly relevant turns out to be unfindable by a
     conventional literature searcher because it isn't "in" the field
     of search.

          I wandered into an instructive case in point recently, when
     it took me over an hour to convince a neophyte to the mysteries
     of intercomputer networking (who is quite highly regarded in at
     least one other area of computer science, and is by no means a
     dummy) that a particular Local Area Network architecture proposal
     which casually appealed to the notion of "gatewaying" to three or
     four other networks it didn't have protocols in common with was a
     Very Bad Thing.  "Gateways" is, of course, another one of those
     bloody buzzwords, and in some contexts it might have been enough
     just to so label it.  But this was a conversation with a bright
     professional who'd recently been reading up on networks and who
     wanted really to understand what was so terrible.

          So I started by appealing to the Oral Tradition, pointing
     out that in the ARPA internetworking research community (from
     which we probably got the term "Gateway" in the first place --
     and from which we certainly get the proof of concept for
     internets) it had been explicitly decided that it would be too
     hard to deal with connecting autonomous networks whose protocol
     sets differed "above" the level of
     Host-to-Communications-Subnetwork-Processor protocol.  That is,
     the kind of Gateway we know how to build -- and, indeed, anything
     one might call a Gateway -- attaches to two (or more) comm
     subnets as if it were a Host on each, by appropriately
     interpreting their respective H-CSNP protocols and doing the
     right things in hardware (see Figure 1), but for ARPA Internet
     Gateways each net attached to is assumed to have the same
     Host-Host Protocol (TCP/IP, in fact


                                     1
     RFC 875                                            September 1982


     or, anyway, IP and either TCP or some other common-to-both-nets
     protocol above it), and the same process level protocols (e.g.,
     Telnet, FTP, or whatever).  The reason for this assuming of
     protocol set homogeneity is that they "knew" the alternative was
     undesirable, because it would involve the translation or mapping
     between different protocol sets in the Gateways and such T/MG's
     were obviously to be avoided.

          Well, that didn't do the trick.  "Why is a T/MG a Bad
     Thing?" he wanted to know.  "Because of the possibility of
     irreconcilable mismatches in functionality."  "For instance?"
     "Addressing is the most commonly cited."  "Addressing?"

          Assuming the reader is as bored as I am with the dialogue
     bit, I'll try to step through some specifics of the sorts of
     incompatibility one can find between protocol sets in a less
     theatric manner.  Note that the premise of it all is that we
     don't want to change either pre-existing protocol set.  Let's
     assume for convenience that we are trying to attach just two nets
     together with a T/MG, and further assume that one of the nets
     uses the original ARPANET "NCP" -- which consists, strictly
     speaking, of the unnamed original ARPANET Host-Host Protocol and
     the unfortunately named "1822", or ARPANET Host-IMP Protocol --
     and the other uses TCP/IP.

          Host addressing is the most significant problem.  NCP-using
     hosts have "one-dimensional" addresses.  That is, there's a field
     in the Host-IMP "leader" where the Host number goes.  When you've
     assigned all the available values in that field, your net is full
     until and unless you go back and change all the IMP's and NCP's
     to deal with a bigger field.  Using IP, on the other hand,
     addresses of Hosts are "two-dimensional".  That is, there's an IP
     header field in which to designate the foreign network and
     another field in which to designate the foreign Host.  (The
     foregoing is a deliberate oversimplification, by the way.)  So if
     you wanted a Host on an NCP-based net to communicate with a Host
     on another, TCP-based net you'd have a terrible time of it if you
     also didn't want to go mucking around inside of all the different
     NCP implementations, because you don't have a way of expressing
     the foreign address within your current complement of addressing
     mechanisms.

          There are various tricks available, of course.  You could
     find enough spare bits in the Host-IMP leader or Host-Host header
     perhaps, and put the needed internet address there.  Or you could
     change the Initial Connection Protocol, or even make the internet
     address be the first thing transmitted as "data" by the User side
     of each process-level protocol.  The common failing of all such
     ploys is that you're changing the pre-existing protocols, though,
     and if





                                     2
     RFC 875                                            September 1982


     that sort of thing were viewed with equanimity by system
     proprietors you might as well go the whole hog and change over to
     the new protocol set across the board.  Granted, that's a big
     jump; but it must be realized that this is just the first of
     several problems.

          (It is the case that you could get around the addressing
     problem by having the T/MG become more nearly a real Host and
     terminate the NCP-based side in an application program which
     would "ask" the user what foreign Host he wants to talk to on the
     TCP-based side -- at least for Telnet connections.  When there's
     no user around, though, as would be the case in most file
     transfers, you lose again, unless you fiddle your FTP.  In
     general, this sort of "Janus Host" -- after the Roman deity with
     two faces, who was according to some sources the god of gateways
     (!) -- confers extremely limited functionality anyway; but in
     some practical cases it can be better than trying for full
     functionality and coming up empty.)

          Then there's the question of what to do about RFNM's.  That
     is, NCP's follow the discipline of waiting until the foreign IMP
     indicates a Ready for Next Message state exists before sending
     more data on a given logical connection, but if you're talking to
     a T/MG, its IMP is the one you'll get the RFNM from (the real
     foreign Host might not even be attached to an IMP).  Now, I've
     actually seen a proposal that suggested solving this problem by
     altering the T/MG's IMP to withhold RFNM's, but that doesn't make
     me think it's a viable solution.  At the very least, the T/MG is
     going to have to go in for buffering in a big way (see Figure 2).
     In a possible worst case, the foreign net might not even let you
     know your last transmission got through without changing its
     protocols.

          Going beyond the NCP-TCP example, a generic topic fraught
     with the peril of functionality mismatch is that of the
     Out-of-Band Signal.  (There are some who claim it's also an
     NCP-TCP problem.) The point is that although "any good Host-Host
     protocol" should have some means of communicating aside from
     normal messages "on" logical connections, the mechanizations and
     indeed the semantics of such Out-of-Band Signals often differ.
     The fear is that the differences may lead to  incompatibilities.
     For example, in NCP the OOBS is an Interrupt command "on" the
     control link, whereas in TCP it's an Urgent bit in the header of
     a message "on" the socket.  If you want Urgent to be usable in
     order to have a "virtual quit button", the semantics of the
     protocol must make it very clear that Urgent is not merely the
     sort of thing the NBS/ECMA Host-Host protocol calls "Expedited
     Data".  If, that is, the intent of the mechanism is to cause the
     associated process/job/task to take special action rather than
     merely the associated protocol interpreter (which need not be





                                     3
     RFC 875                                            September 1982


     part of the process), you'd better say so -- and none of the
     ISO-derived protocols I've seen yet does so.  And there's not
     much a T/MG  can do if it gets an NCP Interrupt on a control
     link, notices a Telnet Interrupt Process control code on the
     associated socket, and doesn't have anything other than
     Expediting Data to do with it on its other side.  (Expedited
     Data, it may be noted, bears a striking resemblance to taking an
     SST across the Atlantic, only to find no one on duty in the
     Customs shed -- and the door locked from the other side.)