rfc928.txt

RFC 相关的技术文档

      for example, even though you'd expect to find OPEs that "come
      with" their own LANs as a fairly frequent product, we don't appeal
      to the notion in the conceptual model; nor do we attempt to
      dictate "chunk" sizes at the Channel level. A protocol spec isn't
      an implementation spec.

   Symmetric Begins

      For almost as long as there have been H-FPs, there has been
      disagreement over whether only the Host can begin a connection or
      if the OPE can also take the initiative.  I am delighted to be
      able to resolve this one finally:  It turns out there IS a
      compelling reason for insisting that THE PROTOCOL include
      provision for OPE --> Host Begins, so it's "in" the protocol--but
      any Host that doesn't need to deal with them doesn't have to (just
      "spell" the "Function not implemented" response code correctly).

      (In case anybody cares, the compelling reason is that if you HAD
      an MLS OPE which happened to use a security kernel and a process
      per level, you'd need IT to be listening for incoming connection
      requests "from the net" rather than having the Host tell it to do
      so, for various esoteric reasons--but in order to cater to the
      possibility, we want the function in the protocol from the


Padlipsky                                                      [Page 11]



RFC 928                                                    December 1984
Introduction to H-FP


      beginning, on the grounds that we can envision SOME other uses for
      it even in non-MLS environments [unlike the security labeling
      trick discussed above, which only seems to make sense for MLS
      Hosts/OPEs--that is, it doesn't burden the Host to reject a Begin
      every once in a while but it would to go around labeling "chunks"
      unnecessarily all the time].)

   Routing

      Concern has been voiced over the issue of what provisions the
      protocol should make to deal with the situation where a Host,
      probably for traffic/load reasons, has multiple OPEs and the
      question arises of which OPE to use/route to.  I claim this is a
      non-issue at the protocol level.  If the Host-side H-FP PI gets a
      "No resources" response to a Begin, it can go off to another OPE
      if it wants to.  "Not our department".  The conceptual model is
      that of a Host and AN OPE--which "ought to" be expandable to carry
      more load at some level.  If you want multiple links for some
      reason, the simplest solution would seem to be to have multiple
      Channel Layers as well, but the whole thing just gets too iffy to
      have anything sensible to prescribe in the protocol.  In other
      words, extending the concept to deal with discrete multiple OPEs
      is either a Fabrication sort of thing, or a Notes to Host-side
      Implementors sort of thing on a per specific OPE basis.

   Operator Interface

      It's probably implicit in the foregoing, but it might be worth
      saying explicitly that the operator interface to a specific OPE is
      a non-issue in terms of the protocol, beyond the provision we're
      made for "Shutdown coming" responses as a reflection of a probable
      operator interface action we imagine most operator interfaces
      would provide.  (It might also be worth noting that if your Host
      does "color changes", your OPE had better have a trustworthy way
      of being told to change the label it plops on all IP datagrams it
      emits, but that comes under the heading of an Aside to Specialized
      Implementors.)












Padlipsky                                                      [Page 12]



RFC 928                                                    December 1984
Introduction to H-FP


Fine Points

   There are a couple of known "loose ends" which are exceedingly fine
   points in some sense that do bear separate mention:

   The Allocate Event

      While mentally testing to see if the new H-FP would indeed
      off-load TCP, we came up against an interesting question: Viewing
      H-FP as "just an interface at a distance" to a TCP PI, what about
      the Allocate "Interface Event" in the TCP spec?  As far as I'm
      concerned, this could be classed as a non-issue, because I submit
      that the spec is wrong in declaring that there is such a thing as
      a MANDATORY Interface Event whereby the user of a TCP PI lets the
      PI know how much data it can take. Granted, you might find such a
      thing in most implementations, but what if you were in a virtual
      memory environment with segment sharing (or a distributed
      supervisor) and you wanted to avoid copies, so all that passed at
      the interface to the PI (or even at the interface from the PI) was
      a pointer?  That is, the "DOD version" of the TCP spec has fallen
      into the trap of assuming things about the execution environment
      that it shouldn't have.

      One moral of this is that

         AN INTERFACE TO AN INTERPRETER OF A PROTOCOL IS N*O*T "THE
         PROTOCOL".

      Another moral is that the interface to the Host-side H-FP PI is
      hard to say much about, but is where the equivalent functionality
      will be found if you've offloaded TCP.  That is, it's reasonable
      to let the user "tell" the outboard PI at Begin time if big or
      small buffers are expected to be in play "net-ward" as part of the
      protocol, but the outboard PI is expected to deliver bits to the
      Host as they come unless throttled by the Channel Layer, or by
      some to-be-invented other discipline to force the OPE to buffer.
      (For present purposes, we envision letting the Channel Layer
      handle it, but nifty mechanizations of encouraging the OPE to
      "make like a buffer" would be at least looked at.)  As a
      Fabrication issue, it is the case that "equity" has to be dealt
      with with regard to the use of the OPE's resources (especially
      buffers) across H-FP connections/channels, but that's a different
      issue anyway, touched upon in the final fine point.






Padlipsky                                                      [Page 13]



RFC 928                                                    December 1984
Introduction to H-FP


   Precedence

      Clearly, the existence of a notion of Precedence in DOD protocols
      has to get reflected in the outboard PI's implementations. Just
      what, if any, role it has in the H-FP, per se, is, however, by no
      means clear.  That is, if the Host doesn't take Begins from the
      OPE and is "full up" on the number of Server Telnet connections
      it's willing to handle, what should happen if a high precedence
      SYN comes in on the Telnet Well-Known Socket (in present day
      terms)?  Probably the OPE should arbitrarily close a low
      precedence connection to make room for the new one, and signal the
      Host, but even that assumes the Host will always hurry to be
      prepared to do a new passive Begin.  Perhaps we've stumbled across
      still another argument in favor of "Symmetric Begins"....  At any
      rate, Precedence does need further study--although it shouldn't
      deter us from making "the rest" of the protocol work while we're
      waiting for inspiration on how to handle Precedence too.

A Note on Host Integration

   The most important thing about Hosts in any intercomputer network is
   that they furnish the resources to be shared. The most significant
   obstacle to sharing those resources, however, is the fact that almost
   invariably they were designed under the assumption that the Host was
   a fully autonomous entity.  That is, few operating systems currently
   deployed "expect" to be members of a heterogeneous community of
   operating systems.  In many cases, this built-in insularity goes so
   far as to have applications programs cognizant of the particular type
   of terminal from which they will be invoked.

   Intercomputer networking protocols attempt to resolve the problems of
   heterogeneity by virtue of presenting appropriate common intermediate
   representations (or "virtualizations") of the constructs and concepts
   necessary to do resource sharing.  A Host-Host protocol such as TCP
   "is" a virtual interprocess communication mechanism; a virtual
   terminal protocol such as Telnet obviously is a mechanism for
   defining and dealing with virtual terminals; FTP offers common
   representations of files; and so on.  It cannot be stressed strongly
   enough, though, that this entire approach to intercomputer networking
   is predicated on the assumption that the modules which interpret the
   protocols (PIs, as we'll refer to them often) will be PROPERLY
   integrated into the various participating operating systems.  Even in
   the presence of powerful OPEs, wherein the bulk of the work of the
   various PIs is performed outboard of the Host, the inboard "hooks"
   which serve to interface the outboard PIs to the native system must
   not only be present, they must be "right".  The argument parallels
   the analysis of the flexible vs. rigid front-ending attachment


Padlipsky                                                      [Page 14]



RFC 928                                                    December 1984
Introduction to H-FP


   strategy issue of [1]; to borrow an example, if you attempt to
   integrate FTP by "looking like" a native terminal user and the
   operator forces a message to all terminals, you've got an undetected
   pollution of your data stream. So the key issue in attaching Hosts to
   networks is not what sort of hardware is required or what sort of
   protocol is interpreted by the Host and the OPE (or comm subnet
   processor, for that matter), but how the PIs (full or partial) are
   made to interrelate with the pre-existing environment.

   It would be well beyond the scope of this document to attempt even to
   sketch (much less specify) how to integrate H-FP PIs into each type
   of operating system which will be found in the DoD.  An example,
   though, should be of use and interest.  Therefore, because it is the
   implementation with which we are most intimately familiar, even
   though it's been several years, we propose to sketch the Multics
   operating system integration of the original ARPANET Network Control
   Program (NCP)--which is functionally equivalent to an H-FP PI for
   offloading ARM L II and L I--and Telnet.  (A few comments will also
   be made about FTP.) Note, by the way, that the sketch is for a
   "full-blown" H-FP; that is, shortcuts along the lines of the
   scenario-driven approach mentioned above are not dealt with here.

   One of the particularly interesting features of Multics is the fact
   that each process possesses an extremely large "segmented virtual
   memory".  That is, memory references other than to the segment at
   hand (which can itself be up to 256K 36-bit words long) indirect
   through a descriptor segment, which is in principle "just another
   segment", by segment number and offset within the segment, so that a
   single process--or "scheduling and access control entity"--can
   contain rather impressive amounts of code and data.  Given that the
   code is "pure procedure" (or "re-entrant"), a "distributed
   supervisor" approach is natural; each process, then, appears to have
   in its address space a copy of each procedure segment (with
   system-wide and process-specific data segments handled
   appropriately).  Without going too far afield, the distributed
   supervisor approach allows interrupts to be processed by whichever
   process happens to be running at a given time, although, of course,
   interprocess communication may well be a consequence of processing a
   particular interrupt.

   A few other necessary background points:  A distinguished process,
   called the Answering Service, exists, originally to field interrupts
   from terminals and in general to create processes after
   authenticating them.  Other shared resources such as line printers
   are also managed by distinguished processes, generically known as
   "Daemons".  Device driver code, as is customary on many operating
   systems, resides at least in part in the supervisor (or hard core


Padlipsky                                                      [Page 15]



RFC 928                                                    December 1984
Introduction to H-FP


   operating system).  Finally (for our purposes, at least), within a
   process all interfaces are by closed subroutine calls and all I/O is
   done by generic function calls on symbolically named streams; also,
   all system commands (and, of course, user written programs which need
   to) use the streams "user_input" and "user_output" for the obvious
   purposes.  (At normal process creation time, both user I/O streams
   are "attached" to the user's terminal, but either or both can be
   attached to any other I/O system interface module instead--including
   to one which reads and writes files, which is handy for consoleless
   processes.)

   All that almost assuredly doesn't do justice to Multics, but equally
   likely is more than most readers of this document want to know, so
   let's hope it's enough to make the following integration sketch
   comprehensible. (There will be some conscious omissions in the
   sketch, and doubtless some unconscious ones, but if memory serves, no
   known lies have been included.)

   Recalling that NCP is functionally equivalent to H-FP, let's start
   with it. In the first place, the device driver for the 1822 spec
   hardware interface resides in the supervisor. (For most systems, the
   PI for H-FP's link protocol probably would too.)  In Multics,
   interrupt time processing can only be performed by supervisor
   segments, so in the interests of efficiency, both the IMP-Host (1822
   software) Protocol PI and the multiplexing/demultiplexing aspects of
   the Host-Host Protocol PI also reside in the supervisor.  (An H-FP PI
   would probably also have its multiplexing/demultiplexing there; that
   is, that portion of the Channel Layer code which mediates access to
   the OPE and/or decides what process a given message is to be sent to
   might well be in the supervisor for efficiency reasons.  It is not,
   however, a hard and fast rule that it would be so. The system's
   native interprocess communications mechanism's characteristics might
   allow all the Channel Layer to reside outside of the supervisor.)

   Even with a very large virtual memory, though, there are
   administrative biases against putting too much in the supervisor, so
   "everything else" lives outside the supervisor. In fact, there are
   two places where the rest of the Host-Host Protocol is interpreted on
   Multics, although it is not necessarily the case that an H-FP PI