summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc36.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc36.txt')
-rw-r--r--doc/rfc/rfc36.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc36.txt b/doc/rfc/rfc36.txt
new file mode 100644
index 0000000..b668e5e
--- /dev/null
+++ b/doc/rfc/rfc36.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group S. Crocker
+Request for Comments: 36 16 March 1970
+
+
+ Protocol Notes
+
+I Overview
+ --------
+
+ The network protocol provides three facilities:
+
+ 1. Connection establishment
+
+ 2. Flow control
+
+ 3. Reconnection
+
+ Reconnection is considered separately from connection establishment
+ partly because of the complexity of reconnection and partly because I
+ don't have enough experience with the protocol to present these
+ concepts in an integrated fashion.
+
+ Connection Establishment
+ ------------------------
+
+ Connection establishment works essentially the same as in NWG/RFC
+ #33. The major change is that a more general form of switching is
+ provided independently of establishment, so establishment is
+ simplified by not including switching procedures.
+
+ A rough scenario for connection establishment follows:
+
+ 1. Process PA in host A grabs socket SA and requests connection with
+ socket SB. Process PA accomplishes this through a system call.
+
+ 2. Concurrently with the above, process PB in host B grabs socket SB
+ and requests connection with socket SA.
+
+ 3. In response to process PA's request, the network control program
+ in host A (referred to as NCPA) sends a Request-for-Connection
+ (RFC) command to host B. NCPB in host B sends a similar command
+ to host A. No ordering is implied: NCPB may send the command to
+ NCPA before or after receiving the command from NCPA.
+
+ 4. NCPA and NCPB are both aware the connection is established when
+ each has received a RFC command and each has received the RFNM
+ for the one it has sent. They then notify processes PA and PB,
+ respectively, that the connection is established.
+
+
+
+Crocker [Page 1]
+
+RFC 36 Protocol Notes March 1970
+
+
+ One of the rules adhered to is that either SA is a send socket and SB
+ is a receive socket or vice versa. This condition is sometimes
+ stated as "SA and SB must be a send/receive pair."
+
+ 5. The sending process may now send.
+
+ Flow Control
+ ------------
+
+ In order to prevent a sending process from flooding a receiving
+ processes it is necessary for the receiving process to be able to
+ stop the flow(*). Flow control is integrated into the network RFNM
+ handling. When a receiving host wishes to inhibit flow on a
+ particular link, the host sends a special message to its IMP which
+ causes the next RFNM on that link to be modified. The sending host
+ interprets this message as a RFNM and as a request to stop sending.
+ A confirming control command is returned.
+
+ When the receiving host is ready to receive again, it sends a command
+ (RSM) telling the sending host to resume sending.
+
+ Reconnection
+ ------------
+
+ For a great many reasons it is desirable to be able to switch one (or
+ both) ends of a connection from one socket to another. Depending
+ upon the restrictions placed upon the switching process, it may be
+ easy or hard to implement. To achieve maximum generality, I present
+ here a scheme for dynamic reconnection, which means that reconnection
+ can take place even after flow has started. It may turn out that for
+ the majority of cases, this scheme is much more expensive than it
+ needs to be; however, the following virtues are claimed:
+
+ 1. All various forms of switching connections are provided.
+
+ 2. Reconnection introduces no overhead in the processing of
+ messages sent over a connection i.e., the whole cost is borne
+ in processing the protocol.
+
+ ---------------------------------------------------
+ *BB&N argues that unlimited buffering should be provided. It is
+ possible that this would be a proper strategy: but it is foreign to
+ my way of thinking, and I have based the protocol design on the
+ assumption that only a small buffer is provided on the receive end of
+ each connection.
+
+
+
+
+
+
+Crocker [Page 2]
+
+RFC 36 Protocol Notes March 1970
+
+
+II Data Structures
+ ---------------
+
+ 1. Connection Table
+ 2. Process Table
+ 3. Input Link Table
+ 4. Output Link Table
+ 5. Link Assignment Table
+
+ Connection Table
+ ----------------
+
+ This holds all information pertaining to local sockets, particularly
+ whether a socket is engaged in a connection, and if so, what state
+ the connection is in. Entries are keyed by local socket, but other
+ tables have pointers into this table also. (See the Process Table,
+ Input Link Table, and Output Link Table.)
+
+ Each entry contains the following information:
+
+ a) local socket (key)
+ b) foreign socket
+ c) link
+ d) connection state
+ e) flow state and buffer control
+ f) pointer to user's process
+ g) reconnection control state
+ h) queue of waiting callers
+
+ The local socket is a 32 bit number. If no entry exists for a
+ particular socket, it may be created with null values.
+
+ The foreign socket is a 40 bit number. This field will be unassigned
+ if no connection is established.
+
+ The link is an 8 bit number and is the link over which data is sent
+ from the sender to the receiver. A socket is a receive socket iff
+ its low-order bit is zero.
+
+ Connection state refers to whether a connection is open or not, etc.
+ The following possibilities may occur.
+
+ a) local process has requested a connection
+ b) foreign process(es) has/have requested a connection
+ c) connection established
+ d) reconnection in progress
+ e) close waiting
+ f) reconnection waiting
+
+
+
+Crocker [Page 3]
+
+RFC 36 Protocol Notes March 1970
+
+
+ Flow state and buffer control refer to checking for RFNM's sending
+ and accepting cease, suspend and resume commands, and keeping track
+ of incoming or outgoing data.
+
+ A pointer to the user's process is necessary if the process has
+ requested a connection.
+
+ If reconnection is in progress, it is necessary to keep track of the
+ sequence of events. A socket engaged in reconnection is either an
+ end or a middle. If it's a middle, it is necessary to store the
+ eight bit name of the other middle attached to the same process, and
+ to record receipt of END and RDY commands.
+
+ Finally, if RFC's are received either when the socket is busy or when
+ no process has engaged it, the RFC's are stacked first-in-first-out
+ on a queue for the named local socket.
+
+ Process Table
+ -------------
+
+ This table associates a process with a socket. It is used to process
+ system calls.
+
+ Input Link Table
+ ----------------
+
+ This table associates receive links with local sockets. It is used
+ to decide for whom incoming messages are destined.
+
+ Output Link Table
+ -----------------
+
+ This table associates send links with local sockets. It is used to
+ interpret RFNM's and RSM commands.
+
+ Link Assignment Table
+ ---------------------
+
+ Links are assigned by receivers. This table shows which links are
+ free.
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 4]
+
+RFC 36 Protocol Notes March 1970
+
+
+III Control Commands
+ ----------------
+
+ Command Summary
+
+
+
+ 0 <NOP>
+ 1 <RFC> <me> <you> or <RFC> <me> <you> <link>
+ 2 <CLS> <me> <you>
+ 3 <RSM> <link>
+ 4 <SPD> <link>
+ 5 <FND> <me> <you> <asker>
+ 6 <END> <link> <end>
+ 7 <RDY> <link>
+ 8 <ASG> <me> <you> <link>
+
+
+ Commands
+No Operation
+
+ Form: NOP
+ NOP is X'00'
+
+ Purpose: This command is included for completeness and
+ convenience.
+
+Request for connection
+
+ Form: <RFC> <my socket> <your socket>
+ or <RFC> <my socket> <your socket> <link>
+ <RFC> is X'01'
+ <my socket> is a 32 bit socket number local to the
+ sender
+ <your socket> is a 32 bit socket number local to the
+ receiver
+ <link> is an eight bit link number.
+ <my socket> and your socket must be a send/receive pair.
+ <link> is included if and only if <my socket> is a
+ receive socket
+
+ Purpose: This command is used to initiate a connection. When
+ two hosts have exchanged RFC commands with the same
+ arguments (reversed), the connection is established.
+ Links are assigned by the receiver.
+
+
+
+
+
+
+Crocker [Page 5]
+
+RFC 36 Protocol Notes March 1970
+
+
+Close
+
+ Form: <CLS> <my socket> <your socket>
+ <CLS> is X'02'
+ <my socket> and <your socket> are the same as for <RFC>
+
+ Purpose: This command is used to block a connection. It may
+ also be used to abort the establishment of a connection
+ or to refuse a request. It may happen that no
+ connection between the named sockets was established,
+ or was in the process of being established. In this
+ event, the <CLS> should be discarded.
+
+Resume
+
+ Form: <RSM> <link>
+ <RSM> is X'03'
+
+ Purpose: This command is sent by a receiving host to cause the
+ sending host to resume transmission on the named link.
+ A sending host suspends sending if it receives a
+ special RFNM for some message. (Special RFNM's are
+ generated by the receiving IMP upon request by its
+ host.)
+
+Suspended
+
+ Form: <SPD> <link>
+ <SPD> is X'04'
+
+ Purpose: This command is sent by a sending host to acknowledge
+ that it has stopped sending over the named link.
+ Transmission will resume if a <RSM> command is
+ received.
+
+Final End
+
+ Form: <FND> <my socket> <your socket> <asker>
+ <FND> is X'05'
+ <my socket> is a 32 bit socket number of a socket local
+ to the sender
+ <your socket> is a 32 bit socket number of a socket
+ local to the receiver
+ <my socket> and <your socket> form a send/receive pair.
+ A connection should be established between them.
+ <asker> is a 40 bit socket number of the same type as
+ <my socket>
+
+
+
+
+Crocker [Page 6]
+
+RFC 36 Protocol Notes March 1970
+
+
+ Purpose: If a process decides to short-circuit itself by connecting
+ one of its receive sockets to one of its send sockets, the
+ NCP sends out two <FND> commands -- one in each direction.
+ Each one has <asker> initialized to <my socket>.
+
+ Upon receiving an <FND> command, the NCP checks its <your
+ socket>. If <your socket> is already engaged in a
+ reconnection, the command is passed on with a new <my
+ socket> and <your socket>. However, before it is passed
+ on, the <asker> is compared with the new <my socket>. If
+ they are equal, a loop has been detected and both sockets
+ are closed.
+
+ If <your socket> is not engaged in a reconnection, it is
+ marked as the end of a chain of reconnections and an <END>
+ is sent back.
+
+ If the connection named is not in progress, a <CLS> is sent
+ back and the <FND> is discarded.
+
+End Found
+
+ Form: <END> <link> <end socket>
+
+ <END> is X'06'
+ <link> is an 8 bit link
+
+ <end socket> is a 40 bit socket
+
+ Purpose: This command indicates which socket is at the end of a
+ chain of reconnections. It is generated at <end
+ socket> and passed back to the other terminal socket
+ via all the intermediate sockets. If <end socket> is a
+ send socket, <link> refers to a connection with the
+ send socket in the sending host and the receive socket
+ in the receiving host. If <end socket> is a receive
+ socket, <link> refers to a connection with the send
+ socket in the receiving host and the receive socket in
+ the sending hose. ("sending" end "receiving" refer to
+ the transmission of this control command.)
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 7]
+
+RFC 36 Protocol Notes March 1970
+
+
+Ready
+
+ Form: <RDY> <link>
+
+ <RDY> is X'07'
+ <link> is an 8 bit link number
+
+ Purpose: This command is sent from a send socket to a receive
+ socket to indicate that all messages have been
+ forwarded and that reconnection may occur.
+
+Assign New Link
+
+ Form: <ASG> <my socket> <your socket> <link>
+
+ <ASG> is X'08'
+
+ Purpose: This command completes a reconnection. It is sent from
+ a receive socket to a send socket after the receive
+ socket has received a <RDY>. A new link is assigned
+ and transmission commences.
+
+ [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Marc Blanchett 3/00 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 8]
+