< NETINFO, NIC15391.NLS.6, >, 17-Mar-78 16:57 JOJO ;;;;
.DefaultFont=10p,Newsgothic,Medium; .LMBase=,1.0; .WidowL=3;
.HJournal="TELNET RECONNECTION OPTION"; .HJFont=10p,Newsgothic,Bold;
.H1="NIC 15391 (Aug. 1973)"; .H1Font=10p,Newsgothic,Bold; .H1Sw=On;
.HJP=OddR; .H1P=OddR; .BM=54,10.0; .HJRM=72,6.5; .RM=72,6.5; .BRM=72,6.5; 
.SNF=Off; .YBS=1; .H2Sw=Off;   .F=".GPN;"; .FFont=10p,Newsgothic,Medium; 
.Text[TU0]=".Tabto=U0+1,U0;"; .Text[TU1]=".Tabto=U1+1,U1;";
.PN=0; .NumDash=0; .BP=FL,J;
.Text[MB]=".BP=,FL;.Bfont=10p,Newsgothic,Medium+Mono;";
.Text[BB]=".BP=,J;.Bfont=10p,Newsgothic,Bold;";
.Text[ME]=".BP=,J;.Bfont=10p,Newsgothic,Medium;";.PES;
.CENTER;.BB;TELNET RECONNECTION OPTION.ME; .FSw=ON; .PN=1;
1. Command name and code
   RCP              2       (prepare to reconnect)
2. Command meanings.
   IAC DO RCP
      The sender of this command requests the receiver of the command to be 
      prepared to break the TELNET connection with the sender of the command 
      and to re-establish the TELNET connection with some other party (to be 
      specified later).
   IAC WILL RCP
      The receiver of this command agrees to break its TELNET connection to the
      sender of the DO RCP command and to re-establish the connection with the 
      party to be specified by the sender of the DO RCP command.
   IAC WON'T RCP
      The receiver of this command refuses to take part in a reconnection.
   IAC DON'T RCP
      The sender of this command demands the cancellation of its previous DO 
      RCP command.
   IAC SB RCP RCS <host> <socket>
      The sender of this command instructs the receiver of the command to 
      transfer this TELNET connection to the place specified by <host> 
      <socket>.  The code for RCS is 0.
   IAC SB RCP RCW <host> <socket>
      The sender of this command instructs the receiver of the command to break
      the TELNET connection and to await a new TELNET connection from the place
      specified by <host> <socket>. The code for RCW is 1.
3. Default. .Grab=5;
   WON'T RCP
      i.e., no reconnection is allowed.
4. Motivation for the option.
   There are situations in which it is desirable to move one or both ends of a 
   communication path from one Host to another.
      A. Consider the case of an executive program which TIP users could use to
      get network status information, send messages, link to other users, etc. 
      Due to the TIP's limited resources the executive program would probably 
      not run on the TIP itself but rather would run on one or more larger 
      Hosts who would be willing to share some of their resources with the TIP 
      (see Figure 1).
      The TIP user could access the executive by typing a command such as 
      "@EXEC"; the TIP should then ICP to Host1's executive port.  After 
      obtaining the latest network news and perhaps sending a few messages, the
      user would be ready to log into Host2 (in general not the same as Host1) 
      and do some work.  At that point he would like to tell the executive 
      program that he is ready to use Host2 and have the executive hand him off
      to Host2.  To do this the executive program would first interact with 
      Host2, telling it to expect a call from the TIP, and then would instruct 
      the TIP to reconnect to Host2.  When the user logs off Host2 he could be 
      passed back to the executive at Host1 preparatory to doing more 
      elsewhere.  The reconnection activity would be invisible to the TIP user.
       .Grab=15;.MB;
       --------                       --------    
       ! EXEC !<--------------------->! USER !    
       --------               /       --------   
        Host 1      !        /           TIP     
                    !       /                   
       reconnection V      /                    
                          /                     
                         /                      
                    --------                     
                    !      !                    
                    --------                    
                     Host 2.ME;                     
                                                
                     FIGURE 1
      B. Imagine a scenario in which a user could use the same name and 
      password (and perhaps account) to log into any server on the network.  
      For reasons of security and economy it would be undersirable to have 
      every name and password stored at every site.  A user wanting to use a 
      Host that doesn't have his name or password locally would connect to it 
      and attempt to log in as usual (see Figure 2).  The Host, discovering 
      that it doesn't know the user, would hand him off to a network 
      authentication service which can determine whether the user is who he 
      claims to be.  If the user passes the authentication test he can be 
      handed back to the Host which can then provide him service.
         If the user doesn't trust the Host and is afraid that it might read 
         his password rather than pass him off to the Authenticator he could 
         connect directly to the authentication service.  After authentication,
         the Authenticator can pass him off to the Host.    
      The idea is that the shuffling of the user back and forth between Host 
      and Authenticator should be invisible to the user.   
       .Grab=15;.MB;
       --------                       --------    
       !      !<--------------------->! USER !    
       --------               /       --------   
         Host       !        /                   
                    !       /                   
       reconnection V      /                    
           for            /                     
       authentication    /                     
                    --------                     
                    !      !                    
                    --------                    
                  Authenticator.ME;                  
                                                
                     FIGURE 2a
       .Grab=15;.MB;
       --------                       --------    
       !      !<--------------------->! USER !    
       --------               /       --------   
         Host       ^        /                   
                    !       /                   
                    !      /                    
       authentication     /                     
         complete        /                     
                    --------                     
                    !      !                    
                    --------                    
                  Authenticator.ME;                  
                                                
                    FIGURE 2b
      C. The McROSS air traffic simulation system (see 1972 SJCC paper by 
      Thomas) already supports reconnection.  It permits an on - going 
      simulation to reconfigure itself by allowing parts to move from computer 
      to computer.  For example, in a simulation of air traffic in the 
      Northeast, the program fragment simulating the New York Enroute air space
      could move from Host2 to Host5 (see figure 3).  As part of the 
      reconfiguration process the New York Terminal  area simulator and Boston 
      Enroute area simulators break their connections with the New York Enroute
      simulator at Host2 and reconnect to it at Host5. .Grab=10;
       .Grab=15;.MB;
        Host 1         Host 2         Host 3          Host 4
       --------     ) -------- (     --------        --------
       !  NY  !    /  !  NY  !  \    ! BOS  !        ! BOS  !
       ! Term !<--/-->! Enrt !<--\-->! Enrt !<------>! Term !
       --------  \    --------    /  --------        --------
                / \     move     / \           
               /   \      !     /   \         
         reconnect  \     !    /   reconnect               
                     \    V   /                
                      \      /                 
                      --------                     
                      !  NY  !                    
                      ! Enrt !                    
                      --------                    
                       Host 5.ME;
                           
                      FIGURE 3 .PES;
5. An abstract description of a reconnection mechanism.
   The reconnection mechanism includes four (abstract) commands:     
      Reconnect Request: .U0=X;RRQ <path> .YBS=0;
      Reconnect OK:.TU0;ROK <path> 
      Reconnect No:.TU0;RNO <path> 
      Reconnect Do:.TU0;RDO <path> <destination> .YBS=1;  
      where <path> is a communication path to be redirected to <destination>.
   Assume that H1 wants to move its end of communication path A-C from itself 
   to port D at H3 (Figure 4). .Grab=18;
    .Grab=15;.MB;
    --------       --------             --------       --------    
    !    C !       ! D    !             !    C !<----->! D    !    
    --------       --------             --------       --------   
     H2   \          H3                    H2             H3     
           \                                              
            \                  ===>                 
             \                               
              --------                         --------              
              ! A    !                         ! A    !          
              --------                         --------             
                 H1                               H1.ME;                       
                                 
         (a) situation                  (b) desired situation      
                                             
                            FIGURE 4
   The reconnection proceeds by steps:
      a. .U0=X;H1 arranges for the reconnection by sending RRQ to H2:
         H1->H2: RRQ (path A-C)
      b..TU0;H2 agrees to reconnect and acknowledges with ROK:
         H2->H1:  ROK (path C-A)
      c..TU0;H1 notes that H2 has agreed to reconnect and instructs H2 to
         perform the reconnection;
         H1->H2: RDO (path A-C)   (Host H3, PortD) .PES;
      d..TU0;H1 breaks paths A-C.
         H2 breaks path C-A and initiates path C-D.
      In order for the reconnection to succeed H1 must, of course, have 
      arranged for H3's cooperation.  One way H1 could do this would be to 
      establish the path B-D and then proceed through the reconnection protocol
      exchange with H3 concurrently with its exchange with H2 (See Figure 5):
         H1->H3:   RRQ (path B-D) .YBS=0;
         H3->H1:   ROK (path D-B)
         H1->H3:   RDO (path B-D)  (Host H2, Port C) .YBS=1;
       .Grab=15;.MB;
       --------           --------
       !    C !   ^   ^   ! D    !
       --------  /     \  --------
        H2   \../.......\../   H3 
              \/         \/                                  
              /\         /\                            
            /   \       /  \                    
      reconnect  --------  reconnect                          
                 ! A  B !                          
                 --------                        
                    H1.ME;                               
                                          
                                                
                 FIGURE 5
   Either of the parties may use the RNO command to refuse or abort 
   reconnection.  H2 could respond to H1's RRQ with RNO; H1 can abort the 
   reconnection by responding to ROK with RNO rather than RDO.
   It is easy to insure that messages in transit are not lost during the 
   reconnection.  Receipt of the ROK message by H1 is taken to mean that no 
   further messages are coming from H2; similarly receipt of RDO from H1 by H2 
   is taken to mean that no further messages are coming from H1.
   To complete the specification of the reconnection mechanism consider the 
   situation in which two "adjacent" entities initiate reconnections:
    .Grab=15;.MB;
    --------       --------             --------       --------    
    !    C !       ! E    !             !    C !-------! E    !    
    --------       --------             --------       --------   
     H1              H4                   H1               H4     
                               ===>                      
                                             
    --------       --------             --------       --------    
    !    B !-------! D    !             !    B !       ! D    !    
    --------       --------             --------       --------   
     H2              H3                   H2               H3.ME;     
                                          
         (a) situation                  (b) desired situation      
                                             
                             FIGURE 6
   H2 and H3 "simultaneously" try to arrange for reconnection:
      H2->H3:   .U0=X;RRQ (path B-D)
      H3->H2:.TU0;RRQ (path D-B)
   Thus, H2 sees an RRQ from H3 rather than an ROK or RNO in response to its 
   RRQ to H3.  This "race" situation can be resolved by having the 
   reconnections proceed in series rather than in parallel:  first one entity 
   (say H2) performs its reconnect and then the other (H3) performs its 
   reconnect.  There are several means that could be used to decide which gets 
   to go first.  Perhaps the simplest is to base the decision on sockets and 
   site addresses:  the entity for which the 40 bit number formed by 
   concatenating the 32 bit socket number with the 8 bit site address is 
   largest gets to go first.  Using this mechanism the rule is the following:
      If H2 receives an RRQ from H3 in response to an RRQ of its own:
         (let NH2, NH3 = the 40 bit numbers corresponding to H2 and H3).IOvr=3;
         a. if NH2>NH3 then both H2 and H3 interpret H3's RRQ as an ROK in 
         response to H2's RRQ.
         b. if NH2<NH3 then both interpret H3's RRQ as an RNO in response to 
         H2's RRQ.  This would be the only case in which it makes sense to 
         "ignore" the refusal and try again - of course, waiting until 
         completion of the first reconnect before doing so. .IOvr=0;
   Once an ordering has been determined the reconnection proceeds as though 
   there was no conflict. 
   The following diagram describes the legal protocol command/response exchange
   sequences for a reconnection initiated by P: .Grab=22;.MB;
                   -----        -----
                   ! P !--------! Q !
                   -----        -----
    .Grab=20;
     ----------------
     ! P->Q !! RRQ  !
     ----------------
                !
        ---------
       !
       V
    ------------------------------
    ! Q->P !! ROK  ! RNO e! RRQ  !
    ------------------------------
               !             !
     -----------             V
     !               ------------
     ! -------yes----! NP > NQ? !----no-
     ! !             ------------      !
     V V                               V
    -------------------              -------------------
    !P->Q!!RDO e!RNO e!              !Q->P!!RDO e!RNO e!
    -------------------              -------------------
   .ME;NP and NQ are the 40 bit numbers for P and Q;  e indicates end of 
   sequence. 
6. A description of the option.
   The reconnection mechanism described abstractly in the previous section can 
   be effected as a TELNET option by use of the command RCP.  Using this 
   command and the TELNET DO, DON'T, WILL, WON'T, and SB prefixes, the four 
   commands used in the previous abstract description become
      .MB;RRQ =>  DO RCP.ME;
      .MB;ROK =>  WILL RCP.ME;
      .MB;RNO =>  WON'T RCP   .ME;;for responses to DO RCP
      .MB;        DON'T RCP   .ME;;for responses to WILL RCP
      .MB;                    .ME;;i.e. used to cancel an RCP.
      .MB;RDO  .ME;<host> <socket> => SB RCP RCS <host> <socket>
   A fifth command is also introduced
      .MB;RWT  .ME;<host> <socket> => SB RCP RCW <host> <socket>
   The first three commands require no parameters since they refer to the 
   connections they are received on.  For RDO and RWT, <host> is an 8 bit (= 1 
   TELNET character) Host address and <socket> is a 32 bit (= 4 TELNET 
   characters) number that specifies a TELNET receive socket at the specified 
   Host (the associated transmit socket is always one higher than the receive 
   socket.
   A pending reconnection can be activiated with either RDO or RWT.  The 
   response to either is to first break the TELNET connection with the sender 
   and then reopen the TELNET connection to the Host and sockets specified.  
   For RDO, the connection is to be reopened by sending two RFC'c; for RWT, by 
   waiting for two RFC's.
   The RWT command is introduced to avoid requiring Hosts to queue RFC's.
   As an example, the reconnnection
    .Grab=15;.MB;
     H2               H3                   H2              H3    
    --------       --------             --------     m --------   
    !   Y  !       !   Z  !             !   Y  !------>!   Z  !   
    !      !       !      !             !      !<------!      !   
    --------       --------             -------- n     --------  
        n\ \           p/ /                               
          \ \          / /                           
           \ \m       / /                    
            \ -------- /q        ===>          --------           
              !   X  !                         !   X  !          
              !      !                         !      !          
              --------                         --------           
                 H1                                H1.ME;
   could be accomplished as follows:.MB;
      X->Y:   RRQ        (=IAC DO RCP) .YBS=0;
      X->Z:   RRQ        (=IAC DO RCP)
      Y->X:   ROK        (=IAC WILL RCP)
      Z->X:   ROK        (=IAC WILL RCP)
      X->Y:   RWT H3 P   (=IAC SB RCP RCW H3 P).ME;
      X closes connections to Y
      Y closes connections to X
      Y waits for STR and RTS from H3.MB;
      X->Z:   RDO H2 N    (=IAC SB RCP RCS H2 N).ME;
      X closes connections to Z
      Z closes connections to X
      Z sends STR and RTS to H2 which Y answers with matching RTS and STR to 
      compete reconnection .YBS=1;
   The RCS and RCW sub-commands should never be sent until a DO RCP has been 
   acknowledged by a WILL RCP.  Thus a Host not choosing to implement the 
   reconnection option does not have to know what RCP means--all the Host need 
   do in response to DO RCP is to transmit WON'T RCP.  The WILL RCP and WON'T 
   RCP commands should never be volunteered.  If an unsolicited WILL RCP is 
   ever received, a DON'T RCP should be fired back, which should be answered by
   a WON'T RCP command.  If an unsolicited WON'T RCP command is received, it 
   should be treated as a No-operation. 
7. A word about security.
   It should be clear that the decision to accept or reject a particular 
   reconnection request is the responsibility of the entity (person at the 
   terminal or process) using the connection.  In many cases the entity may 
   chose to delegate that responsibility to its TELNET (e.g., Example A, 
   Section 4).  However, the interface a Host provides to the reconnection 
   mechanism would best include means for local entities to exercise control 
   over response to remotely intitiated reconnection requests.  For example, a 
   user-TELNET might support several modes of operation with respect to 
   remotely initiated reconnections:
      .U1=X;1. .U0=X;.IRest=U0-U1,U0-U1;transparent:  all requested 
      reconnections are to be performed in a way that is invisible to the user;
      2. .TU0;visible:  all requested reconnections are to be performed and the
      user is to be informed whenever a reconnection occurs;
      3. .TU0;confirmation:  the user is to be informed of each reconnection 
      request which he may accept or reject;
      4. .TU0;rejection:  all requested reconnects are to be rejected. 
      .IRest=0;
