rfc928.txt

RFC 相关的技术文档

   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
      what I meant for "mediation level" to Joel and Dick.)  Again,
      suggestions are solicited.

   Security

      During the detailed design pass, we had an intensive discussion
      with some of the Blacker design team on the interplay between the
      new H-FP and a meant-to-be multilevel-secure OPE such as Blacker.
      The conclusion was that by and large "Security" is to be an aspect
      of an enhanced H-FP, rather than the standard one. The reasoning
      was rather involved, but seems to amount to the following:  Hosts
      that are NOT MLS (or "Compartmented") have two significant
      properties in our context: They're in the vast majority of
      present-day systems.  They have no legitimate need even to tell
      their OPEs what they "think" their current System High or
      Dedicated Mode level is; that information should be furnished by
      some trusted portion of a network security architecture (e.g., a
      security enhanced OPE, or a table in a "secure" comm subnet
      processor).

      Thus, even having the optional security label/level field in the
      Begin command is in some sense overkill, because we're not sure of
      any sensible circumstances in which it would be useful, but we put
      it in "just in case".  On the other hand, Hosts that ARE
      MLS/Compartmented by definition can be permitted to assert what
      the level of a given transmission (or perhaps of a given
      connection) should be, and their OPEs need to have a mechanism for
      learning this.  But it is by no means clear that a given Host (or
      even a given OPE) will be so structured as to make the H-FP PI,


Padlipsky                                                       [Page 9]



RFC 928                                                    December 1984
Introduction to H-FP


      the Channel PI, and the Link PI ALL trustworthy--as they'd have to
      be if the security labeling were part of H-FP.  So, we envision
      the labeling's being handled by trusted code in both Host and OPE
      that will be inserted into the normal processing route at the
      appropriate point for the given architecture (presumably "at the
      very bottom" of the Host, and "the very top" of the OPE), and that
      will place the label in a convenient, known position in the
      Host-OPE transmission "chunk" (block/packet/data unit) as the
      circumstances dictate. (It's likely--but we wouldn't swear to
      it--that a good place would be just before the H-FP command, and
      if that's the case then semi-clearly the security enhanced H-FP
      PIs would have to "make room" for it in the sense of handing the
      Channel Layer a suitably lengthened "chunk".)

      The Host and its OPE should be viewed as a single entity with
      regard to labeling requirements in the non-MLS/C case, and either
      the OPE will be conditioned to emit the right label or the CSNP
      will "know" anyway; in the MLS/C Host and OPE case (and it should
      be noted that it's just about impossible to envision a MLS/C Host
      which IS outboarded which DOESN'T have a MLS/C OPE) it will depend
      on the given security architectures as to whether each "chunk"
      needs labeling (i.e., there COULD be trusted H-FP, Channel, and
      Link PIs, so that only at channel establishment time does the
      label need to be passed), but it seems likely each "chunk" would
      need labeling, and we can see how that would happen (as sketched
      above).

      This is all, of course, subject to reappraisal when the full-time
      Security folks get in the act, but for now, H-FP per se is viewed
      as playing no direct role in "Security"--except indirectly, as
      noted below under the Symmetric Begins Non-Issue.  (In case
      anybody's worrying about the case where the OPE is physically
      remote from its Host, by the way, that line would have to be
      protected anyway, so the Host/OPE-asa-single-unit view should hold
      up.)

   How It Implements

      The final issue to take note of is that one of the central
      premises of the Outboard Processing approach has always been that
      H-FPs can be invented which implement more compactly on the Host
      side than the code they're allowing to be offloaded.  We certainly
      think the new H-FP will fulfill that condition, but we'd certainly
      like to hear of any evidence to the contrary.





Padlipsky                                                      [Page 10]



RFC 928                                                    December 1984
Introduction to H-FP


Non-Issues

   The following items are declared to be non-issues, in the sense that
   even though some people have expressed concern over them we believe
   that they are either "not part of the protocol" or resolved already
   for reasons that were overlooked by those worried about them:

   Fabrication

      Who builds OPEs isn't within our purview, except to the extent of
      hoping a few volunteers come forward to do testcase
      implementations of what is, at present, only a paper protocol.
      However, beyond agreeing that a few points should be marked as
      "Notes to Entrepreneurs" in the spec, we didn't attempt to dictate
      how an OPE vendor would behave, beyond the explicit and implicit
      dictates of the protocol per se. For example, if a given OPE
      doesn't offload SMTP, it jolly well ought to respond with the
      appropriate "Function not implemented" code, and if a vendor
      claims to accept X.25 for Channel and Link disagreements over what
      X.25 "is" are the province of the vendor and the customer, not of
      the H-FP spec.  As OPE'S are supposed to be offloading COMMON
      protocols in a COMMON fashion, a given OPE should be able to
      interoperate with another Host irrespective of whether that Host
      even has an OPE, much less whose OPE it is if it's there. Thus,