|
Network Working Group Request for Comments: 46 |
Edwin E. Meyer, Jr. Massachusetts Institute of Technology 17 April 1970 |
The attached document contains comments and suggestions of the Network Working Group at Project MAC. It is based upon the protocol outlined in NWG/RFC 33, 36, and later documents.
This proposal is intended as a contribution to the dialog leading to a protocol specification to be accepted by the entire Network Working Group.
We solicit your comments.
In this document the Network Working Group at MIT Project MAC suggest modifications and extensions to the protocol specified by Carr, Crocker, and Cerf in a preprint of their 1970 SJCC paper and extended by Crocker in NWG/RFC 36. This document broadly outlines our proposal but does not attempt to be a complete specification. It is intended to be an indication of the type and extent of the protocol we think should be initially implemented.
We agree with the basic concept of simplex communication between sockets having unique identifiers. We propose the implementation of a slightly modified subset of the network commands specified in NWG/RFC36 plus the ERR command as specified by Harslem and Heafner in NWG/RFC 40.
Given the basic objective of getting all ARPA contractors onto the network and talking to each other at the earliest possible date, we think that it is important to implement an initial protocol that is reasonably simple yet extendable while providing for the major initial uses of the network. It should be a simple protocol so as to elicit the broadest possible support and to be easily implementable at all installations with a minimum of added software.
While the protocol will evolve, the fundamentals of a protocol accepted and implemented by all installations are likely to prove very resistant to change. Thus it is very important to make the initial protocol open-ended and flexible. A simple basic protocol is more likely to succeed in this respect than a complicated one. This
[Page 1]
We feel that three facilities must be provided for in the initial protocol:
The major differences between the protocol as proposed by Carr, Crocker, and Cerf and this proposal are the following:
[Page 2]
It seems convenient and useful to view the network as consisting of a hierarchy of protocol and implementation levels. In addition to aiding independent software and hardware development, provisions for a layered protocol allow additions and substitution of certain levels in experimental or special purpose systems.
We view the initial network communications system as a hierarchy of three systems of increasing generality and decreasing privilege level. These are:
[Page 3]
H O S T A H O S T C
______________________________ ______________________
| | | |
| ____ ____ ____ ____ | | ____ ____ ____ |
| |Proc| |Proc| |Proc| | | | | |Proc| |Proc| | | |
| | A | | B | | C | |UCC | | | | D | | E | |UCC | |
| |____| |____| |____| |____| | | |____| |____| |____| |
| | | | | | | | | | |
- - - - - - |- - - |- - - |- - -|- - -|- - |- - -|- - - |- - - - - -
| | | | | NCP NETWORK | | | |
| | | | | | | | | | |
| _|_____|______|______|_ | | _|_____|______|_ |
| | | | | | | |
| | N C P A | | | | N C P C | |
| |_______________________| | | |________________| |
| || | | || |
|_____________________||_______| |_______||_____________|
|| ||
- - - - - - - - - - - -|| - - - - - - - - - - ||- - - - - - - - - -
|| IMP NETWORK ||
___||___ ____||__
| | | |
| IMP |------------| IMP |
| A | | C |
|________| |________|
| |
| ________ |
| | | |
+------| IMP |-----+
| B |
|________|
FIG 1. Modular View Of Network
[Page 4]
Each HOST implements a module called the Network Control Program (NCP) which controls all network communications involving that HOST. The network of NCPs forms a distributed communication system that implements communication paths between individual processes. The NCP protocol issues involve: (i) the definition of these communication paths, and (ii) a system for coordinating the distributed NCP system in maintaining these communication paths. These are discussed below.
Sockets
Communication between two processes is made through a simplex connection between two sockets: a send socket attached to one process and a receive socket attached to another process. Sockets have the following characteristics:
Socket Identifier - A socket identifier is used throughout the network to uniquely identify a socket. It consists of 48 bits, having the following components:
network receives instance tag = 0 by convention.
[Page 5]
Socket Event Queue - A queue of events to be disclosed to the owning process is maintained for each open or connected socket. It consists of a chronologically ordered list of certain events generated by the action of one or more foreign processes trying to connect or disconnect this socket. An entry in the event queue consists of the event type plus the identifier of the foreign socket concerned. The following event types are defined:
A "request" event is removed from the queue when it is accepted or rejected. The other events are removed from the queue as they are disclosed to the owning process.
Some events are intended to be transparent to the process owning the socket, and they do not generate entries in the event queue.
Although an event queue is conceptually unlimited, it seems necessary to place some practical limit on its length. When an event queue for a socket is full, any incoming event that would add to the queue should be discarded and the sending NCP notified (via ERR command described below).
[Page 6]
The NCP network coordinates its activities through control commands passed between its individual components. These commands generally concern the creation and manipulation of socket connections controlled by the NCP receiving the command. A control command is directed to a particular NCP by being sent to its HOST as a message over link number 1 (designated as the control link), which is reserved for that purpose. The IMP network does not distinguish between these messages and regular data messages implementing communication through a socket connection.
The following NCP control commands are defined:
RFC <local socket> <foreign socket> [<link no.>]
An NCP directs this command to a foreign NCP to attempt to initiate a connection between a local socket and a foreign socket. If the foreign socket is open, the foreign NCP places a "request" event into the socket's event queue for disclosure to the process that owns it. If the foreign process accepts, the foreign NCP returns a positive acknowledgement in the form of another RFC. It rejects connection by issuing the CLS command (see below). An RFC is automatically rejected without consulting the owning process if the foreign socket is not open (inactive or connected). Multiple RFCs to the same socket are placed into its event queue in order of receipt. Any queued RFCs are automatically rejected by the NCP once the owning process decides to accept a connection. The NCP which has control of the "receive" socket of the potentially connected pair designates a link number over which messages are to flow.
CLS <local socket> <foreign socket>
An NCP issues this network command to disconnect an existing connection or to negatively acknowledge an RFC. There is a potential race problem if an NCP closes a local send socket in that the CLS command may reach the foreign NCP prior to the last message over that socket connection. This race is prevented by adhering to two standards: (i) A CLS command for a local send socket is not transmitted until the RFNM for the last message to the foreign socket comes back, and (ii) the foreign NCP processes all incoming messages in the order received.
[Page 7]
BLK <foreign send socket>
A process may read data through a receive socket slower than messages are coming in and thus the NCP's buffers may tend to clog up. The NCP issues this command to a foreign NCP to block further transmission over the socket pair until the receiving process catches up.
RSM <foreign send socket>
An NCP issues this command to unblock a previously blocked connection.
INT <foreign socket>
Receipt of this message causes the foreign NCP to immediately interrupt the foreign process attached to <foreign socket> if it is connected to a local socket. Data already in transit within the NCP network over the interrupted connection will be transmitted to the destination socket. The meaning of "interrupt" is that the process will immediately break off its current execution and execute some standard procedure. That procedure is not defined at this protocol level.
ERR <code> <command length> <command in error>
This command is used to report spurious network commands or messages, or overload conditions that prevent processing of the command. <code> specifies the error type. If <code> specifies an erroneous network command, <command in error> is that command (not including IMP header) and <command length> is an integer specifying its length in bits. If <code> specifies an erroneous message, <command in error> contains only the link number over which the erroneous message was transmitted. (This is slightly modified from the specification in NWG/RFC 40.)
[Page 8]
ECO <48 bit code> <echo switch>
An NCP may test the quality of communications between it and a foreign NCP by directing to it an ECO command with an arbitrary
<48 bit code> (of the same length as a socket identifier) and
<echo switch> 'on'. An NCP receiving such a ECO command should
immediately send an acknowledging ECO with the same <48 bit code>
and <echo switch> 'off' to the originating NCP. An NCP does not
acknowledge an ECO with <echo switch> 'off'. We feel that this
command will be of considerable aid in the initial shakedown of
the entire network.
NOP
An NCP discards this command upon receipt.
The NCP at each HOST has an interface through which a local process can exercise the network, subject to the control of the NCP. The exact specification of this interface is not a network protocol issue, since each installation will have its own interface keyed to its particular requirements. The protocol requirements for the user interface to an NCP are that it provide all intended network functions and no illegal privileges. Examples of such illegal privileges include the ability to masquerade as another process, eavesdrop on communications not intended for it, or to induce the NCP to send out spurious network commands or messages.
We outline here an interface based on the Carr, Crocker, and Cerf proposal that is sufficient to fully utilize the network. While this particular set of calls is intended mainly for illustrative purposes, it indicates the types of functions necessary.
The following calls to the NCP are available:
A user opens this socket, creating an empty event queue for it. This LISTEN call may block waiting for the first "request" event, or it may return immediately.
[Page 9]
A user attempts to connect <my socket> to <foreign socket>. The local NCP sends an RFC to the foreign NCP requesting that the connection be created. The returned acknowledgemnet is either an RFC (request accepted) or CLS (request rejected). At the caller's option, the INIT call blocks on the expected "accept" or "reject" event, or it can return immediately without waiting. In this case the user must call STATUS (see below) at a later time to determine the action by the foreign NCP. When a blocked INIT call returns, the "accept" or "reject" event is removed from the event queue.
This call reports out the earliest previously unreported event in the queue of <my socket>. The STATUS call deletes the event from the queue if that type of event is deleteable by disclosure.
The user accepts connection with the foreign socket whose "request" event is earliest in the event queue for <my socket>. An acknowledging RFC is sent to the accepted foreign socket, and the "request" event is deleted from the event queue. Should any other "request" event exist in the queue, the NCP automatically denies connection by sending out a CLS command and deleting the event.
The user rejects connection with the foreign socket whose "request" event is earliest in the event queue for <my socket>. The NCP sends out a CLS command and deletes the "request" event from the queue.
The user directs the NCP to disconnect any active connection to this socket and to deactivate the socket. The NCP sends out a CLS command to the foreign socket if a connection has existed. The status of the foreign socket also becomes closed once the "close" event is disclosed to the foreign process.
The user directs the NCP to send out an INT command to the foreign socket connected to <my socket>.
[Page 10]
The user wishes to read (<my socket> is receive) or write (<my socket> is send) <nbits> of data into or out of an area pointed to by <pointer>. A call to write returns immediately after the NCP has queued the data to send a message over the connection. The call to write blocks only if the connection is blocked or if the local NCP is too loaded to process the request immediately. Data to be transmitted over a connection is formatted into one or more IMP messages of maximum length 8095 bits and transmitted to the foreign HOST over the link number specified in the RFC sent by the NCP controlling the receiving connection. A "close" event in the event queue for <my socket> is disclosed through the action of TRANSMIT. A call to write discloses the "close" event immediately. A read call discloses it when all data has been read.
Assume that process 'a' on HOST A wishes to establish connection with process 'b' on HOST B. Before communication can take place, two conditions must be fulfilled:
an RFC specifying link number = 47, which it chooses from its
available set of links. This is the link over which it will
receive messages if the connection is ACCEPTed by process 'b'.
[Page 11]
HOST A | HOST B
INITIATOR | ACCEPTOR
PROCESS 'a' | PROCESS 'b'
|
|
| a. LISTEN 'socket code 9'
|
|
b. INIT 'socket code 12' 'Bb9' |
RFC 'AA12' 'Bb9' 'link 47' ==========>
|
| c. ACCEPT 'socket code 9'
| RFC 'Bb9' 'Aa12'
|
| d. TRANSMIT 'send buffer' 'len'
| 'socket 9'
<============== IMP message 'link 47' 'send buffer'
|
e. TRANSMIT 'rec buffer' 'length'
'socket 12' ============>
|
| f. CLOSE 'socket code 9'
|
last RFNM ===>
<============== CLS 'Bb9' 'Aa12'
closes socket 'Aa12' |
|
FIG 2. Establishing and Communicating over a Socket Connection
to NCP A with link number = 47 as specified by A's RFC.
[Page 12]
[Page 13]
Some process must exist which agrees to listen to anybody in the network and create a process for him upon proper identification. This process is called the logger and interacts through the NCP via the network-related User Control and Communication (UCC) module, which implements the necessary protocol. Except for one instance (CLOSEing connections of dead processes), the process operating the UCC module does not have special network privileges.
Under the UCC protocol a "requestor" process which has directed the creation of a "foreign" process maintains two full-duplex pseudo- typewriter connections: one to the foreign logger, and one to the created process. The duplex connection to the foreign logger is used to identify the requestor process to the logger, and after login to return to the requestor process basic information concerning the health of the created process. The duplex connection to the created process is used for control communication to it.
Maintaining two full-duplex connections avoids reconnection problems
both when the logger transfers communication to the created process
and when it needs to regain control. This is at the modest expense
of requiring the requestor process to switch typewriter
communications between two sets of connections.
The way that communication is established is essentially as follows: the requestor process first reserves four of its sockets having contiguous socket codes. Then it "signals" the UCC, specifying one of these sockets. From the "signal" the UCC knows which process is calling, and by protocol, on which requestor socket pair the UCC is to communicate with the requestor process, and which requestor socket pair the created process is to use for its communications. This is specified below in more detail.
The UCC at each HOST always keeps a send socket with user number = 0, instance tag = 0 open (active and unconnected) as a "signal" socket, and periodically checks for INITs to this socket. Processes wishing to create a process at this HOST must first signal the UCC by issuing an INIT to this socket.
[Page 14]
<base_socket+2> and <base_socket+3> receive/send pair over which it will talk to the foreign UCC. Then it sends out a "signalling" INIT call on <base_socket> to the UCC "signal" socket. The only thing that the UCC does with this "signalling" INIT call is to note down the socket number <base_socket> from which it originated. The UCC immediately rejects this request so as to keep its "signal" socket open for other signals.
<base_socket> and <base_socket+1>. (The created process will INIT these sockets to establish control communication with the requestor process.) The requestor process then blocks by calling STATUS <base_socket+2> .
<base_socket+2> and <base_socket+3> on which the requestor process is presumably LISTENing. The requestor process has called STATUS <base_socket+2> with block option after LISTENing for the two sockets, so that when the INIT from the foreign UCC reaches the requestor process, STATUS returns with the INIT indication. The requestor process verifies that the UCC is the process that is calling, then it ACCEPTs the call. The requestor process then calls STATUS <base_socket+3> and returns when the INIT for that socket reaches it. It does a similar verify and ACCEPT. (There is an arbitrary choice as for which socket the requestor process first calls STATUS.) Two way communication is established when the requestor process has ACCEPTed both INITs from the UCC. This connection is maintained during the login ritual and throughout the life of the created process. Should the requestor process fail to respond properly within a limited amount of time to the INITs of the UCC, the UCC abandons the connection attempt.
[Page 15]
This document was prepared through the use of the MULTICS "runoff" command. A source file consisting of intermixed text and "runoff" requests was created using the "qed" text editor. This file was then compiled by the "runoff" command to produce a finished copy. The latest version of this document exists online in MULTICS in the segment
>udd>Multics>Meyer>network_protocol.runoff
(END)
[Page 16]
REQUESTOR FOREIGN
PROCESS LOGGER
-------------- -------------
a. LISTEN to sockets
<base_socket+2> and
<base_socket+3> to be
connected to foreign logger.
=======================================>
d. LISTEN to sockets e. INIT a logger socket
<base_socket> and pair to the requestor's
<base_socket_1> to be <base_socket+2> and
connected to the created process. <base_socket+3>.
/
<==========================/
PERFORM LOGIN RITUAL
CREATED
PROCESS
-------------
g. INIT any socket pair
to requestor's
<base_socket> and
<base_socket+1>
/
<===========================/
h. ACCEPT connection
with sockets from created
process.
FIG. 4 Establishing a Process at a Foreign HOST
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Miles McCredie 11/99 ]
[Page 17]