rfc874.txt

RFC 的详细文档！

     other hand, the metaphor is not being taken literally enough in
     some other sense (with the emphasis on the "virtual" aspect), for
     many construe it to imply that the logical connection it
     represents is "only as strong as a wire."  Whether the whole
     problem stems from the desire to "save bits" by not making
     addresses explicitly available on a per-transmission basis is
     conjectural, but if such be the case it is also unfortunate.

          (As an aside, it should be noted that there is some evidence
     that bit saving reaches fetish--if not pathological--proportions
     in X.25:  For instance, there does not even appear to be a Packet
     Type field in data packets; rather--as best we can determine--for
     data packets the low order bit of the "P(R)" field, which
     overlaps/stands in the place of the Packet Type is always 0,
     whereas in "real" Packet Type fields it's always 1.  [That may,
     by the way, not even be the way they do it--it's hard to tell ...
     or care.])

          There is also confusion even amongst its advocates as to
     what implications, if any, the protocol(s) has (have) for comm
     subnet node to comm subnet node (CSN) processing.  Those who draw
     just two highrises seem to be implying that from their
     perspective the CSN (or "DCE") is invisible.  This might make a
     certain amount of sense if they did not assert that each floor of
     a highrise has a "peer-relationship" with the corresponding floor
     of the other highrise--for to do so implies excessively long
     wires, well beyond the state of the wire-drawing art, when one
     notices that the first floor is the physical level.  (It also
     appears to disallow the existence of concatenated comm subnets
     into an internet, or "catenet," unless the CSN's are all
     identically constituted.  And those who hold that the ISORM
     dictates single protocols at each level will have a hard time
     making an HDLC interface into a Packet Radio Net, in all
     probability.)

          Those who, on the other hand, "draw parking garages," seem
     to be dictating that the internal structure of the CSN also
     adhere to X.25 link and physical protocols.  This implies that
     Packet Radio or satellite CSNs, for example, cannot "be X.25."
     Now that might be heartening news to the designers of such comm
     subnets, but it presumably wasn't intended by those who claim
     universality for X.25--or even for the ISO Reference Model.








                                     4
     RFC 874                                            September 1982


          Even granting that ambiguities in the conceptual model do
     not constitute prima facie grounds for rejecting the protocol(s),
     it is important to note that they almost assuredly will lead to
     vendor implementations based on differing interpretations that
     will not interoperate properly. And the unambiguous position that
     virtual circuits are broken whenever X.25 says so constitutes a
     flaw at least as grave as any of the ambiguities.

          Another, in our view extremely severe, shortcoming of the
     X.25 conceptual model is that it fails to address how programs
     that interpret its protocol(s) are to be integrated into their
     containing operating systems.  (This goes beyond the shortcoming
     of the X.25 specifications in this area, for even the advocates
     of the ISORM--who, by hypothesis at least, have adopted X.25 for
     their Levels 1-3--are reticent on the topic in their literature.)
     Yet, if higher level protocols are to be based on X.25, there
     must be commonality of integration of X.25 modules with operating
     systems at least in certain aspects.  The most important example
     that comes to mind is the necessity for "out-of-band signals" to
     take place.  Yet if there is no awareness of that sort of use
     reflected in the X.25 protocol's specification, implementers need
     not insert X.25 modules into their operating systems in such a
     fashion as to let the higher level protocols function properly
     when/if an X.25 Interrupt packet arrives.

          Yet much of the problem with the conceptual model might turn
     out to stem from our own misunderstandings, or the
     misunderstandings of others.  After all, it's not easy to infer a
     philosophy from a specification.  (Nor, when it comes to
     recognizing data packets, is it easy even to infer the
     specification--but it might well say something somewhere on that
     particular point which we simply overlooked in our desire to get
     the spec back on the shelf rapidly.) What other aspects of X.25
     appear to be "bad art"?

     "Personality Problems"

          When viewed from a functionality perspective, X.25 appears
     to be rather schizophrenic, in the sense that sometimes it
     presents a deceptively end-to-end "personality" (indeed, there
     are many who think it is usable as an integral Host-Host, or
     Transport, and network interface protocol, despite the fact that
     its specification itself--at least in the CCITT "Fascicle"
     version--points out several functional omissions where a
     higher-level protocol is expected--and we have even spoken to one
     or two people who say they actually do -- use it as an end-to-end
     protocol, regardless); sometimes it presents a comm subnet
     network interface personality (which all would agree it must);
     and sometimes (according to some observers) it presents a






                                     5
     RFC 874                                            September 1982


     "Host-Front End Protocol" personality.  Not to push the "bad art"
     methaphor too hard, but this sort of violation of "the Unities"
     is, if demonstrable, grounds for censure not only to literary
     critics but also to those who believe in Layering.  Let's look at
     the evidence for the split-personality claim:

          X.25 is not (and should not be) an "end-to-end" protocol in
     the sense of a Transport or Host-to-Host protocol.  Yet it has
     several end-to-end features.  These add to the space-time expense
     of implementation (i.e., consume "core" and CPU cycles) and
     reflect badly on the skill of its designers if one believes in
     the design principles of Layering and Least Mechanism.  (Examples
     of end-to-end mechanisms are cited below, as mechanisms
     superfluous to the network interface role.)  The absence of a
     datagram mode which is both required and "proper" (e.g., not Flow
     Controlled, not Delivery Confirmed, not Non-delivery mechanized)
     may also be taken as evidence that the end-to-end view is very
     strong in X.25.  That is, in ISO Reference Model (ISORM) terms,
     even though X.25 "is" L1-3, it has delusions of L4-ness; in
     ARPANET Reference Model (ARM) terms, even though X.25 could "be"
     L I, it has delusions of L II-ness.*

          X.25 is at least meant to specify an interface between a
     Host (or "DTE") and a comm subnet processor (or "DCE"),
     regardless of the ambiguity of the conceptual model about whether
     it constrains the CSNP "on the network side."  (Aside:  that
     ambiguity probably reflects even more badly on certain X.25
     advocates than it does on the designers, for there is a strong
     sense in which "of course it can't" is the only appropriate
     answer to the question of whether it is meant to constrain
     generic CSN processors (CSNP's) in the general case.  Note,
     though, that it might well be meant to constrain specific DCE's;
     that is, it started life as a protocol for PTT's--or Postal,
     Telephone, and Telegraph monopolies--and they are presumably
     entitled to constrain themselves all they want.)  Yet the
     end-to-end features alluded to above are redundant to the
     interfacing role, and, as noted, extraneous features have
     space-time consequences. There are also several features which,
     though not end-to-end, seem superfluous to a "tight" interface
     protocol.  Further, the reluctance of the designers to
     incorporate a proper "datagram" capability in the protocol (what
     they've got doesn't seem to be

     ________________
     *  For more on the ARM, see Padlipsky, M. A., "A Perspective on
        the ARPANET Reference Model", M82-47, The MITRE Corporation,
        September 1982; also available in Proc. INFOCOM '83.  (Some
        light may also be cast by the paper on the earlier-mentioned
        topic of Who Invented What.)






                                     6
     RFC 874                                            September 1982


     usable as a "pure"--i.e., uncontrolled at L3 but usable without
     superfluous overheard by L4--datagram, but instead entails
     delivery confirmation traffic like it or not; note that "seem" is
     used advisedly:  as usual, it's not easy to interpret the
     Fascicle) suggests at least that they were confused about what
     higher-level protocols need from interfaces to CSNP's, and at
     worst that there is some merit to the suggestion that, to
     paraphrase Louis Pouzin, "the PTT's are just trying to drum up
     more business for themselves by forcing you to take more service
     than you need."

          Examples of mechanisms superfluous to the interface role:

           1.  The presence of a DTE-DTE Flow Control mechanism.

           2.  The presence of an "interrupt procedure" involving the
               remote DTE.

           3.  The presence of "Call user data" as an end-to-end item
               (i.e., as "more" than IP's Protocol field).

           4.  The "D bit" (unless construed strictly as a "RFNM" from
               the remote DCE).

           5.  The "Q bit" (which we find nearly incomprehensible, but
               which is stated to have meaning of some sort to
               X.29--i.e., to at least violate Layering by having a
               higher-level protocol depend on a lower level
               machanism--and hence can't be strictly a network
               interface mechanism).

























                                     7
     RFC 874                                            September 1982


          The final "personality problem" of X.25 is that some of its
     advocates claim it can and should be used as if it were a
     Host-Front End protocol.*  Yet if such use were intended, surely
     its designers would have offered a means of differentiating
     between control information destined for the outboard
     implementation of the relevant protocols and data to be
     transmitted through X.25, but there is no evidence of such
     mechanisms in the protocol.  "Borrowing" a Packet Type id for
     H-FP would be risky, as the spec is subject to arbitrary
     alteration.  Using some fictitious DTE address to indicate the
     proximate DCE is also risky, for the same reason.  Further, using
     "Call user data" to "talk to" the counterpart H-FP module allows
     only 15 octets (plus, presumably, the 6 spare bits in the 16th
     octet) for the conversation, whereas various TCP and IP options
     might require many more octets than that.  Granted that with
     sufficient ingenuity--or even by the simple expedient of
     conveying the entire H-FP as data (i.e., using X.25 only to get
     channels to demultiplex on, and DTE-DCE flow control, with the
     "DCE" actually being an Outboard Processing Environment that gets
     its commands in the data fields of X.25 data packets)--X.25 might
     be used to "get at" outboard protocol interpreters, but its
     failure to address the issue explicitly again reflects badly on
     its designers' grasp of intercomputer networking issues.
     (Another possibility is that the whole H-FP notion stems from the
     use of X.25 as a Host-Host

     ________________
     *  That is, as a distributed processing mechanism which allows
        Host operating systems to be relieved of the burden of
        interpreting higher level protocols "inboard" of themselves by
        virtue of allowing Host processes to manipulate "outboard"
        interpreters of the protocols on their behalf.  Note that the
        outboarding may be to a separate Front-End processor or to the
        CSNP itself.  (The latter is likely to be found in
        microprocessor-based LAN "BIU's.")  Note also that when
        dealing with "process-level" protocols (ARM L III;
        approximately ISORM L5-7), only part of the functionality is
        outboarded (e.g., there must be some Host-resident code to
        interface with the native File System for a File Transfer
        Protocol) and even when outboarding Host-Host protocols (ARM L
        II; approximately ISORM L4 plus some of 5) the association of
        logical connections (or "sockets") with processes must be
        performed inboard--which is why, by the way, it's annoying to
        find ISO L5 below ISO L6: because, that is, you'd like to
        outboard "Presentation" functionality but its protocol expects
        to interact with the "Session" protocol, the functionality of
        which can't be outboarded.  (Although this approach, not the
        proper context for a full treatment of the H-FP approach, it
        is also of interest that the approach can effectively insulate
        the Host from changes in the protocol suite, which can be a
        major advantage in some environments.)




                                     8
     RFC 874                                            September 1982


     protocol so that some might think of it in its Host aspect as
     "simply" a way of getting at the H-HP.  This interpretation does