doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc48.txt b/doc/rfc/rfc48.txt
new file mode 100644
index 0000000..5cfecef
--- /dev/null
+++ b/doc/rfc/rfc48.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 48                                      S. Crocker
+                                                                    UCLA
+                                                          April 21, 1970
+
+
+                      A Possible Protocol Plateau
+
+I. Introduction
+
+   We have been engaged in two activities since the network meeting of
+   March 17, 1970 and, as promised, are reporting our results.
+
+   First, we have considered the various modifications suggested from
+   all quarters and have formed preferences about each of these.  In
+   Section II we give our preferences on each issue, together with our
+   reasoning.
+
+   Second, we have tried to formalize the protocol and algorithms for
+   the NCP, we attempted to do this with very little specification of a
+   particular implementation.  Our attempts to date have been seriously
+   incomplete but have led to a better understanding.  We include here,
+   only a brief sketch of the structure of the NCP.  Section III gives
+   our assumptions about the environment of the NCP and in Section IV
+   the components of the NCP are described.
+
+II. Issues and Preferences
+
+   In this section we try to present each of the several questions which
+   have been raised in recent NWG/RFC's and in private conversations,
+   and for each issue, we suggest an answer or policy.  In many cases,
+   good ideas are rejected because in our estimation they should be
+   incorporated at a different level.
+
+      A. Double Padding
+
+         As BBN report #1822 explains, the Imp side of the Host-to-Imp
+         interface concatenates a 1 followed by zero or more 0's to fill
+         out a message to an Imp word boundary and yet preserve the
+         message length.  Furthermore, the Host side of the Imp-to-Host
+         interface extends a message with 0's to fill out the message to
+         a Host word boundary.
+
+         BBN's mechanism works fine if the sending Host wants to send an
+         integral number of words, or if the sending Host's hardware is
+         capable of sending partial words.  However, in the event that
+
+
+
+
+
+Postel & Crocker                                                [Page 1]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+         the sending Host wants to send an irregular length message and
+         its hardware is only capable of sending word-multiple messages,
+         some additional convention is needed.
+
+         One of the simplest solutions is to modify the Imp side of the
+         Host-to-Imp interface so that it appends only 0's.  This would
+         mean that the Host software would have to supply the trailing
+         1.  BBN rejected the change because of an understandably strong
+         bias against hardware changes.  It was also suggested that a
+         five instruction patch to the Imp program would remove the
+         interface supplied 1, but this was also rejected on the new
+         grounds that it seemed more secure to depend only upon the Host
+         hardware to signal message end, and not to depend upon the Host
+         software at all.
+
+         Two other solutions are also available.  One is to have "double
+         padding", whereby the sending Host supplies 10* and the network
+         also supplies 10*.  Upon input, a receiving Host then strips
+         the trailing 10* 10*.  The other solution is to make use of the
+         marking.  Marking is a string of the form 0*1 inserted between
+         the leader and the text of a message.  The original intent of
+         marking was to extend the leader so that the sending Host could
+         _begin_ its text on a word boundary.  It is also possible to
+         use the marking to expand a message so that it _ends_ on a word
+         boundary.
+
+         Notice that double padding could replace marking altogether by
+         abutting the text beginning against the leader.  For 32 bit
+         machines, this is convenient and marking is not, while for
+         other lengths, particularly 36 bit machines, marking is much
+         more convenient than double padding.
+
+         We have no strong preference, partially because we can send
+         word fragments.  Shoshani, et al in NWG/RFC #44 claim that
+         adjusting the marking does not cause them any problems, and
+         they have a 32 bit machine.  Since the idea of marking has been
+         accepted for some time, we suggest that double padding not be
+         used and that marking be used to adjust the length of a
+         message.  We note that if BBN ever does remove the 1 from the
+         hardware padding, only minimal change to Host software is
+         needed on the send side.
+
+         A much prettier (and more expensive) arrangement was suggested
+         by W. Sutherland.  He suggested that the Host/Imp interfaces be
+         smart enough to strip padding or marking and might even parse
+         the message upon input.
+
+
+
+
+
+Postel & Crocker                                                [Page 2]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+      B. Reconnection
+
+         A very large population of networkers has beat upon us for
+         including dynamic reconnection in the protocol.  We felt it
+         might be of interest to relate how it came to be included.
+
+         After considering connections and their uses for a while, we
+         wondered how the mechanism of connections compared to existing
+         forms of intra-Host interprocess communication.  Two aspects
+         are of interest, what formalisms have been presented in the
+         literature, and what mechanisms are in use.  The formalisms are
+         interesting because they lead to uniform implementations and
+         parsimonious design.  The existing mechanisms are interesting
+         because they point out which problems need solving and
+         sometimes indicate what an appropriate formalism might be.  In
+         particular, we have noticed that the mechanisms for connecting
+         a console to the logger upon dial in, the mechanisms for
+         creating a job, and the mechanisms for passing a console around
+         to various processes within a job tend to be highly
+         idiosyncratic and distinct from all other structures and
+         mechanisms within an operating system.
+
+         With respect to the literature, it appears there is only one
+         idea with several variations, viz processes should share a
+         portion of their address spaces and cooperatively wake up each
+         other.  Semaphores and event channels are handy extensions of
+         wake up signals, but the intent is basically the same.  (Event
+         channels could probably function as connections, but it seems
+         not to be within their intended use.  In small systems, the
+         efficiency and capacity of event channels are inversely
+         related.)
+
+         With respect to existing implementations, we note that several
+         systems allow a process to appear to be a file to another
+         process.  Some systems, e.g. the SDS-940 at SRI impose a
+         master/slave relationship between two processes so connected,
+         but other systems provide for a coequal relationship e.g. the
+         AI group's PDP-6 system at MAC.  The PDP-6 system also has a
+         feature whereby a superior process can "surround" an inferior
+         process with a mapping from device and file names to other
+         device and file names.  Consoles have nearly the same semantics
+         as files, so it is quite reasonable for an inferior process to
+         believe it is communicating with the console but in fact be
+         communicating with another process.
+
+         The similarity between network connections and existing
+         sequential interprocess connections supports our belief that
+         network connections are probably the correct structure for
+
+
+
+Postel & Crocker                                                [Page 3]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+         using the network.  Moreover, the structure is clean enough and
+         compatible with enough machines to pass as a formalism or
+         theory, at least to the extent of the other forms of
+         interprocess communication presented in the literature.
+
+         Any new formalism, we believe, must meet at least the following
+         two tests:
+
+            1. What outstanding problems does it solve?
+            2. Is it closed under all operations?
+
+         In the case of network connections, the candidates for the
+         first are the ones given above, i.e. all operations involving
+         connecting a console to a job or a process.  Also of interest
+         are the modelling of sequential devices such as tape drives,
+         printers and card readers, and the modeling of their buffering
+         (spooling, symbiont) systems.
+
+         The second question mentions closure.  In applying the
+         connection formalism to the dial-in and login procedures, we
+         felt the need to include some sort of switching or
+         reconnection, and an extremely mild form is presented in an
+         SJCC paper, which is also NWG/RFC #33.  This mild form permits
+         only the substitution of AEN's, and even then only at the time
+         of connection establishment. However, it is a common experience
+         that if an operation has a natural definition on an extended
+         domain, it eventually becomes necessary or at least desirable
+         to extend its definition.  Therefore, we considered the
+         following extensions:
+
+            1. Switching to any other socket, possibly in another Host.
+            2. Switching even after data flow has started.
+
+         There is even some precedent for feeling these extensions might
+         be useful.  In one view of an operating system, we see all
+         available phone lines as belonging to a live process known as
+         the logger.  The logger answers calls, screens users, and
+         creates jobs and processes.  One of the features of most
+         telephone answering equipment is that many phone lines may
+         serve the same phone number by using a block of sequential
+         numbers and a rotary answering system.  In our quest for
+         accurate models of practical systems, we wanted to be able to
+         provide equivalent service to network users, i.e. they should
+         be able to call a single advertised number and get connected to
+         the logger.  Thus a prima facie case for switching is
+         established.
+
+
+
+
+
+Postel & Crocker                                                [Page 4]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+         Next we see that after the logger interrogates a prospective
+         user, it must connect the user to a newly created job.  Data
+         flow between the user and the logger has already commenced, so
+         flow control has to be meshed with switching if it is desired
+         not to lose or garble data in transit.
+
+         With respect to inter-Host switching, we find it easy to
+         imagine a utility service which is distributed throughout the
+         network and which passes connections from one socket to another
+         without the knowledge of the user.  Also, it is similar to the
+         more sophisticated telephone systems, to standard facilities of
+         telephone company operators, and to distributed private
+         systems.
+
+         These considerations led us to investigate the possibility of
+         finding one type of reconnection which provided a basis for all
+         known models.  The algorithm did not come easily, probably
+         because of inexperience with finite state automata theory, but
+         eventually we produced the algorithm presented in NWG/RFC #36.
+         A short time later, Bill Crowther produced an equivalent
+         algorithm which takes an alternate approach to race conditions.
+
+         Networkers seem to have one of two reactions.  Either it was
+         pretty and (perhaps ipso facto) useful, or it was complex and
+         (again perhaps ipso facto) unnecessary.  The latter group was
+         far more evident to us, and we were put into the defensive
+         position of admitting that dynamic reconnection was only
+
+            1. pretty
+            2. useful for login and console passing
+
+         In response to persistent criticism, we have made the following
+         change in the protocol.  Instead of calling socket <O,H,O> to
+         login, sockets of the form <U,H,O> and <U,H,1> are the input
+         and output sockets respectively of a copy of the logger or, if
+         a job has been stared with user id U, these sockets are the
+         console sockets.  The protocol for login is thus to initiate a
+         connection to <U,H,O> and <U,H,1>.  If user U is not in use, a
+         copy of the logger will respond and interrogate the caller.  If
+         user id U is in use, the call will be refused.  This
+         modification was suggested by Barry Wessler recently.  (Others
+         also suggested this change much earlier; but we rejected it
+         then.)
+
+         The logger may demand that the caller be from the same virtual
+         net, i.e. the caller may have user id U in some other Host, or
+         it may demand that the user supply a password matched to user
+
+
+
+
+Postel & Crocker                                                [Page 5]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+         id U, or it may demand both.  Some systems may even choose to
+         permit anybody to login to any user id.
+
+         After login, AEN's 0 and 1 remain the console AEN's.  Each
+         system presumably has mechanisms for passing the console, and
+         these would be extended to know about AEN's 0 and 1 for network
+         users.  Passing the console is thus a matter of reconnecting
+         sockets to ports, and happens within the Host and without the
+         network.
+
+         In conversations with Meyer and Skinner after NWG/RFC #46 was
+         received, they suggested a login scheme different from both
+         Meyer's and ours in section above.  Their new scheme seemed a
+         little better and we look forward to their next note.
+
+         It is generally agreed that login should be "third-level", that
+         is, above the NCP level.  We are beginning to be indifferent
+         about particular logins schemes; all seem ok and none impress
+         us greatly.  We suggest that several be tried.  It is some
+         burden, of course, to modify the local login procedure, but we
+         believe it imposes no extra hardship to deal with diverse login
+         procedures.  This is because the text sequences and interrupt
+         conventions are so heterogenous that the additional burden of
+         following, say, our scheme on our system and Meyer's on Multics
+         is minimal.
+
+         We are agreed that reconnection should not be required in the
+         initial protocol, and we will offer it later as an optional and
+         experimental tool.  In addition, we would like to be on record
+         as predicting that general reconnection facilities will become
+         useful and will provide a unifying framework for currently ad
+         hoc operating system structures.
+
+      C. Decoupling Connections and Links
+
+         Bill Crowther (BBN) and Steve Wolfe (UCLA) independently have
+         suggested that links not be assigned to particular connections.
+         Instead, they suggest, include the destination socket as part
+         of the text of the message and then send messages over any
+         unblocked link.
+
+         We discussed this question a little in NWG/RFC #37, and feel
+         there is yet an argument for either case.  With the current
+         emphasis on simplicity, speed and small core requirements, it
+         seems more efficient to leave links and connections coupled.
+         We, therefore, recommend this.
+
+
+
+
+
+Postel & Crocker                                                [Page 6]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+      D. Error Reporting
+
+         As mentioned by J. Heafner and E. Harslem of RAND, it is
+         important to treat errors which might occur.  A good philosophy
+         is to guard against any input which destroys the consistency of
+         the NCP's data base.
+
+         The specific formulation of the error command given by Heafner
+         and Harslem in NWG/RFC #40 and by Meyer in NWG/RFC #46 seems
+         reasonable and we recommend its adoption.  Some comments are in
+         order, however.
+
+         A distinction should be made between resource errors and other
+         types of errors.  Resource errors are just the detection of
+         overload conditions.  Overload conditions are well-defined and
+         valid, although perhaps undesirable.  Other types of errors
+         reflect errant software or hardware.  We feel that resource
+         errors should not be handled with error mechanisms, but with
+         mechanisms specific to the problem.  Thus the <CLS> command may
+         be issued when there is no more room to save waiting <RFC>'s.
+         Flow control protocol is designed solely to handle buffering
+         overload.
+
+         With respect to true errors, we are not certain what the value
+         of the <ERR> command is to the recipient.  Presumably his NCP
+         is broken, and it may only aggravate the problem to bombard it
+         with error commands.  We therefore, recommend that error
+         generation be optional, that all errors be logged locally in a
+         chronological file and that <ERR> commands received likewise be
+         logged in a chronological file.  No corrective action is
+         specified at this time.
+
+         In the short time the network has been up at UCLA, we have
+         become convinced that the network itself will generate very few
+         errors.  We have watched the BBN staff debug and test the IMP
+         program, and it seemed that most of the errors affected timing
+         and throughput rather than validity.  Hence most errors will
+         probably arise from broken Hosts and/or buggy NCP's.
+
+      E. Status Testing and Reporting
+
+         A valuable debugging aid is to be able to get information about
+         what a foreign NCP thinks is happening.  A convenient way to do
+         this is to permit NCP's to send status whenever they wish, but
+         to always have them do it whenever they receive a request.
+
+
+
+
+
+
+Postel & Crocker                                                [Page 7]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+         Since we view this feature as primarily a debugging tool, we
+         suggest that a distinct link, like 255, be used.  The intent is
+         that processing of status requests and generating of status
+         messages should use as little of the normal machinery as
+         possible.  Thus we suggest that link 255 be used to send
+         "request status" and "status is" commands.  The form follows
+         the suggestion on page 2 of NWG/RFC #40.
+
+         Meyer's <ECO> command is easily implemented and serves the more
+         basic function of testing whether a foreign NCP is alive.  We
+         suggest that the length of the <ECO> command be variable, as
+         there seems to be no significance in this context to 48 bits.
+         Also, the value of a (presumably) 8 bit binary switch is
+         unclear, so we recommend a pair of commands:
+
+                   <ECO>   <length>   <text>
+         and
+                   <ERP>   <length>   <text>
+         where
+                   <length> is 8 bits.
+
+         Upon receipt of an <ECO> command the NCP would echo with the
+         <ERP> command.
+
+      F. Expansion and Experimentation
+
+         As Meyer correctly points out in NWG/RFC #46, network protocol
+         is a layered affair.  Three levels are apparent so far.
+
+            1. IMP Network Protocol
+            2. Network Control Program Protocol
+            3. Special user level or Subsystem Level Protocol
+
+         This last level should remain idiosyncratic to each Host (or
+         even each user).  The first level is well-specified by BBN, and
+         our focus here is on level 2.  We would like to keep level 2 as
+         neutral and simple as possible, and in particular we agree that
+         login protocol should be as much on level 3 as possible.
+
+         Simplicity and foresight notwithstanding, there will arise
+         occasions when the level 2 protocol should change or be
+         experimented with.  In order to provide for experimentation and
+         change, we recommend that only link numbers 2 through 31 be
+         assigned to regular connections, with the remaining link
+         numbers, 32 to 255, used experimentally.  We have already
+         suggested that link 255 be used for status requests and
+         replies, and this is in consonance with our view of the
+         experimental aspects of that feature.
+
+
+
+Postel & Crocker                                                [Page 8]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+         We also recommend that control command prefixes from 255
+         downward be used for experimentation.
+
+         These two conventions are sufficient, we feel to permit
+         convenient experimentation with new protocol among any subset
+         of the sites. We thus do not favor inclusion of Ancona's
+         suggestion in NWG/RFC #42 for a message data type code as the
+         first eight bits of the text of a message.
+
+      G. Multiplexing Ports to Sockets
+
+         Wolfe in NWG/RFC #38 and Shoshani et al in NWG/RFC #44 suggest
+         that it should be possible to attach more than one port to a
+         socket.  While all of our diagrams and prototypical system
+         calls have shown a one-to-one correspondence between sockets
+         and ports, it is strictly a matter of local implementation.  We
+         note that sockets form a network-wide name space whose sole
+         purpose is to interface between the idiosyncratic structures
+         peculiar to each operating system.  Our references to ports are
+         intended to be suggestive only, and should be ignored if no
+         internal structures corresponds to them.  Most systems do have
+         such structures, however, so we shall continue to use them for
+         illustration.
+
+      H. Echoing, Interrupts and Code Conversion
+
+         1. Interrupts
+
+            We had been under the impression that all operating systems
+            scanned for a reserved character from the keyboard to
+            interpret it as an interrupt signal.  Tom Skinner and Ed
+            Meyer of MIT inform us that model 37 TTY's and IBM 2741
+            generate a "long space" of 200-500 milliseconds which is
+            detected by the I/O channel hardware and passed to the
+            operating system as an interrupt.  The "long space" is not a
+            character -- it has no ASCII code and cannot be program
+            generated.
+
+            Well over a year ago, we considered the problem of
+            simulating console interrupts and rejected the <INT> type
+            command because it didn't correctly model any system we
+            knew.  We now reverse our position and recommend the
+            implementation of an INTERRUPT system call and an <INT>
+            control command as suggested by Meyer in NWG/RFC #46.
+
+
+
+
+
+
+
+Postel & Crocker                                                [Page 9]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+            Two restrictions of the interrupt facility should be
+            observed.  First, when communicating with systems which scan
+            for interrupt characters, this feature should not be used.
+            Second, non-console-like connections probably should not
+            have interrupts. We recommend that systems follow their own
+            conventions, and if an <INT> arrives for a connection on
+            which it shouldn't the <INT> should be discarded and
+            optionally returned as an error.
+
+         2. Echoing and Code Conversion
+
+            We believe that each site should continue its current
+            echoing policy and that code conversion should be done by
+            the using process.  Standardization in this area should
+            await further development.
+
+            Ancona's suggestion of a table-driven front-end transducer
+            seems like the right thing, but we believe that such
+            techniques are part of a larger discussion involving
+            higher-level languages for the network.
+
+      I. Broadcast Facilities
+
+         Heafner and Harslem suggest in NWG/RFC #39 a broadcast
+         facility, i.e. <TER> and <BDC>.  We do not fully understand the
+         value of this facility and are thus disposed against it.  We
+         suspect that we would understand its value better if we had
+         more experience with OS/360.  It is probably true in general
+         that sites running OS/360 or similar systems will find less
+         relevance in our suggestions for network protocol than sites
+         running time-sharing systems.  We would appreciate any cogent
+         statement on the relationship between OS/360 and the concepts
+         and assumptions underlying the network protocol.
+
+      J. Instance Numbers
+
+         Meyer in NWG/RFC #46 suggests extending a socket to include an
+         _instance_ code which identifies the process attached to the
+         socket.  We carefully arranged matters so that processes would
+         be indistinguishable.  We did this with the belief that both as
+         a formal and as a practical matter it is of concern only within
+         a Host whether a computation is performed by one or many
+         processes.  Thus we believe that all processes within a job
+         should cooperate in allocating AEN's.  If an operating system
+         has facilities for passing a console from process to process
+         within a job, these facilities mesh nicely with the current
+         network protocol, even within reconnection protocol; but
+         instance numbers interfere with such a procedure.
+
+
+
+Postel & Crocker                                               [Page 10]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+         We suggest this matter be discussed fully because it relates to
+         the basic philosophy of sockets and connections.  Presently we
+         recommend 40 bit socket numbers without instance codes.
+
+      K. AEN's
+
+         Nobody, including us, is particularly happy with our name AEN
+         for the low order 8 bits of the socket.  We rejected _socket_
+         number_, and are similarly unhappy with Meyer's _socket_code_.
+         The word socket should not be used as part of the field name,
+         and we solicit suggestions.
+
+III. Environment
+
+   We assume that the typical host will have a time-sharing operating
+   system in which the cpu is shared by processes.
+
+   Processes
+
+   We envision that each process is tagged with a _user_number_. There
+   may be more than one process with the same user number, and if so,
+   they should all be cooperating with respect to using the network.
+
+   We envision that each process contains a set of _ports_ which are
+   unique to the process.  These ports are used for input to or output
+   from the process, from or to files, devices or other processes.
+
+   We also envision that each process has an event channel over which it
+   can receive very short messages (several bits).  We will use this
+   mechanism to notify a process that some action external to the
+   process has occurred.
+
+   To engage in network activity, a process _attaches_ a _local_socket_
+   to one of its ports.  Sockets are identified by user number, host and
+   AEN, and a socket is local to a process if their user numbers match
+   and they are in the same host.  A process need only specify an AEN
+   when it is referring to a local socket.
+
+   Each port has a status which is modified by system calls and by
+   concurrent events outside the process.  Whenever the status of a port
+   is changed, the process is sent an event over its event channel which
+   specifies which port's status has changed.  The process may then look
+   at a port's status.
+
+   These assumptions are used descriptive material which follows.
+   However, these assumptions are not imposed by the network protocol
+   and the implementation suggested by section IV is in no way binding.
+
+
+
+
+Postel & Crocker                                               [Page 11]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+   We wish to make very clear that this material is offered only to
+   provide clues as to what the implementation difficulties might be and
+   not to impose any particular discipline.
+
+   For example, we treat <RFC>'s which arrive for unattached local
+   sockets as valid and queue them.  If desired, an NCP may reject them,
+   as Meyer suggests, or it might hold them for awhile and reject them
+   if they're not soon satisfied.  The offered protocol supports all
+   these options.
+
+   Another local option is the one mentioned before of attaching
+   multiple ports to a socket.  We have shown one-one correspondence but
+   this may be ignored.  Similarly, the system calls are merely
+   suggestive.
+
+   System Calls
+
+   These are typical system calls which a user process might execute.
+   We show these only for completeness; each site will undoubtedly
+   implement whatever equivalent set is convenient.
+
+        We use the notation
+
+        Syscall ( arg , arg ...; val ... )
+                     1     2        1
+   where
+        Syscall is the system call
+        arg  etc. are the parameters supplied with the call, and
+           1
+        val etc. are any values returned by the system call.
+           1
+
+   Init (P,AEN,FS,Bsiz;C)
+
+        P      Specifies a port of the process.
+        AEN    Specifies a local socket.  The user number of this
+               process and host number of this host are implicit.
+        FS     Specifies a socket with any user number in any host,
+               with any AEN.
+        Bsiz   Specified the amount of storage in bits the user wants
+               to devote to buffering messages.
+        C      The condition code returned.
+
+   Init attempts to attach the local socket specified by AEN to the port
+   P and to initiate a connection with socket FS.  Possible returned
+   values of C are
+
+
+
+
+
+Postel & Crocker                                               [Page 12]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+        C = ok      The Init was legal and the socket FS is being
+                    contacted.  When the connection is established or
+                    when FS refuses, the process will receive an event.
+
+        C = busy    The local socket was in use by a port on this or
+                    some other process with the same user number.  No
+                    action was taken.
+
+        C = homosex The AEN and FS were either both send or both receive
+                    sockets.
+
+        C = nohost  The host designated within FS isn't known.
+
+        C = bufbig  Bsiz is too large.
+
+   Listen (P,AEN,Bsize;C)
+
+        P     Specifies a port of the process.
+        AEN   Specifies a local socket.
+        Bsiz  Specified a buffer size.
+        C     The returned legality code.
+
+   Codes for C are
+
+        C = ok
+        C = busy
+        C = bufbig
+
+   The local socket specifies by AEN is attached to P.  If there is a
+   waiting call, it is processed; otherwise no action is taken.  When a
+   call comes in, a connection will be established and the process
+   notified via an event.
+
+   Close (P)
+
+        P Specifies a port of the process.
+
+   Any activity is stopped, and the port becomes free for other use.
+
+   Transmit (P,M,L1;L2,C)
+
+        P     Specifies port with an open connection.
+        M     The text to be transmitted.
+        L1    Specifies the length of the text.
+        L2    The length actually transmitted.
+        C     The error code.
+
+
+
+
+
+Postel & Crocker                                               [Page 13]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+   Transmission between the processes on either side of the port takes
+   place.
+
+   Codes for C are
+
+        C = ok
+   or
+        C = not open     if no connection is currently open and
+                         otherwise uninhibited
+   Status (P;C)
+
+   The status of port P is returned as C.
+
+IV. The NCP
+
+   We view the NCP as having five component programs, three associative
+   tables, some queues and buffers, and a link assignment table.  Each
+   site will of course, vary this design to meet its needs, so our
+   design is only illustrative.
+
+   The Component Programs
+
+      1. The Input Handler
+
+         This is an interrupt driven input routine.  It initiates Imp-
+         to-Host transmission into a resident buffer and wakes up the
+         Input Interpreter when transmission is complete.
+
+      2. The Output Handler
+
+         This is an interrupt driven output routine.  It initiates
+         Host-to-Imp transmission out of a resident buffer and wakes up
+         the Output Scheduler when transmission is complete.
+
+      3. The Input Interpreter
+
+         This program decides whether the input is a regular message
+         intended for a user, a control message, an Imp-to-Host message,
+         or an error.  For each class of message, this program takes the
+         appropriate action.
+
+      4. The Output Scheduler
+
+         Three classes of message are sent to the Imp
+
+            (a) Host-to-Imp messages
+            (b) Control messages
+            (c) Regular messages
+
+
+
+Postel & Crocker                                               [Page 14]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+         We believe that a priority should be imposed among these
+         classes.  The priority we suggest is the ordering above. The
+         Output Scheduler selects the highest priority message and
+         gives it to the Output Handler.
+
+      5. The System Call Interpreter
+
+         This program interprets requests from the user.
+
+   The two interesting components are the Input Interpreter and the
+   System Call Interpreter.  These are similar in that the Input
+   Interpreter services foreign requests and the System Call Interpreter
+   services local requests.
+
+   Associative Tables
+
+   We envision that the bulk of the NCP's data base is in three
+   associative tables.  By "associative", we mean that there is some
+   lookup routine which is presented with a key and either returns
+   successfully with a pointer to the corresponding entry, or fails if
+   no entry corresponds to the key.
+
+      1. The Rendezvous Table
+
+         "Requests-for-connection" and other attributes of a
+         connection are held in this table.  This table is accessed by
+         local socket, but other tables have pointers to existing
+         entries.
+
+            The components of an entry are:
+
+            (a) local socket   (key)
+            (b) foreign socket
+            (c) link
+            (d) queue of callers
+            (e) text queue
+            (f) connection state
+            (g) flow state
+            (h) pointer to attached port
+
+            An entry is created when a user executes either an Init or a
+            Listen system call or when a <RFC> is received.  Some fields
+            are unused until the connection is established, e.g. the
+            foreign socket is not known until a <RFC> arrives if the
+            user did a Listen.
+
+
+
+
+
+
+Postel & Crocker                                               [Page 15]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+      2. The Input Link Table
+
+            The Input Interpreter uses the foreign host and link as a
+            key to get a pointer to the entry in the rendezvous table
+            for the connection using the incoming link.
+
+      3. The Output Link Table
+
+            In order to interpret RFNM's, the Input Interpreter needs a
+            table in the same form as the Input Link Table but using
+            outgoing links.
+
+   Link Assignment Table
+
+   This is a very simple structure which keeps track of which links are
+   in use for each host.  One word per host probably suffices.
+
+   The following diagram is our conception of the Network Control
+   Program.  Boxes represent tables and Buffers, boxes with angled
+   corners and a double bottom represent Queues, and jagged boxes
+   represent component programs, the arrows represent data paths.
+
+   The abbreviated names have the following meanings.
+
+   ILT   - Input Link Table
+
+   OLT   - Output Link Table
+
+   LAT   - Link Assignment Table
+
+   RT    - Rendezvous Table
+
+   HIQ   - Host to Imp Queue
+
+   OCCQ  - Output Control Command Queue
+
+   ORMQ  - Output Regular Message Queue
+
+   IHBuf - Buffer filled by the Input Handler from the IMP and
+           emptied by the Input Interpreter
+
+   OHBuf - Buffer of outgoing messages filled from the Queues
+           by the Output Scheduler and emptied by the Output
+           Handler.
+
+
+
+
+
+
+
+Postel & Crocker                                               [Page 16]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+                              +---------+
+                              |  I M P  |
+                              +---------+
+                                v     ^
+                                |     |
+    +---------------------------|-----|------------------------------+
+    |                           |     |                              |
+    |   /\/\/\/\/\/\/\          |     |     /\/\/\/\/\/\/\           |
+    |   \            / <--------+     +---< \            /           |
+    |   /  Input     \                      /  Output    \           |
+    |   \   Handler  /                      \   Handler  / <----+    |
+    |   /            \ >------+             /            \      |    |
+    |   \/\/\/\/\/\/\/        |             \/\/\/\/\/\/\/      ^    |
+    |                         v                              +-----+ |
+    |                      +-----+                           | OH  | |
+    |                      | IM  |                           | Buf | |
+    |                      | Buf |                           +-----+ |
+    |                      +-----+          /\/\/\/\/\/\/\/\    ^    |
+    | /\/\/\/\/\/\/\/\        v      +----> \              /    |    |
+    | \              /        |      |      /  Output      \ >--+    |
+    | /              \ <------+      ^      \              /         |
+    | \  Input       /           /-----\    /   Scheduler  \         |
+    | /              \ >-------->| HIQ |    \              /         |
+    | \  Interpreter /           |_____|    /              \         |
+    | /              \ >----+    \_____/    \/\/\/\/\/\/\/\/         |
+    | \/\/\/\/\/\/\/\/      |                ^     v    ^            |
+    |   ^   ^    ^   \      |    /-----\     |     |    |    /-----\ |
+    |   |    \    \   \     |    |  O  |     |     |    |    |  O  | |
+    |   |     \    \   \    +--->|  C  |>----+     |    +---<|  R  | |
+    |   v     v     v   \        |  C  |           |         |  M  | |
+    | +---+ +---+ +---+  \       |  Q  |           v         |  Q  | |
+    | |   | |   | |   |   \      |_____|      +---------+    |_____| |
+    | |ILT| |LAT| |OLT|    \     \_____/      |         |    \_____/ |
+    | |   | |   | |   |     \       ^         |   R T   |       ^    |
+    | +---+ +---+ +---+      +------|-------->|         |       |    |
+    |         v                     |         +---------+       |    |
+    |         |                     ^              ^            |    |
+    |         |            /\/\/\/\/\/\/\/\        |            |    |
+    |         |            \              /        |            |    |
+    |         +----------->/    System    \<-------+            |    |
+    |                      \     Call     /                     |    |
+    |                      /  Interpreter \>--------------------+    |
+    |                      \              /                          |
+    |                  +-->/              \>--+                      |
+    |                  |   \/\/\/\/\/\/\/\/   |                      |
+    +------------------|----------------------|----------------------+
+                       |                      |
+                       +---< system calls <---+
+
+
+
+Postel & Crocker                                               [Page 17]
+
+RFC 48                A Possible Protocol Plateau             April 1970
+
+
+       [ This RFC was put into machine readable form for entry ]
+   [ into the online RFC archives by Donald and Jill Eastlake 1999 ]
+
+[Editor's note: The original hand-drawn diagram represented
+Queues by cylinders and component programs by "squishy ameoba
+like things".]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Crocker                                               [Page 18]
+