Movatterモバイル変換

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

UNKNOWN

NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490TIP/TENEX Reliability ImprovementsRFC 636 J. Burchfiel - BBN-TENEX B. Cosell - BBN-NETNIC 30490 R. Tomlinson - BBN-TENEX D. Walden - BBN-NET 10 June 1974TIP/TENEX Reliability ImprovementsDuring the past months we have felt strong pressure to improve thereliability of TIP/TENEX network connection as improvement in thereliability of users' connections between TENEXs and TIPs would havemajor impact on the appearance of overall network reliability due to thelarge number and high visibility of TENEXs and TIPs. Despite theemphasis on TIP/TENEX interaction, all work done applies equally well tointeractions between Hosts of any type.The remainder of this RFC gives a sketch of our plan for improving thereliability of connections bettween TIPs and TENEXs. Major portions ofthis plan have already been implemented (TIP version 322; TENEX version1.32) and are now undergoing final test prior to release throughout thenetwork. Completion of the implementation of the plan is expected inthe next quarter.Our plan for improving the reliability of TIP/TENEX connections isconcerned with obtaining and maintaining TIP/TENEX connections,gracefully recovering from lost connections, and providing clearmessages to the user whenever the state of his connection changes.When a TIP user attempts to open a connection to any Host, the Host maybe down. In this case it would be helpful to provide the user withinformation about the extent of the Host's unavailability. To facilitatethis, we modified the IMP program to accept and utilize information froma Host about when the Host will be back up and for what reason it isdown. TENEX is to be modified to supply such information before it goesdown, or through manual means, after it has gone down. When the TIPuser then attempts to connect to the down TENEX, the IMP local to theTENEX returns the information about why and for how long TENEX will bedown. The TIP is to be modified to report this sort of information tothe user; e.g., "Host unavailable because of hardware maintenance --expected available Tuesday at 16:30 GMT".The TIP's logger is presently not reentrant. Thus, no single TIP usercan be allowed to tie up the logger for too long at a time; and the TIP

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490TIP/TENEX Reliability Improvementstherefore enforces a timeout of arbitrary length (about 60 seconds) onlogger use.  However, a heavily loaded Host cannot be guaranteed alwaysto respond within 60 seconds to a TIP login request, and at present TIPusers sometimes cannot get connected to a heavily loaded TENEX.  Tocorrect this problem, the TIP logger will be made reentrant and thetimeout on logger use will be eliminated.One notorious soft spot in the Host/Host protocol which degrades thereliability of connections is the Host/Host protocol incrementalallocate mechanism.  Low frequency software bugs, intermittant hardwarebugs, etc., can lead to the incremental allocates associated with aconnection getting out of synchronization.  When this happens it usuallyappears to the user as if the connection just "hung up".  A slightaddiition to the Host/Host protocol to allow connection allocates to beresynchronized has been designed and implemented for both the TIP andTENEX.TENEX has a number of internal consistency checks (called "bughalts")which occasionally cause TENEX to halt.  Frequently, after diagnosis bysystem personnel, TENEX can be made to proceed without loss from theviewpoint of local users.  A mechanism is being provided which allowsTENEX to proceed in this case from the point of view of TIP users ofTENEX.The appropriate mechanism entails the following:  TENEX will not dropits ready line during a bughalt (from which TENEX can usually proceedsuccessfully), nor will it clear its NCP tables and abort allconnections.  Instead, after a bughalt TENEX will:  discard the messageit is currently receiving, as the IMP has returned an IncompleteTransmission to the source for this message; reinitialize the interfaceto the IMP; and resynchronize, on all connections possible, Host/Hostprotocol allocate inconsistencies due to lost messages, RFNMs etc.  Thelatter is done with the same mechanism described above.  This procedureis not guaranteed to save all data -- a tiny bit may be lost -- but thisis of secondary importance to maintaining the connection over the TENEXbughalt.The TIP user must be kept fully informed as TENEX halts and thencontinues.  Therefore, the TIP has been modified to report "Host notresponding -- connection suspended" when it senses that TENEX has halted(it does this by properly interpreting messages returned by thedestination IMP).  When TENEX resumes service after proceeding from abughalt, the above procedure notifies the TIP that service is restored,and the TIP has been modified to report "Service resumed" to all usersof that Host.On the other hand, the service interruption may not be proceedable and                                   1

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490TIP/TENEX Reliability ImprovementsTENEX may have to do a total system reload and restart.  In this caseTENEX will clear its NCP connection tables and send a Host/Host protocolreset command to all other Hosts.  On receiving this reset command, theTIP will report "Host reset -- connection closed" to all users of thatHost with suspended connections.  The TIP user can then re-login to theTENEX or to some other Host.Of couse, the user may not have the patience to wait for service toresume after a TENEX bughalt.  Instead, he may unilaterally choose toconnect to some other Host, ignoring the previously suspendedconnection.  If TENEX is then able to proceed, its NCP will still thinkits connection to the TIP is good and suitable for use.  Thus, we have aconnection which the TIP thinks is closed and TENEX thinks is open, aphenomenon known as the "half-closed connection".  An automaticprocedure for cleanly completing the closing of such a connection hasbeen specified and implemented for the TIP and TENEX.Since TENEX will maintain connections across service interruptions, theTIP user will be required to take the security procedure telling the TIPto "forget" his suspended connection before abandoning his terminal.The command @H 0 (for example) will guarantee that his connection willnot be reestablished on resumpption of service.  Otherwise, his jobwould be left at the mercy of anyone who acquires that terminal.An appendix follows which describes the Host/Host protocol changes made.These changes are backward compatible (with the exception that Hostswhich have not implemented these changes will sometimes receiveunrecognizable Host/Host protocol commands which they presumably discardwithout suffering harm).  These protocol changes are ad hoc in naturebut in light of their backward compatibility and potential utility, ARPAokayed their addition to the TIP and TENEX NCPs without (we believe) anyimplication that other Hosts have to implement them (although we wouldencourage their widespread implementation).                                   2

NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490TIP/TENEX Reliability Improvements Appendix - Ad Hoc Change to Host-Host Protocol A.1 Introduction The current Host-Host protocol (NIC #8246) contains no provisions for resynchronizing the status information kept at the two ends of each connection. In particular, if either host suffers a service interruption, or if a control message is lost or corrupted in an interface or in the subnet, the status information at the two ends of the connection will be inconsistent. Since the current protocol provides no way to correct this condition, the NCPs at the two ends stay "confused" forever. An occasional frustrating symptom of this effect is the "lost allocate" phenomenon, where the receiving NCP believes that it has bit and message allocations outstanding, while the sending NCP believes that it does not have any allocation. As a result, information flow over that connection can never be restarted. Use of the Host-Host RST (reset) command is inappropriate here, as it destroys all connections between the two hosts. What is needed is a way to resynchronize only the affected connection without disturbing any others. A second troublesome symptom of inconsistency in status information is the "half-closed" connection: after a service interruption or network partitioning, one NCP may believe that a connection is still open, while the other believes that the connection is closed (does not exist). When such an inconsistency is discovered, the "open" end of the connection should be closed. A.2 The RAR, RAS and RAP commands To achieve resynchronization of allocation, we add the following three commands to the host-host protocol. 8 bits 8 bits ------------------- ! ! ! 16 ! RAR ! link ! ! ! ! ------------------- Reset Allocation by Receiver 8 bits 8 bits ------------------- ! ! ! 3

NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490TIP/TENEX Reliability Improvements 17 ! RAS ! link ! ! ! ! ------------------- Reset Allocation by Sender 8 bits 8 bits ------------------- ! ! ! 20 ! RAP ! link ! ! ! ! ------------------- Reset Allocation Please The RAS command is sent from the Host sending on "link" to the Host receiving on "link". This command may be sent whenever the sending Host desires to resynch the status information associated with the connection (and doesn't have a message in transit through the network). Some circumstances in which the sending Host may choose to do this are: 1) After a timeout when there is traffic to move but no allocation (assumes that an allocation has been lost); 2) When an inconsistent event occurs associated with that connection (e.g. an outstanding allocation in excess of 2^32 bits or 2^16 messages); 3) After the sending host has suffered an interruption of network service; 4) In response to a RAP (see below). The RAR command is sent from the Host receiving on "link" to the Host sending on "link" in response to an RAS. It marks the completion of the connection resynchronization. When the RAR is returned the connection is in the known state of having no messages in transit in either direction and the allocations are zero. The receiving Host may then start afresh with a new allocation and normal message transmission can proceed. Since the RAR may be sent ONLY in response to an RAS, there are no races in the resynchronization. All of the initiative lies with the sending Host. If the receiving Host detects an anomalous situation, however, there is no way to inform the sending Host that a resynchronization is desirable. For this purpose, the RAP command is provided. It constitutes a "suggestion" on the part of the 4

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490TIP/TENEX Reliability Improvements      receiving Host that the sending Host resynchronize; the sending      Host is free to honor it or not as it sees fit.  Since there is no      obligatory response to a RAP, the receiving Host may send them as      frequently as it chooses and no harm can occur.  For example, if a      message in excess of the allocate arrives, the receiving Host      might send RAPs every few seconds until the sending Host replies      with no fears of races if one or more RAPs pass a RAS in the      network.   A.3  Resynchronization Procedure      The resynchronization sequence below may be initiated only by the      sender either for internally generated reasons or upon the receipt      of a RAP.         a)  Sender - decision to resynch            1)  Set state to "Wait-for-RAR" (Defer transmission of            message.)            2)  Wait until no RFNM outstanding            3)  Send RAS            4)  Zero allocation            5)  Ignore allocates until RAR received            6)  Set state to "Open" (Resume normal message transmission            subject to flow control.)         b)  Receiver - receipt of RAS            1)  Send RAR            2)  Zero allocation            3)  Send a new allocation      When the sender is in the "Wait-for-RAR" state it is not permitted      to send new regular messages.  (Note that steps 4 and 5 will      insure this in the normal course of events.)  With the return of      the RAR the pipeline contains no messages and no allocates, the      outstanding allocation variables at both ends are forced into      agreement by setting them both to zero.  The receiver will then      reconsider bit and message allocation, and send an ALL command for      any allocation it cares to do.   A.4  The Problem of Half-closed Connections      The above procedures provide a way to resynchronize a connection      after a brief lapse by a communications component, which results      in lost messages or allocates for an open connection.                                   5

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490TIP/TENEX Reliability Improvements      A longer and more severe interruption of communication may result      from a partitioning of the subnet or from a service interruption      on one of the communicating hosts.  It is undesirable to tie up      resources indefinitely under such circumstances, so the user is      provided with the option of freeing up these resources (including      himself) by unilaterally dissolving the connection.  Here      "unilaterally" means sending the CLS command and closing the      connection without receiving the CLS acknowledgement.  Note that      this is legal only if the subnet indicates that the destination is      dead.      When service is restored ater such an interruption, the status      information at the two ends of the connection is out of      synchronization.  One end believes that the connection is open,      and may proceed to use the connection.  The disconnecting end      believes that the connection is closed (does not exist), and may      proceed to re-initialize communication by opening a new connection      (RTS or STR command) using the same socket pair or same link.      The resynchronization needed here is to properly close the open      end of the connection when the inconsistency is detected.  We will      accomplish this by specifying consistency checks and adding a new      pair of commands.   A.5  The NXS and NXR Commands      The "missing CLS" situation described above can manifest itself in      two ways.  The first way involves action taken by the NCP at the      "open" end of the connection.  It may continue to send regular      messages on the link of the half-closed connection, or control      messages referencing its link.  The closed end should respond with      an NXS if the message referred to a non-existent transmit link      (e.g. was an ALL) or NXR if the message referred to a non-existent      receive link (e.g. a data message).  On receipt of such an NXS or      NXR message, the NCP at the "open" end should close the connection      by modifying its tables (without sending any CLS command) thereby      bringing both ends into agreement.              8 bits   8 bits            -------------------            !        !        !         21 !  NXR   !  link  !            !        !        !            -------------------         Non-existent Receive Link              8 bits   8 bits                                   6

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490TIP/TENEX Reliability Improvements            -------------------            !        !        !         22 !  NXS   !  link  !            !        !        !            -------------------         Non-existent Send Link   A.6  Consistency Checks      A second way this inconsistency can show up involves actions      initiated by the NCP at the "closed" end.  It may (thinking the      connection is closed) send an STR or RTS to reopen the connection.      The NCP at the "open" end should detect the inconsistency when it      receives such an RTS or STR command, because it specifies the same      socket pair as an existing open connection, or, in the case of an      RTS, the same link.  In this case, the NCP at the "open" end      should close the connection (without sending any CLS command) to      bring the two ends into agreement before responding to the      RTS/STR.   A.7  Conclusion      The scheme presented in Section A.2 to resynchronize allocation      has one very important property:  the data stream is preserved      through the exchange.  Since no data is lost, it is safe to      initiate resynchronization from either end at any time.  When in      doubt, resynchronize.      The consistency checks for RTS and STR, and the NXR and NXS      commands provide the synchronization needed to complete the      closing of "half-closed" connections.      The protocol changes above

[8]ページ先頭