GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc54

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
 (617) 495-3989
    or 495-3991
 To make reservations to attend the UCLA meeting, contact Mrs. Benita
 Kirstel (213) 825-2368.

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.
 A NOP command is included for convenience.  It is coded as zero to
 facilitate command message construction.
 Finally, an ERR command is included for notifying a foreign host it
 has (apparently) made an error.  At present, no specific list of
 errors is defined, and no action is defined for the receipt of ERR
 commands.  Hosts should log ERR commands upon receipt so that system
 programmers can diagnose the trouble.  A host may generate an ERR
 command at any time and for any reason, but it is advised that each
 host publish an exhaustive list of the ERR commands it may sent and
 their interpretations.

NETWORK CONTROL COMMANDS

 The following is a detailed description of the structure and format
 of each of the control commands.
 To facilitate and clarify socket descriptions, the following
 conventions have been adopted:
 <my socket> and <your socket> are used in the command descriptions.

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

 <my socket> is local to the originator of the command.
 <your socket> is local to the receiver of the command.

CONTROL COMMAND FORMATS

 No Operation
                    _______
                   |       |
                   |  NOP  |
                   |_______|
 Request Connection, Receiver to Sender
                    ______________________________________________
                   |       |             |               |        |
                   |  RTS  |  my socket  |  your socket  |  link  |
                   |_______|_____________|_______________|________|
 Request Connection, Sender to Receiver
                    _____________________________________
                   |       |             |               |
                   |  STR  |  my socket  |  your socket  |
                   |_______|_____________|_______________|
 Close
                    _____________________________________
                   |       |             |               |
                   |  CLS  |  my socket  |  your socket  |
                   |_______|_____________|_______________|
 Allocate
                    __________________________
                   |       |        |         |
                   |  ALL  |  link  |  space  |
                   |_______|________|_________|
 Interrupt Sent by Receiving Process
                    _______________
                   |      |        |
                   | INR  |  link  |
                   |______|________|

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

 Interrupt Sent by Sending Process
                   _______________
                  |      |        |
                  | INS  |  link  |
                  |______|________|
 Echo Request
                   ____________________________   _________
                  |       |                    \  \        |
                  |  ECO  |  length            /  /  text  |
                  |_______|____________________\  \________|
 Echo Reply
                   ____________________________   _________
                  |       |                    \  \        |
                  |  ERP  |  length            /  /  text  |
                  |_______|____________________\  \________|
 Error Detected
                   ____________________________   _________
                  |       |                    \  \        |
                  |  ERR  |  length            /  /  text  |
                  |_______|____________________\  \________|
 The host is specified in the leader.
 <link> is 8 bits
 <space> is 32 bits long and is an unsigned integer.
 <length> is an unsigned 16 bit integer.
 <text> is as long as the length.  The command is therefore 24 bits
 longer that the length.  Maximum length is one message, to facilitate
 command decoding and manipulation.
 All control command codes are 8 bit long:
           NOP = 0
           RTS = 1
           STR = 2
           CLS = 3
           ALL = 4
           INR = 5

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

           INS = 6
           ECO = 7
           ERP = 8
           ERR = 9
 <my socket> and <your socket> are 32 bits long,
                   _______________________
                  |               |       |
                  |  User number  |  AEN  |
                  |_______________|_______|
 24 bits for user number and 8 bits for AEN.

III. Conclusion

 Extensions to the Protocol
 Some issues have not been adequately treated in the current protocol.
 We have in mind the following topics to consider more thoroughly and
 perhaps experiment with.
 1. More Sophisticated Flow Control.
 As mentioned above, other schemes for flow control are still being
 considered.  Other than the necessity of providing some form of it,
 we are completely unsure of the nature of the problem.  It may turn
 out that the present scheme is completely adequate; it may also turn
 out that we will need a much more complex scheme.
 2. Error Detection and Recovery
 As we gain some experience with the network, we will develop a better
 understanding of what errors can occur and, perhaps more importantly,
 what to do about these errors.  We expect the protocol to change as
 we understand error control.
 3. Start Up and Shut Down Procedures
 We have not done enough thinking about the problem of the host which
 participates part-time in the network, which ceases normal network
 operation but remains on the network for special purposes, or which
 recovers from a system failure.  These issues are critical to robust
 network operation and are possibly our highest priority.  4. Query
 and Response
 A host-to-host status test would be a valuable tool, but it is not
 yet clear what is appropriate to provide.

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

Coming onto the Network

 We suggest that hosts come onto the network gingerly.  First, each
 host should thoroughly exercise connections to itself.  Then it
 should arrange experiments with some other host who is already
 functioning.  Finally, it may begin to exercise the facilities of
 other hosts.  It is not clear at this time which host will be in the
 best position to help other hosts first, but UCLA will attempt to
 serve this function.

Private Networking

 A common ploy is to use the IMP to connect several local computers,
 one or more of which is not available to the whole network.  For
 example, Harvard is connecting its PDP-1 to its PDP-10 via an IMP;
 Lincoln Laboratories is connecting its TSP to the 360/67 and the TX2
 via an IMP; and UCLA is similarly connecting a XDS 920 to its Sigma-
 7.  In each of these cases, the small machine will not initially
 provide services to the network.
 Although there should be no unwanted traffic to any of these extra
 hosts, it is desirable that they conform minimally to the network
 protocol.  Provided that they never initiate a connection or send out
 spurious control commands, it is sufficient for a host to respond to
 CLS commands with acknowledging CLS commands, and to respond to ECO
 commands with ERP commands.

Acknowledgments

 The work presented above is only a small portion of the concurrent
 effort.  Most of the related effort will be reported in immediately
 forthcoming RFC's.  A number of people provided extremely valuable
 aid during the last two weeks.  We are particularly grateful to
 Professor George Mealy of Harvard for supporting four of his students
 to come westward to work on the network, to Robert Uzgalis for
 facilitating access to CCN at UCLA, and to the secretarial staff of
 the Computer Science Division of the University of Utah, and
 especially Peggy Tueller and Marcella Sanchez, for excellent help in
 preparing these documents.
     [ This RFC was put into machine readable form for entry ]
    [ into the online RFC archives by Eitetsu Baumgardner 3/97 ]

Crocker, Postel, Newkirk & Kraley [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc54.txt · Last modified: 1997/03/13 15:48 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki