|
Network Working Group Request for Comments: 426 NIC: 13011 Categories: Protocols, TELNET References: 36,318,333,435 |
Bob Thomas BBN-TENEX 23 January 1973 |
There are situations in which it is desirable to move one or both ends of a communication path from one host to another. This note describes several situations in which the ability to reconnect is useful, presents a mechanism to achieve reconnection, sketches how the mechanism could be added to Host-Host or TELNET protocol, and recommends a place for the mechanism in the protocol hierarchy.
The TIP user could access the executive by typing a command such as
"@ EXEC"; the TIP would 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 executive
hand him off to Host2. To do this the executive program would first
interact with Host2, telling it to expect a call from 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 prepatory to
doing more work elsewhere. The reconnection activity would be
invisible to the TIP user.
Reconnection
______ | ______
| | | | |
| EXEC |<-------------+------------>| USER |
|______| | / |______|
Host1 V / TIP
______ /
| |<------/
|______|
Host2
Figure 1
(a) ______ for authentication ______
| | | | |
| |<-----------+------------->| User |
|______| | / |______|
Host |/
X
/|
_______ / |
| | / v
| |<---
|_______|
Authenticator
(b)
______ ______
| | | |
| |<--\ ^ /-->| User |
|______| \ | / |______|
Host \ | /
------------+--/
| /
|/
|
/|
/ |
/ | authentication
_______ / | complete
| | /
| |<------
|_______|
Authenticator
Figure 2
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.
NY Terminal NY Enroute Boston Enroute Boston Terminal
_____ _____ _____ _____
| | / | | \ | | | |
|Host1|<----/--->|Host2|<---\---->|Host3|<----->|Host4|
|_____| \ / |_____| \ / |_____| |_____|
X move X
/ \ | / \
| \ V / |
V \ _____ / V
reconnect \ | | / reconnect
->|Host5|<-
|_____|
NY Enroute
Figure 3
The mechanism proposed here could be added to the existing Host-Host protocol or to the TELNET protocol. The mechanism is first described and then its adaptation to each of the protocols is discussed.
The reconnection mechanism includes four commands:
Reconnect Request: RRQ <path>
Reconnect OK: ROK <path>
Reconnect No: RNO <path>
Reconnect Do: RDO <path> <new destination>
where <path> is the communication path to be redirected to <new destination>.
Assume that H1 wants to move its end of communication path A-C from itself to port D at H3 (See figure 4).
(a) situation (b) desired situation
H2 H3 H2 H3
___ ___ ___ ___
| | | | | | | |
| C|<-+ |D | | C|<------>|D |
|___| | |___| |___| |___|
|
|
| ___ ___
| | | | |
+->|A | |A |
|___| |___|
H1 H1
Figure 4
The reconnection proceeds by steps:
H1->H2: RRQ (path A-C)
H2->H1: ROK (path C-A)
H1->H2: RDO (path A-C) (Host H3, Port 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)
H3->H1: ROK (path D-B)
H1->H3: RDO (path B-D) (Host H2, Port C)
H2 H3
______ ______
| | | |
| C | | D |
---\-- -/----
\ /--> <--\ /
\- -/--- --- --- --- --- \---/
\ / \ /
X X
/ \ / \
/ \ / \
reconnection \ / reconnection
\ ________ /
---|A B|---
| |
|________|
H1
Figure 5
Either of the parties may use the RNO command to refuse or abort the 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:
(a) situation (b) desired situation
H1 H4 H1 H4
____ ____ ____ ____
| | | | | | | |
| C| |E | | C|--------|E |
|____| |____| |____| |____|
H2 H3 H2 H3
____ ____ ____ ____
| | | | | | | |
| B|--------|D | | B| |D |
|____| |____| |____| |____|
H2 and H3 "simultaneously" try to arrange for reconnection:
H2->H3: RRQ (path B-D)
H3->H2: 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 H[2])
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:
___ ___
| P |---------------| Q |
|___| |___|
____________________
| P --> Q || R R Q |
|_________||_________|
|
+---------+
|
____V_______________________________________
| || | | |
| Q --> P || R O K | R N O ----| R R Q |
| || | | E | |
|_________||_________|_________|___|_________|
| |
+------------+ v
| Yes +----------+ No
| +------------------------| NP > NQ? |------+
| | +----------+ |
__v___v_______________________________ |
| || | | |
| P --> Q || R D O ----| R N O ----| |
| || | E | | E | |
|_________||_________|___|_________|___| |
|
+--------------------------------------------+
|
____v_________________________________
| || | |
| Q --> P || R D O ----| R N O ----|
| || | E | | E |
|_________||_________|___|_________|___|
NP and NQ are the 40 bit numbers for P and Q; E indicates end of sequence.
The four reconnect commands could be included directly in Host-Host protocol as follows:
RRQ <my socket> <your socket>
ROK <my socket> <your socket>
RNO <my socket> <your socket>
RDO <my socket> <your socket> <new host> <new socket>
The ROK and RDO commands for a send connection should not be sent until there are no messages in transit over the connection. The RDO
command is to be interpreted as a CLS.
The reconnection:
H2 H3 H2 H3
___ ___ ___ ___
| | | | | C|--------|D |
|_C_| |_D_| |___| |___|
| |
| | ===>
| ____ | ____
---|A B|--- | |
|____| |____|
H1 H1
could be accomplished as follows:
H1->H2: RRQ A C
H1->H3: RRQ B D
H2->H1: ROK C A
H3->H1: ROK D B
H1->H2: RDO A C H3 D
H1->H3: RDO B D H2 C
H2->H1: CLS C A
H3->H1: CLS D B
H2->H3: STR C D size
H3->H2: RTS D C link
Note that it is possible for the STR from H2 to arrive at H3 before the RDO from H1. H3 must be prepared to queue such an RFC until it gets an RDO or RNO from H1. Stated differently, transmission of an ROK for a local socket causes the socket to move from an "open" state to a "reconnect pending" state and indicates willingness to queue subsequent RFC's until receipt of a "matching" RDO or RNO.
Independently of whether Host-Host protocol directly supports reconnection, the reconnection mechanism could be included in TELNET with the addition to the TELNET protocol of the five commands:
RRQ
ROK
RNO
RDO <host> <socket>
RWT <host> <socket>
where RRQ, ROK, RNO, RDO, and RWT are appropriately chosen characters in the range 128 to 255. 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.
A pending reconnection can be activated 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's; for RWT, by waiting for two RFC's.
The RWT command is introduced to avoid races such as the one between the STR and CLS (RDO) discussed above. In Host-Host protocol the race is avoided by putting a connection into "reconnect pending" state upon transmission of ROK. For TELNET the race can be avoided by the initiator of the reconnection by judicious use of RWT and RDO. For example the reconnection:
H2 H3 H2 H3
+---+ +---+ +---+ M +---+
| |----+ +---->| | | |------->| |
| Y | N | | Q | Z | ==> | Y | N | Z |
| |<-+ | H1 | +---| | | |<-------| |
+---+ | | M +---+ P | | +---+ +---+ +---+
| +--->| |----+ |
| | X | | H1
+------| |<-----+ +---+
+---+ | |
H1 | X |
| |
+---+
could be accomplished as follows:
X->Y: RRQ
X->Z: RRQ
Y->X: ROK
Z->X: ROK
X->Y: RWT H3 P
X closes connections to Y
Y closes connections to X
Y waits for STR and RTS from H3
X->Z: RDO H2 N
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 complete reconnection
The reconnection mechanism for TELNET can be made to fit nicely into the command format suggested by Cosell and Walden in RFC #435. Consider the addition of three new commands to TELNET:
Prepare for Reconnect: RCP
Begin Reconnect by sending RFC's: RCS
Begin Reconnect by waiting for RFC's: RCW
Using these three command and the DO, DON'T, WILL, WON'T commands of RFC #435, the commands proposed earlier become:
RRQ => DO RCP
ROK => WILL RCP
RNO => WON'T RCP ;for responses to DO RCP
DON'T RCP ;for responses to WILL RCP
;i.e. used to cancel an RCP.
RDO <host> <socket> => DO RCS <host> <socket>
RWT <host> <socket> => DO RCW <host> <socket>
As RFC #435 notes the nice thing about this structure is that a host choosing not to implement reconnection does not even have to know what RCP means. All that it need do in response to DO RCP is to transmit WON'T RCP.
I feel that reconnection is a basic notion and that its proper place within the protocol hierarchy is at the Host-Host level where it would be available for use in all higher level protocols. The difficulty is that placing it there would, of course, require NCP rewrites. Reluctance to make NCP modifications would probably be sufficient to kill interest in the proposal.
Therefore, for pragmatic reasons, I recommend that the reconnection mechanism be included in TELNET as an "option" in the spirit of RFC
#435. This can be accomplished with the addition to the TELNET protocol of the RCP, RCS, RCW commands as described in Section 4. Modification of user- and server-TELNET programs to handle these new commands should be straightforward. If a reconnection option is made part of TELNET protocol the TENEX hosts will support it. In addition, the TIP guys (Walden and Cosell) have said that they like the reconnection mechanism and have agreed, in principle, to implement it for TIPs if it is accepted as part of TELNET protocol.
Addition of reconnection at the TELNET level rather than the Host- Host level is admittedly a compromise. However, with it, activity of the sort described in Examples A and B of Section 1 will be possible.
__ __ __ __ __
___| |____| |____| |____| |____| |___
|__| |__| |__| |__| |__|
and specifies how one or more entities can break out of the chain. As suggested above (Figure 5) the mechanism proposed in this note supports that kind of reconnection.
As simple and appealing as this procedure seems, I doubt that it would be used in practice if MSP were to be implemented as a replacement for or alternative to existing Host-Host protocol. The reason is that the ability to pass ports from Host to Host (needlessly) complicates port name allocation by requiring cooperation among Hosts to manage the allocation (e.g., before a Host can safely allocate a port name for use by a local process it must not only insure that the port is not in use locally but also that no process out in the network is using it.) The inter-Host cooperation required to support the passage of ports among Hosts can probably not be reliably achieved in practice. Therefore port passage of the sort described in RFC #333 should not be supported at the Host-Host protocol level. For this reason, I feel that within an MSP "reconnection" would be best handled by a mechanism such as the one proposed in this note.
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Anthony Anderberg 4/99 ]