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
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.
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.
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]