rfc873.txt

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

---------


     < INC-PROJECT, MAP-ILLUSION.NLS.8, >, 12-Aug-83 11:44 AMW ;;;;
     




     RFC 873                                            September 1982
                                                                M82-49







                      THE ILLUSION OF VENDOR SUPPORT




     
     

     













                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts
     




                                 ABSTRACT
     

     

          The sometimes-held position that "vendor supplied"
     intercomputer networking protocols based upon the International
     Standards Organization's Reference Model for Open System
     Interconnection are worth waiting for, in particular in
     preference to protocols based upon the ARPANET Reference Model
     (ARM), is shown to be fallacious.

          The paper is a companion piece to M82-47, M82-48, M82-50,
     and M82-51.







































                                     i
          
     
     
     
                      THE ILLUSION OF VENDOR SUPPORT

                              M. A. Padlipsky
     
     
     

     Introduction

          Even one or two members of the DoD Protocol Standards
     Technical Panel join with many others (including, apparently,
     some members of the DoD Protocol Standards Steering Group, and
     clearly, somebody at the GAO) in expressing a desire to "go with
     vendor-supported intercomputer networking protocols instead of
     using our own."  The author's view of the implications of this
     desire should be clear from the title of this paper.  What
     evidence, then, is there to so stigmatize what is clearly a
     well-meant desire to save the Government money?

     Scope

          First, we must consider what is meant by "vendor-supported
     protocols."  It can't be just X.25, because that only gets you
     through the network layer whether you're appealing to the
     International Standards Organization's widely-publicized
     Reference Model for Open System Interconnection (ISORM) or to the
     unfortunately rather tacit reference model (ARM) to which the
     ARPANET protocols (e.g., TCP, IP, Telnet, FTP) were designed.  It
     also can't be just X.25 and X.28/X.29 (even with X.75 tossed in
     to handle "internetting" and X.121 for addressing) because: 1.
     They don't serve as a protocol suite for resource sharing (also
     known as OSI), but rather only allow for remote access [1]. 2.
     They (coming as they do from the Consultative Committee on
     International Telegraphy and Telephony--and including one or two
     other protocols, in reality) don't even constitute the full
     protocol suite being worked on by the U. S. National Bureau of
     Standards, much less the somewhat different suite being evolved
     by ISO.  So it must be a suite from NBS or ISO, and for present
     purposes we needn't differentiate between them as their Reference
     Models are close enough to be shorthanded as the ISORM.

     Timeliness

          Realizing that we're being asked to consider an
     ISORM-related protocol suite as what the vendors are expected to
     support has one immediate consequence which in some sense can be
     considered to dominate all of the other points to be raised:
     That is, the DoD procurement process entails quite long lead
     times.  Yet the ISORM suite is by no means complete at present.
     Without prejudice to its




                                     1
     RFC 873                                            September 1982


     merits or demerits, only X.25 (as levels 1-3, and with some
     ambiguity as to what level X.75 belongs at) is as yet firmly in
     the ISORM suite (which it will be convenient to refer to as
     "ISORMS"), and there is even some doubt as to how firmly they're
     there.  (E.g., a British observer at a recent PSTP meeting
     assured the author that "We in the U.K. don't believe X.25 is
     officially part of the ISORM.") There are proposals which have
     been circulating for some time at Level 4, and less far along
     through the international (or even national, remembering NBS)
     standardization process, ones at Level(s) 5-7.  It must be noted
     that:  1.  These are by and large "paper protocols" (that is,
     they have not been subjected to the test of actual use).  2.
     Even ISO and NBS's warmest supporters acknowledge that the
     standardization process "takes years."  So if the DoD is to avoid
     buying what might turn out to be a series of pigs in a series of
     pokes, it can't wait for the ISORMS.

          On the other side of the coin, the DoD is letting
     intercomputer networking contracts right now.  And, right now,
     there does exist a suite of protocols designed to the ARPANET
     Reference Model (ARMS, with no pun intended).  Implementations of
     the ARMS already exist for a number of operating systems already
     in use in the DoD.  Now, it is not argued that the ARMS protocols
     come "for free" in upcoming acquisitions (contractors fuss about
     the style of the available specifications, system maintainers
     fear incursions of non-vendor supplied code into operating
     systems, and so on), but it is unarguable that the ARMS can be
     procured significantly more rapidly than the ISORMS.  (It is also
     unarguable that those who speak of their unwillingness to see the
     DoD "develop new protocols rather than employ international
     standards" haven't done their homework; we're not talking about
     new protocols in the ARMS, we're talking about protocols that
     have been in real use for years.)

     Quality of Support

          The timeliness argument can lead to a counterargument that
     the ISORMS is "worth waiting for," though, so we're not done yet.
     Let's look further at what "vendor support" means.  Clearly, the
     proponents of the position expect that vendors' implementations
     of protocols will be in conformance with the Standards for those
     protocols.  Given the nature of these specifications, though,
     what can we infer about the quality of support we can expect from
     the vendors?

          There are two problem areas immediately apparent:
     ambiguities and options.  Let's take ambiguities first.  The
     following are some of the questions raised by knowledgable
     observers about the present state of the ISORMS:






                                     2
     RFC 873                                            September 1982


          1.   Can an X.25 comm subnet offer alternate routing?  (The
               answer depends on whether "DCE's" are expected to
               follow X.25 between themselves.  The situation is
               further complicated by the fact that some ISORM
               advocates don't even include the Data Communication
               Elements in their depictions of the Model; this leads
               to the metaphorical question* "Are there parking
               garages between the highrises?")  If you can conform to
               X.25 and not offer alternate routing--which certainly
               appears to be consistent with the spec, and might even
               be construed as required by it--the DoD's inherent
               interest in "survivability" cannot be served by you.

          2.   Can an X.75 internet offer alternate gatewaying?  (The
               answer is almost surely no, unless the X.75 spec is
               re-written.)  If not, again the DoD's interest is not
               served.

          3.   Does "Expedited Data" have semantics with regard to the
               L4-L5/L7 interface?  (Not as I read the spec, by the
               way.) If not, the ISORMS lacks the ability to convey an
               "Out-of-Band-Signal" to an Application protocol.  (This
               leads to the metaphorical question, "What good is an
               SST if there's nobody on duty at the Customs Shed?")

          4.   Must all layers be traversed on each transmission?
               (There are rumors of a new ISORM "null-layer" concept;
               it's not in the last version I looked at, however, and
               apparently the answer is yes at present.)  If so, the
               DoD's inherent interest in efficiency/timeliness cannot
               be served.  (This leads to the metaphorical question,
               "Are there elevators inside the highrises, or just
               staircases?")

          5.   Can an implementation be in conformance with the ISORM
               and yet flout the prescription that "N-entities must
               communicate with each other by means of N-1 entities"?
               (Not as I read the spec.)  If not, again
               implementations must be inefficient, because the
               prescription represents an inappropriate legislation of
               implementation detail which can only lead to
               inefficient implementations.

     _______________
     *  This and other metaphorical questions are dealt with at
        greater length in reference [2].









                                     3
     RFC 873                                            September 1982


          6.   Is each layer one protocol or many?  (The point quoted
               in 5 would seem to imply the latter, but many ISORM
               advocates claim it's the former except for L1 and L7.)