Movatterモバイル変換

Network Working Group                              Bernard CosellRFC # 271                                          BBNNIC 7819                                           3 January 1972Categories:  B.1Updates:  NoneObsoletes:  NoneIMP System Change Notification------------------------------    We are planning to install a new version of the IMP System,version 2514.  The new version is scheduled for field installationThursday, January 13, 1972 between noon and 1 PM EST, and will requirethe assistance of IMP-site personnel at each site.    There were two principal problems with version 2513, both relatedto the delay inserted between the time when a Host comes up and thetime when its IMP will accept the second packet from the Host.  Thefirst was that the delay was lengthened to slightly over 40 seconds,which caused hardware difficulties for some Hosts.  The second wasthat there was an ambiguity that could make the delay run as long as aminute and a quarter.  On the first point, the delay has been backedoff from 40 seconds to 30 seconds, as it was for IMP systems prior to2513.  On the second point, the ambiguity has been entirely removed.(Note, however, that BBN Report No. 1822, on page 23, specifies thatthe delay may range from 30 to 90 seconds, and that future versionsmay require a longer delay.)    In summary, a Host may come alive in one of two ways, corres-ponding to the two ways in which the Host can go down.  If the Hostwent down voluntarily (by sending a "Host going down" to the IMP), theHost indicates his intention to come alive by sending the IMPsomething.  If the Host went down involuntarily (by dropping his readyline), the Host indicates his intention to come alive by bringing hisready line back up.  In either case                                                                [Page 1]

the IMP will refuse to accept more than one packet from the Host for30 seconds after the Host has indicated his intention to come alive.Notice, however, that the Host must be prepared to accept all messagesfrom the Network from the instant that he indicates his intention tocome alive.* This particular point seems to have given many Hostsdifficulty in running through their standard initializationprocedures.  Don't forget this simple and universal rule, that whenyou are telling your IMP that you are alive, you must be prepared toalways take every- thing from the Network whether or not the Networkis taking any- thing from you.    Version 2514 will also incorporate a few other changes, mainlyrelated to the operation of the NCC.  Since the Timeout is, for achange, being made shorter, and the other modifications are minor,there should be no appreciable transient with the coming of the newversion._______________*In fact, if the Host does not accept messages from his IMPpimmediately then the Host may see the IMP's Ready line go downfor 1/4 second sometime during the 30 second waiting period.This is due to the following set of circumstances:    *  The IMP periodically places NOPs on the queue for a       dead Host as part of the process of checking the IMP/Host       interface.    *  If a message remains on a Host's queue for 30 seconds       without being taken, the IMP drops its Ready line for       1/4 second in order to clear the interface (see RFC #270).    *  The timeout periods for the Host queue and the delay       when the Host comes alive are _not_ synchronized.If the Host is prepared to see the IMP's Ready line droppedduring the 30-second delay while coming alive, then no harmwill be done if messages from the IMP are not accepted immediately.BC/jm       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by BBN Corp. under the   ]       [ direction of Alex McKenzie.                   12/96   ]                                                                [Page 2]