Note on Reconnection Protocol
RFC 671

Document Type RFC - Unknown (December 1974; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 671 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                    Richard Schantz
RFC # 671                                                      BBN-TENEX
NIC # 31439                                             December 6, 1974

                    A Note on Reconnection Protocol

INTRODUCTION

   This note documents the experience we have had in implementing a
   modified, experimental version of the Telnet reconnection protocol
   option within the context of the Resource Sharing Executive (RSEXEC).
   The reconnection protocol specifies a procedure for transforming a
   configuration from one in which the initiating process has
   connections to two correspondent processes, to one in which there is
   a direct connection between the correspondents. When the procedure is
   successfully completed, the initiating process is no longer in the
   communication path between the correspondents.

   Resource sharing computer networks and distributed computing will
   increasingly give rise to specialization by task among the computer
   installations. In such an environment, a "job" is the dynamically
   varying interconnection of a subset of these specialized modules.
   Connections are the "glue" in "bonding" the job together.
   Reconnection provides for a dynamically changing "bonding" structure.
   (For a more complete discussion of the utility of reconnection, see
   RFC 426).

   This document deals with reconnection in terms of its current ARPANET
   definition as a Telnet protocol option.  The first section defines a
   modified reconnection protocol. The second section discusses general
   network implementation details, while the final section describes
   aspects of the TENEX/RSEXEC implementation.

   Familiarity with the new ARPANET Telnet protocol (RFC 495) is
   assumed.

I.  PROTOCOL for RECONNECTING TELNET COMMUNICATION PATHS

   A process initiates the reconnection of two of its Telnet connections
   by sending (or requesting its "system" to send) the
   <IAC><DO><RECONNECT> Telnet command sequence over each of the two
   send connections.  The process initiating the reconnection is
   attempting to cause the direct connection of the objects of the two
   Telnet connections. In this manner, the initiating process can remove
   itself from the communication path between Telnet objects.

Schantz                                                         [Page 1]
RFC 671             A Note on Reconnection Protocol        December 1974

   The initiating process awaits positive responses to both reconnection
   requests before proceeding further with the reconnection. A
   reconnection request may be accepted by replying with the Telnet
   sequence <IAC><WILL><RECONNECT>. It may be rejected by sending the
   Telnet sequence <IAC><WONT><RECONNECT>. Rejection of both requests
   means normal communication may resume at once. Rejection of one
   request (but not the other) requires that the process agreeing to the
   reconnection be notified by sending it the Telnet sequence
   <IAC><DONT><RECONNECT> in response to its acceptance reply.

   After receiving positive responses to both requests, the initiating
   agent next selects the object of one of the Telnet connections for a
   passive role in the subsequent connection attempt. The other is
   designated as the active participant. The passive participant is to
   listen on a set of sockets, and the active participant is to send
   Request for Connections (RFCs) for those sockets. By designating
   roles, we are trying to reduce the probability of synchronization
   problems.

   The initiating process next enters into subnegotiation with the
   process designated as being passive. This subnegotiation involves
   sending the Telnet sequence <IAC> <SB> <RECONNECT> <PASSIVE>
   <NEWHOST> <NEWSOCKET1> <NEWSOCKET2> <NEWSOCKET3> <NEWSOCKET4> <IAC>
   <SE>. The <PASSIVE> parameter indicates that the recipient is to
   listen for RFCs from the socket pair denoted by <NEWHOST>
   <NEWSOCKET1-4>. The "NEWHOST" is one 8-bit byte designating the
   address of the host on which the active process (i.e., the one to
   reconnect to) resides.  NEWSOCKET1-4 are four 8-bit bytes indicating
   the 32-bit send socket number of the Telnet pair from the active
   process. The <IAC><SE> fields terminate the subnegotiation
   parameters. The initiating agent awaits a response from the passive
   process before proceeding.  The legal responses are:

     1) Telnet sequence <IAC><WONT>(RECONNECT>
        Meaning: The passive process has decided not to complete the
        reconnection, after having initially indicated willingness. This
        may be due to unexpected parameters during the subnegotiation
        (e.g., it refuses to connect to NEWHOST), or perhaps some error
        condition at the passive host.

     2) Telnet sequence <IAC><SE>
        Meaning: Positive acknowledgement of the subnegotiation
        sequence. The passive process has accepted the reconnection
Show full document text