A Simplified NCP Protocol
RFC 60

Document Type RFC - Unknown (July 1970; No errata)
Last updated 2015-02-14
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 60 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           R. Kalin
Request for Comments: 60                                             MIT
                                                            13 July 1970

                       A Simplified NCP Protocol

Abstract

   This RFC defines a new NCP protocol that is simple enough to be
   implemented on a very small computer, yet can be extended for
   efficient operation on large timesharing machines. Because worst case
   storage requirements can be predicted, a conservative implementation
   can be freed of complicated resource allocation and storage control
   procedures. A general error recovery procedure is also defined.

Overview and Rational

   The central premise of this proposal is an insistence that all user-
   to-user connections be bi-directional. For those familiar with
   communication theory, this appears most reasonable. All communication
   requires a cyclical flow of information. To deny a simple association
   between a message and its reply makes protocol unnecessarily
   complicated and turns simple mechanisms of flow control into
   nightmares.

   It is proposed that a bi-directional connection, or duplex link, be
   identified by a pair of socket numbers, one for each end. This is
   half the number presently required. Associated with the connection
   are some number of "crates" or message containers. These crates
   travel back and forth over the link carrying network messages from
   one side to the other. Buffers are allocated at each end of the link
   to hold crates and the messages that they carry. Worst case buffer
   requirements are equal to the number of crates in circulation, or the
   "capacity" of the link.

Details

   A message buffer has four states which follow one another cyclically.
   They are:

   1) empty,

   2) filled with a message-laden crate to be unloaded,

   3) filled with an empty crate, and

   4) filled with a message-laden crate to be sent.

Kalin                                                           [Page 1]
RFC 60                  A Simplified NCP Protocol           13 July 1970

   Normally state transitions correspond to message arrival, message
   removal, message insertion and message transmission.

   For a process to be an NCP it must:

   1) be able to make initial contact with foreign hosts via the control
   link and, if necessary, delete user-to-user links left over from the
   previous system incarnation.

   2) be able to create user-to-user links.

   3) be able to interface users with these links.

   4) be able to delete user-to-user links.

   The first of the four functions shall not be discussed here except to
   point out that it contains critical races that can not be resolved
   without making assumptions about maximum message propagation delays.
   Since within the ARPA network, bounds on message turnaround time do
   not exist, the approach chosen must necessarily be tender. The other
   three functions are discussed first from the viewpoint of one
   interested in implementing a minimal NCP. Then extensions and
   improvements are proposed that are suitable for larger machines.

   Any NCP must be capable of creating a duplex link between a local
   user process and a remote one. The current protocol accomplishes this
   by queuing a potentially unbounded number of RFC's and waiting for
   the user to examine the queue to determine with whom he wishes to
   talk.  There is no guarantee that the user will ever look at the
   queue and there is no way to limit the size of the queue. The
   overflow error message suggested fails in the respect because it
   admits that the RFC will only be sent again. The picture need not be
   this bleak. The following network conversation demonstrates how
   connections can be made without using queues or relying on user
   process attention.

   Suppose that a local user process and a remote user process wish to
   establish a new connection. The remote process asks its NCP to listen
   for a connection request and gives it the socket identifier for its
   end. Optionally it can give both socket identifiers. The user process
   at the local end asks its NCP to send a request for a duplex link
   (RFDL). It specifies both socket identifiers of the proposed link.
   The local NCP sends a RFDL over the control link with the following
   format:

   RFDL <my socket> <your socket> <max number buffers> <spare>

Kalin                                                           [Page 2]
RFC 60                  A Simplified NCP Protocol           13 July 1970

   The third argument is normally supplied by the local NCP and
   indicates the maximum number of buffers the NCP will consider
   allocating to this duplex link. If buffers are in user storage the
   count may be given by the user in a call made to the NCP.

   The RFDL is received at the remote host and the remote NCP compares
   <my socket> and <your socket> against the socket identifiers supplied
Show full document text