rfc54.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                               Steve Crocker (UCLA)
Request for Comments # 54                              Jon Postel (UCLA)
June 18, 1970                                     John Newkirk (Harvard)
                                                   Mike Kraley (Harvard)

                    An Official Protocol Proffering

I. INTRODUCTION

   As advertised in NEW/RFC #53, we are submitting the protocol herein
   for criticism, comments, etc.  We intend for this protocol to become
   the initial official protocol, and will, therefore, be happiest if no
   serious objections are raised.  Nevertheless, we will entertain all
   manner of criticism until July 13, 1970, and such criticism should be
   published as a NWG/RFC or directed to the first author.

   After July 13, a decision will be made whether to adopt this protocol
   (or slight variation) or whether to redesign it and resubmit it for
   criticism.

Only the Protocol

   In preceding discussions of protocol, no clear distinction has been
   made between the network-wide specifications and local strategies.
   We state here that the only network-wide issues are message formats
   and restrictions on message content.  Implementation of a Network
   Control Program (NCP) and choice of system calls are strictly local
   issues.

   This document is constrained to cover only network-wide issues and
   thus will not treat system calls or NCP tables; nevertheless, a
   protocol is useless without an NCP and a set of system calls, so we
   have expended a great deal of effort in deriving a protypical NCP.
   This effort is reported in NWG/RFC #55, and the reader should
   correlate the protocol presented here with the suggestions for using
   it presented there.  It is important to remember, however, that the
   content of NWG/RFC #55 is only suggestive and that competitive
   proposals should be examined before choosing an implementation.

Flow Control

   In the course of designing this current protocol, we have come to
   understand that flow control is more complex than we imagined.  We
   now believe that flow control techniques will be one of the active
   areas of concern as the network traffic increases.  We have,
   therefore, benefitted from some ideas stimulated by Richard Kaline
   and Anatol Holt and have modified the flow control procedure.
   (Defects in our scheme are, of course, only our fault).  This new



Crocker, Postel, Newkirk & Kraley                              [Page 1]

RFC 54              An Official Protocol Proffering        18 June 1970


   procedure has demonstrable limitations, but has the advantages that
   it is more cleanly implementable and will support initial network
   use.  This is the only substantive change from the protocol already
   agreed upon.

   The new flow control mechanism requires the receiving host to
   allocate buffer space for each connection and to notify the sending
   host of how much space in bits is available.  The sending host keeps
   track of how much room is available and never sends more text than it
   believes the receiving host can accept.

   To implement this mechanism, the sending host keeps a counter
   associated with each connection.  The counter is initialized to zero,
   increased by control commands sent from the receiving host, and
   decremented by the text length of any message sent over the
   connection.  The sending host is prohibited from sending text longer
   than the value of the counter, so the counter never goes below zero.

   Ideally, the receiving host will allocate some buffer space as soon
   as the connection is established.  The amount allocated must never
   exceed what the receiver can guarantee to accept.  As text arrives,
   it occupies the allocated buffer space.  When the receiving process
   absorbs the waiting text from the buffer, the NCP fires back a new
   allocation of space for that connection.  The NCP may allocate space
   even if the receiving process has not absorbed waiting text if it
   believes that extra buffer space is appropriate.  Similarly, the NCP
   may decide not to reallocate buffer space after the receiving process
   makes it available.

   The control command which allocates space is

                   ALL     <link>  <space>

   This command is sent only from the receiving host to the sending
   host.

   This formulation of flow control obviates the RSM and SPD commands in
   NWG/RFC #36, and the Host-to-Imp message type 10 and Imp-to-Host
   message types 10 and 11 in the current revision of BBN Report 1822.

   The obvious limitation in this scheme is that the receiving host is
   not permitted to depend upon average buffer usage -- worse case is
   always assumed.  If only a few connections are open, it is unlikely
   that there would be much savings.  However, for more than a few
   connections, average buffer usage will be much less than allocated
   buffer space.  We have looked at extensions of this protocol which
   would include adaptive allocation, and we believe this to be
   feasible.  For the present this limited scheme seems best, and we



Crocker, Postel, Newkirk & Kraley                              [Page 2]

RFC 54              An Official Protocol Proffering        18 June 1970


   look forward to discussing more sophisticated schemes later.  The old
   scheme of special RFNM's, etc. also remains under discussion.

   In order to answer questions and discuss details, we will hold a pair
   of network meetings.  The first will be on June 29 at Harvard and the
   second on July 1 at UCLA.  We request that no more than on programmer
   per host attend a meeting and that hosts be represented at only one
   of these meetings.  Two of us (J.N. and S.C.) will be at both
   meetings.

   To make reservations to attend the Harvard meeting, contact

   Mrs. Margi Robison
   [phone]
      or 495-3991

   To make reservations to attend the UCLA meeting, contact Mrs. Benita
   Kirstel [phone].

II. THE PROTOCOL

   The notion of a connection as explained in NWG/RFC #33 pervades the
   protocol.  A connection is a simplex communication path, intended to
   be between two processes.

   The primary function of the protocol is to provide for
       (1)  establishment of connections,
       (2)  regulation of flow over connections, and
       (3)  termination of connections.

   In addition, the protocol provides some ancillary functions such as
   sending simulated interrupt pulses and echoing test messages.

   To provide a path for exchanging information about connections, we
   designate specific links, i.e. link one between each pair of hosts to
   be control links.  Traffic on control links consists only of control
   commands, defined below.

   Connections are named by a pair of sockets.  Sockets are 40 bit names
   which are known throughout the network.  Each host is assigned a
   private subset of these names, and a command which requests a
   connection names one socket which is local to the requesting host and
   one local to the receiver of the request.

   Sockets are polarized; even numbered sockets are receive sockets; odd
   numbered ones are send sockets.  One of each is required to make a
   connection.




Crocker, Postel, Newkirk & Kraley                              [Page 3]

RFC 54              An Official Protocol Proffering        18 June 1970


   To facilitate transmission of information over a connection, a unique
   link is assigned to each connection.  One of the steps in
   establishing a connection, therefore, is the assignment of a link.
   Of the non-control links, zero is reserved for intra-network use, and
   links 32 to 255 are reserved for experiment and expansion.  Thus only
   links 2 through 31 are available for regular use.  Link assignment
   must either always be done by the receiver or always by the sender.
   We have (almost) arbitrarily chosen this to be the receiver's
   responsibility.

   All regular messages consist of a 32 bit leader, marking, text, and
   padding.  Marking is a (possibly null) sequence of zeroes followed by
   a 1; padding is a 1 followed by a (possibly null) sequence of zeroes.

   A regular message sent over the control link (link 1) is called a
   control message.  Its text is an integral (possibly zero) number of
   control commands in the form described below, and this text must end
   on a command boundary.

   The commands used to establish a connection are STR and RTS.  The STR
   command is sent from a prospective sender to a prospective receiver.
   Its <my socket> field contains a send socket local to the prospective
   sender; its <your socket> field contains a receive socket local to
   the prospective receiver.  The RTS command is the dual, but is also
   contains a <link> field for link assignment.  These two commands are
   referred to as requests-for-connection (RFC).  A STR and an RTS match
   if the <my socket> field of one is identical to the <your socket>
   field of the other and vice versa.  A connection is established where
   a matching pair of RFC's have been exchanged.

   Hosts are prohibited from establishing more than one connection to
   any local socket.  Therefore, a host may not use a socket for the <my
   socket>  field of an RFC if that socket is mentioned in a previous
   RFC and the connection is not yet terminated.

   The command used to terminate a connection is CLS.  Each side must
   send and receive a CLS command before a connection is completely
   terminated and the sockets are free to participate in other
   connections.  It is not necessary that both RFC's be exchanged before
   a connection is terminated.  More details on termination are given
   below.

   After a connection is established, the receiving host sends a ALL
   command which allocates space for the connection.  The sender keeps
   track of how much space is available in the receiving host and does
   not transmit more text than the receiving host can accept, as
   explained above.  A sender is also constrained by the local IMP from
   sending a message over a connection until  the RFNM from the previous



Crocker, Postel, Newkirk & Kraley                              [Page 4]

RFC 54              An Official Protocol Proffering        18 June 1970


   message is received.

   After a connection is established, CLS commands sent by the receiver
   and sender have slightly different effects.  CLS command sent by the
   sender indicate that no more messages will be sent over the
   connection.  This command must not be sent if there is a message in
   transit over the connection.

   CLS commands sent by the receiver act as demands on the sender to
   terminate transmission.  However, since there is a delay in getting
   the CLS command to the sender, the receiver must expect its buffers
   to fill to the limit provided in ALL commands.

   While a connection is established, either side may send INR or INS
   commands.  The interpretation of these commands is a local matter,
   but in general they will provide and escape function.

   Note that the ALL, INR and INS commands may be sent only after the
   connection is established and before a CLS command is sent.

   A very simple test facility is provided by the ECO and ERP commands.
   Upon receiving a ECO command, a host must change the first eight bits
   to ERP and return it.  These commands have no relationship to
   connections.