rfc426.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         Bob Thomas
Request for Comments: 426                                      BBN-TENEX
NIC: 13011                                               23 January 1973
Categories: Protocols, TELNET
References: 36,318,333,435


                         Reconnection Protocol

   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.

1. Some Examples:

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 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



Thomas                                                          [Page 1]

RFC 426                  Reconnection Protocol              January 1973


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 undesirable 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 Host which can then provide him service.  The
   idea is that the shuffling of the user back and forth between Host
   and Authenticator should invisible to the user.

   (a)   ______      for authentication     ______
        |      |            |              |      |
        |      |<-----------+------------->| User |
        |______|            | /            |______|
          Host              |/
                            X
                           /|
             _______      / |
            |       |    /  v
            |       |<---
            |_______|
          Authenticator

   (b)
         ______                             ______
        |      |                           |      |
        |      |<--\             ^     /-->| User |
        |______|    \            |    /    |______|
          Host       \           |   /
                     ------------+--/
                                 | /
                                 |/
                                 |
                                /|
                               / |
                              /  | authentication
             _______         /   | complete
            |       |       /
            |       |<------
            |_______|
          Authenticator

                           Figure 2





Thomas                                                          [Page 2]

RFC 426                  Reconnection Protocol              January 1973


   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.

C. The McROSS air traffic simulation system (see 1972 SJCC paper)
   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 New York
   Enroute simulator at Host2 and reconnect to it at Host5.

   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
2. A Reconnection Mechanism

   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).



Thomas                                                          [Page 3]

RFC 426                  Reconnection Protocol              January 1973


     (a) situation                 (b) desired situation

     H2          H3                  H2           H3
    ___         ___                 ___          ___
   |   |       |   |               |   |        |   |
   |  C|<-+    |D  |               |  C|<------>|D  |
   |___|  |    |___|               |___|        |___|
          |
          |
          |   ___                             ___
          |  |   |                           |   |
          +->|A  |                           |A  |
             |___|                           |___|
               H1                              H1

                          Figure 4


   The reconnection proceeds by steps:

           a. H1 arranges for the reconnection by sending RRQ to
              H2:
                   H1->H2:   RRQ (path A-C)

           b. H2 agrees to reconnect and acknowledges with ROK:

                   H2->H1:   ROK (path C-A)

           c. H1 notes that H2 has agreed to reconnect and
              instructs H2 to perform the reconnection:

                   H1->H2:   RDO (path A-C) (Host H3, Port D)

           d. 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)
           H3->H1:  ROK (path D-B)
           H1->H3:  RDO (path B-D) (Host H2, Port C)






Thomas                                                          [Page 4]

RFC 426                  Reconnection Protocol              January 1973


          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   |
   |____|        |____|            |____|        |____|




Thomas                                                          [Page 5]

RFC 426                  Reconnection Protocol              January 1973


   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])

      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.

   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:


















Thomas                                                          [Page 6]