Gateways, architectures, and heffalumps
RFC 875

Document Type RFC - Unknown (September 1982; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 875 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
RFC 875                                            September 1982

                  Gateways, Architectures, and Heffalumps



                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts




          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.


                  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


     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.
Show full document text