rfc928.txt

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

   A final preliminary:  all the designers and implementors of H-FPs
   present at the December meeting concurred that the true test of any
   protocol is how well it implements.  Therefore, until several
   implementations of the "new" protocol have been performed and
   assessed, it must be understood that the proposed protocol is
   precisely that:  a proposal, not a standard.

   Not too surprisingly, the first point on which consensus was reached
   is that there are three separable aspects (or "layers") to an H-FP:
   At bottom, there must be some physical means for conveying bits from
   Host to OPE and from OPE to Host.  As it has always been a premise of
   outboard processing that the Host's convenience is paramount, just
   what this physical layer is can vary:  typically, a bit-serial
   interface is customary, but parallel/DMA interfaces, if available for
   the Host and interfaceable to a given OPE, are fair game.  (So would
   teleporting the bits be, for that matter.)

   In the middle, there must be a layer to manage the multiplexing of
   network "connections" and the control of the flow between Host and
   OPE.  If we agree to call the lowest layer the Link and the middle
   layer the Channel, one thing which must be noted is that between the
   two of them, the Link and Channel layers must be responsible for
   reliably conveying the bits between Host and OPE. After all, an OPE'd
   Host should not be "weaker" than one with an inboard implementation
   of a robust Host-Host protocol such as TCP.  It should be noted that
   any Host which "comes with" a suitable implementation of the X.25
   interface protocol (where the definition of "suitable" is rather too
   complex to deal with here) could, given an OPE conditioned to accept
   it, quite cheerfully satisfy the requirements of the lower two
   layers. This is not to say that X.25 "is" the mechanization of H-FP's
   Link and Channel layers, however; merely that it could be used.  The
   protocol spec itself will detail an alternative, less cumbersome
   channel layer for Hosts which don't have or want X.25.

   The top layer of H-FP is the most important:  we refer to it as the
   Command layer.  Here is where the peer H-FP modules in a given Host
   and OPE communicate with each other. Indeed, the segregation of JUST
   multiplexing and flow control (plus reliability) into the Channel
   Layer is done--in addition to making it easier for Hosts that possess
   preexisting software/hardware which could be turned to the
   purpose--so as to clarify "what the H-FP is":  it's the commands and


Padlipsky                                                       [Page 5]



RFC 928                                                    December 1984
Introduction to H-FP


   responses of the Command layer wherewith the Host's processes are
   able to manipulate the outboard implementations of the members of a
   protocol suite. The use of the phrase "commands and responses" is
   rather significant, as it happens. For in the protocol to be proposed
   for DOD standardization, unlike all but one of its predecessors,
   binary encoded "headers" are not employed; rather, the H-FP commands
   are indeed ASCII strings, and the responses (following the practice
   of ARPANET FTP) ASCII-encoded numbers.

   There are various reasons for this departure, which initially stemmed
   from a desire to have the same NFE be usable for terminal traffic as
   well as Host offloading, but the one that seemed to dominate when
   consensus was arrived on it as the basis for the new standard is that
   it is very much in the original spirit of H-FP.  That is, if you want
   to "make things as easy as possible for the Host", it makes a great
   deal of sense to offload in a fashion that only requires some sort of
   scenario or script ("exec-com"/"command file"/"shell command" are
   approximations on some systems) in the Host, rather than requiring a
   program, possibly of more complexity than we would like. This is not
   to say that we envision all--or even most--Hosts will take the
   scenario approach to H-FP mechanization, but rather that the command
   orientation chosen allows for the possibility. (It would be useful to
   recall that the Channel layer does all the necessary
   multiplexing/demultiplexing, so that each channel's  metaphorical
   state machine--at least on the Host side--really has very little to
   worry about other than "doing its thing.")

   It should be noted that the proposed protocol provides a mechanism
   for offloading "all" protocols.  That is, although most "first
   generation NFEs" only handled ARPANET Reference Model Layers II and I
   (Host-Host and Network Interface--approximately ISO levels 4-1, with
   some of L5's functionality included when it comes to service
   identifications being handled via Well-Known Sockets in L II), it is
   assumed that OPEs will be evolved to handle L III offloading as well
   (ISO 5-7).  Indeed, it should also be noted that what is being
   addressed here is "the protocol", not "the" OPE.  More will be said
   on this topic below, and in the protocol spec itself, but it is
   important to realize from the outset that the H-FP being proposed is
   intended to be implementable by any number of OPE suppliers/vendors,
   so "an" OPE may or may not choose to implement, say, a given file
   transfer protocol, but provided it says so in proper H-FP terms and
   does offload some other protocols it's still an OPE in our sense of
   the term. (Cf. "Issues" and "Non-Issues", below.)






Padlipsky                                                       [Page 6]



RFC 928                                                    December 1984
Introduction to H-FP


Issues

   The following items are either in some sense still open issues or
   bear special emphasis:

   Command Approach

      The most striking feature of the new H-FP, especially to those who
      have seen older H-FPs, is the decision to employ
      character-oriented commands rather than the more conventional
      binary-oriented headers at the Command Layer.  As noted, the
      primary motivation was the report that the approach worked well
      when it was employed in an H-FP for the Platform Network called
      NAP (Network Access Protocol) [4]. In discussions with NAP's
      originator, Gerry Bailey, the author was convinced of the
      fundamental reasonableness of the approach, but of course that
      doesn't have to convince others.  Additional rationales emerged in
      discussions with Gary Grossman, the originator of the DCA/DTI
      H-FP [5], which is probably the best-known current H-FP and which
      furnished the default Channel Layer for the new one:  In the first
      place, the text approach makes parsing for the ends of
      variable-length parameters easier.  In the second place, it allows
      for the possibility of creating a terminal-supporting OPE in a
      very straightforward fashion should any OPE developer elect to do
      so.  (See below for more on the distinction between OPE developers
      and H-FP implementors.) Finally, there's nothing sacred about
      binary headers anyway, and just because the text approach is
      different doesn't make it "wrong".  So, although it's not out of
      the question that the new protocol should back off from the text
      approach if reviewers and/or implementors come up with compelling
      reasons for doing so, the already frequently encountered reaction
      of "it feels funny" isn't compelling.  (It was, indeed, the
      author's own initial reaction.)  Besides, "nobody" (not even Gary)
      really liked the top layer of the DCA/DTI H-FP.

   X.25 Appropriateness

      Of more concern than how text "feels" is whether X.25 "works".
      That is, we understand that many system proprietors would greatly
      prefer being able to use "off-the-shelf" software and hardware to
      the greatest extent feasible and still be able to do intercomputer
      networking according to DOD Standards, which is a major reason why
      we decided to take the H-FP commands out of the Channel Layer of
      the DCA/DTI H-FP even before we decided to encode them as text.
      However, it is by no means clear that any old vendor supplied
      "X.25" will automatically be usable as a new H-FP Channel and Link
      layer mechanization.  As noted, it all depends upon how Host


Padlipsky                                                       [Page 7]



RFC 928                                                    December 1984
Introduction to H-FP


      programs (the Command Layer/H-FP Protocol Interpreter in
      particular) are able to invoke X.25 on particular systems.  Also,
      there might be peculiarities in the handling of some constructs
      (the Group and Member fields--or whatever they're called--are a
      strong candidate) which could militate against getting JUST
      demultiplexing and flow control out of X.25-as-Channel
      Link/Layers.  For that matter, it's conceivable that on some
      systems only one process can "own" the presumed DCE, but there's
      no interprocess communication available between it and the
      processes that want to use H-FP.  What that all amounts to, then,
      is that we don't pretend to be sufficiently versed in the vagaries
      of vendor-idiosyncratic X.25 implementations to claim more than
      that we THINK the new H-FP Command Layer should fit "on top of"
      X.25 in a Host such that a suitably crafted OPE could look like a
      DCE to the low-level Host software and still be an OPE in our
      sense of the term.  Finally, some reports on bit-transfer rates
      attainable through typical X.25 interfaces give rise to concern as
      to whether such a lash-up would be "good" even if it were
      feasible.

      DCA/DTI Channel Layer Appropriateness

      The Channel Layer of the DCA/DTI H-FP has been implemented for a
      few Host types already, and is being implemented for others (in
      particular, as part of the DODIIS NFE project). A delicate
      decision is whether to alter the header structure (e.g.--and
      perhaps i.e.--to remove the now-superfluous command and response
      fields).  On the "con" side are the considerations that
      implementations DO exist, and that it's well specified.  On the
      "pro" side are that keeping the header as it is is in some sense
      "wasteful" and that somebody's going to have to go over the spec
      again anyway, to remove that which no longer applies.  (It should
      be noted that Gary Grossman was initially tempted to scuttle the
      Group and Member trick, but the presence of a similar
      dichotomizing in X.25 seems to rule that out.)  One of the
      interesting issues during the review phase of the new H-FP, then,
      will be the decision about which way to go on the Channel Layer
      header in its non-X.25 version.  (NOBODY considers going X.25
      only, be it noted.)  By the time the protocol is finalized, it
      will, of course, be made clear in the protocol spec, but I'll
      probably leave this in the final version of the Introduction just
      for historical interest anyway.

   Syntax

      Another point which probably needs close scrutiny during the
      review process is the "syntax" of the command lines.  Basically,


Padlipsky                                                       [Page 8]



RFC 928                                                    December 1984
Introduction to H-FP


      we just took our best shot, but without any claims that it's the
      best possible way to express things.  So comments and/or
      alternatives are earnestly solicited on this one.

   L III Offloading

      Contrary to the expectations of some, we are allowing for the
      offloading of Process/Applications Layer (ARPANET Reference Model
      L III) protocols.  Both Bailey and Grossman reported favorably on
      the feasibility of this. Two points should be made, however: It's
      perfectly fair for a GIVEN OPE implementation not to offload a
      given L III protocol, although it would presumably not sell as
      well as ones which did.  That is, we're not claiming that by
      inventing a mechanization of the feature in the spec we levy a
      constraint on everybody who implements "the protocol", (Cf.
      Fabrication under Non-Issues, below). Just as we were feeling our
      way on syntax in general, we're really feeling our way when it
      comes to the L III stuff.  (I'm not even sure I managed to convey