rfc874.txt

RFC 相关的技术文档

---------


     < INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;;
     




     RFC 874                                            September 1982
                                                                M82-50







                            A CRITIQUE OF X.25




     
     

     













                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts
     




                                 ABSTRACT
     

     

          The widely touted network interface protocol, "X.25", and
     its attendant conceptual framework, the International Standards
     Organization's Reference Model for Open System Interconnection
     (ISORM), are analyzed and found wanting.  The paper is a
     companion piece to M82-48, and M82-51.











































                                     i
          
     
     
     
                            A CRITIQUE OF X.25

                              M. A. Padlipsky
     
     
     

     Introduction

          According to some sources, the International Standards
     Organization's (ISO) "Open System Interconnection" (OSI) effort
     has adopted the International Consultative Committee on Telephony
     and Telegraphy (CCITT) developed X.25 protocol(s) as its Levels
     1-3. ("Loose constructionists" of the ISORM would hold that X.25
     is a mechanization of L1-L3 rather than the mechanization, and at
     least one British source holds that "we in the U.K. don't believe
     that ISO have adopted X.25.")  In the U.S. Government arena,
     where the author spends much of his time, the Government
     Accounting Office (GAO) has suggested that the Department of
     Defense (DoD) ought to consider adopting "X.25 networks,"
     apparently in preference to networks based on protocols developed
     by the DoD-sponsored intercomputer networking research community.
     That intercomputer networking research community in turn has,
     with a few recent exceptions, adhered to its commitment to the
     Oral Tradition and not taken up the cudgels against X.25 in the
     open literature, even though X.25 is an object of considerable
     scorn in personal communications.

          Although the DoD Protocol Standards Technical Panel has
     begun to evolve a "Reference Model" different from ISO's for
     reasons which will be touched on below, there seems to be a need
     to address the deficiencies of X.25 on their own demerits as soon
     as possible. Without pretending to completeness*, this paper will
     attempt to do just that.

          The overall intent is to deal with X.25 in the abstract;
     because of who pays the bills, though, a necessary preliminary is
     to at least sketch the broad reasons why the DoD in particular
     should not

     ________________
     *  Various versions of X.25 and ISO documentation were employed;
        one incompleteness of note, however, is that no attempt has
        been made to do proper bibliographic citation.  Another
        incompleteness lies in the area of "tutoriality"; that is,
        appropriate prior knowledge is assumed on the part of the
        reader.  (The author apologizes for the omissions but hasn't
        the time or the energy to be overly scholarly.  Reference [3]
        might be of use to the reader who feels slighted.)





                                     1
     RFC 874                                            September 1982


     employ intercomputer networks which base their protocol suites on
     the ISO Reference Model (ISORM) with X.25 as Levels 1-3.  (Note
     that this is a different formulation from "use communications
     subnetworks which present an X.25 interface.")  Very briefly, the
     DoD has concerns with "survivability," reliability, security,
     investment in prior art (i.e., its research community has a
     working protocol suite in place on many different operating
     systems), procurability (i.e., ISORM-related protocol suites do
     not as yet fully exist even on paper and the international
     standardization process is acknowledged even by its advocates to
     require several years to arrive at full suite specification, much
     less offer available interoperable implementation), and
     interoperability with a much wider range of systems than are ever
     likely to receive vendor-supplied implementations of ISORM
     protocol suites.  Regardless of which particular concerns are
     considered to dominate, the DoD cannot be expected to await
     events in the ISO arena.  (Particularly striking is the fact that
     DoD representatives are not even permitted under current doctrine
     to present their specific concerns in the area of security in the
     sort of unclassified environment the ISO arena constitutes.)

          Some zealous ISORM advocates have suggested that the DoD
     research community suffers from a "Not Invented Here" syndrome
     with respect to ISORM-related protocols, though, so even if the
     various reasons just cited were to prevail, there would still be
     an open issue at some level.  At least one or two zealous members
     of the research community have asserted that the problem is not
     Not Invented Here, but Not Invented Right, so an assessment of
     the apparent keystone of the ISORM suite, X.25, from the
     perspective of whether it's "good art" ought to be appropriate.
     That's what we're up to here.
























                                     2
     RFC 874                                            September 1982


     Problems With the Conceptual Model*

          There is confusion even amongst its advocates as to the real
     conceptual model of X.25-based ISO networking.  Some draw their
     Reference  Model as two "highrises," others draw "parking
     garages" beside each highrise.  That is, some draw the seven
     ISORM layers in large rectangles (representing Hosts) next to one
     another, showing each layer in communication with its "peer" in
     the other Host/Open System; this implies an "end-to-end" view of
     X.25.  Others draw smaller rectangles between the larger ones,
     with Levels 1-3 having peer relationships from the Host-OS ("Data
     Terminal Equipment") to the Comm Subnet Node ("Data Circuit
     Terminating Equipment"); this implies a "link-by-link" view of
     X.25.  This ambiguity does not engender confidence in the
     architects, but perhaps the real problem is with the spectators.
     Yet it is indisputable that when internetting with X.75, the
     model becomes "hop-by-hop" (and it is likely it's meant to be
     link-by-link even on a single comm subnet).

          A major problem with such a model is that the designers have
     chosen to construe it as requiring them to break the "virtual
     circuit" it is supposed to be supporting whenever there is
     difficulty with any one of the links.  Thus, if internetting, and
     on some interpretations even on one's proximate net, rerouting of
     messages will not occur when needed, and all the upper levels of
     protocols will have to expend space-time resources on
     reconstituting their own connections with their counterparts.
     (Note that the success of the reconstitution under DCE failure
     appears to assume a certain flexibility in routing which is not
     guaranteed by the Model.)  This can scarcely be deemed sound
     design practice for an intercomputer networking environment,
     although many have conjectured that it probably makes sense to
     telephonists.

     ________________
     *  Note that we are assuming an ISO-oriented model rather than a
        CCITT-oriented one (X.25/X.28/X.29) because the latter appears
        to offer only "remote access" functionality whereas the sort
        of intercomputer networking we are interested in is concerned
        with the full "resource-sharing" functionality the former is
        striving for.  This might be somewhat unfair to X.25, in that
        it is taking the protocol(s) somewhat out of context; however,
        it is what ISO has done before us, and if what we're really
        accomplishing is a demonstration that ISO has erred in so
        doing, so be it.  As a matter of fact, it can also be argued
        that X.25 is itself somewhat unfair--to its users, who are
        expecting real networking and getting only communication; cf.
        Padlipsky, M. A., "The Elements of Networking Style", M81-41,
        The MITRE Corporation, October 1981, for more on the extremely
        important topic of resource sharing vs. remote access.





                                     3
     RFC 874                                            September 1982


          Indeed, it appears the virtual circuit metaphor is in some
     sense being taken almost literally (with the emphasis on the
     "circuit" aspect), in that what should be an environment that
     confers the benefits of packet-switching is, at the X.25 level,
     reduced to one with the limitations of circuit-switching.  On the