Movatterモバイル変換

Network Working Group                                          D. WaldenRFC # 611                                                        BBN-NETNIC # 21354                                            February 14, 1974TWO CHANGES T0 THE IMP/HOST PROTOCOLTO IMPROVE USER/NETWORK COMMUNICATIONS*1.  A Reminder    When a host receives an IMP-Going Down message from its IMP (seepage 3-15 of BBN Report 1822, Specifications for the Interconnection ofa Host and an IMP), the Host should forward the information included inthe IMP-Going-Down message to its users from the network and its localusers of the network.  Further, we suggest that the Host keep thisinformation around after the IMP has gone down, in order to tell localusers who are attempting to use the network.    In the next two sections of the RFC, we describe modifications tothe IMP/Host protocol which will allow the IMPs to distribute the samesort of information about Hosts which are down.2.  Expansion of the Host-Going-Down Message    The type 2, Host-Going-Down, message described on page 3-1l of BBNReport 1822 has not previously allowed for any provision by the Host foradditional information such as why, when, and for how long the Host isgoing down. The following describes a modification to the Host-Going-Down message which permits the Host to supply this additiona1information.    In a type 2, Host-Going-Down message, bits 17-28 give the time ofthe Host's coming back up, bit-coded as follows:bits 17-19:  the day of the week the Host is coming back up. Monday is             day 0 and Sunday is day 6.bits 20-24:  the hour of the day, from hour 0 to hour 23, that the Host             is coming back up.bits 25-28:  the five minute interval, from 0 to 11, in the hour that             the Host is coning back up.----------*Please file this RFC with your copy of BBN Report 1822 until thatreport is updated.Walden                                                          [Page 1]

RFC 611               Changes to IMP/Host Protocol         February 1974All three of the above or to be specified in Universal time (i.e.,G.M.T.).  The Host may indicate that it will be coming back up more thana week away by setting bits 17-28 all to ones.  Setting all bits 17-27to one and bit 28 to zero means it is unknown when the host is comingback up.    Bits 29-32 of the Host-Going-Down message should be used by the Hostto specify the reason it is going down.  These bits are coded asfollows:Value     Meaning-----     -------0-4       Reserved for IMP use (seeSection 3 below)5         Scheduled P.M.6         Scheduled Hardware Work7         Scheduled Software Work8         Emergency Restart9         Power Outage10        Software Breakpoint11        Hardware Failurel2-15     Currently Unused    It is assumed that as the time for the Host to go down approaches,the Host itself will send warning messages to its network users.  Justbefore going down, the Host should send the Host-Going-Down message toits IMP.  The IMP will store this message and return it to the sourceHost along with Destination (Host) Dead messages.  The IMP will try topreserve this message over IMP reloads where appropriate.  The NCC willbe able to update manually the stored copy of this message in responseto a phone call from the Host site in the event the Host is going to bedown longer than it said or if it didn't have time to say before goingdown.3.  Addition of the Dead Host Status Message    The type 7, destination dead, message described on page 3-16 of BBNReport 1822, does not allow for providing the reason for the DestinationHost's being "dead".  An additional IMP to Host message is thereforebeing added which provides status information on the dead Host.  Thismessage is type 6, Dead Host Status, and will provide the additionalinformation as follows:    Bits 17-28 have the same meanings as bits 17-28 in the Host-Going-    Down message described inSection 2 above.Walden                                                          [Page 2]

RFC 611               Changes to IMP/Host Protocol         February 1974    Bits 29-32 have the following meanings:        Value  Meaning        -----  -------        0      The destination Host is not communicating with the               network -- the destination IMP has no information about               the cause.  Note that this is the message most likely to               occur if the destination IMP has gone down since the               destination Host went down.        1      The destination Host is not communicating with the               network -- it took its ready-line down without saying               why.        2      The destination Host is not communicating with the               network -- the Host was tardy in taking traffic from the               network and the network had to declare the Host down.        3      The destination Host does not exist to the knowledge of               the NCC.        4      Currently unused.        5      The destination Host is down for scheduled P.M.        6      The destination Host is down for scheduled hardware work.        7      The destination Host is down for scheduled software work.        8      The destination Host is down for emergency restart.        9      The destination Host is down because of power outage.        10     The destination host is stopped at a software breakpoint.        11     The destination Host is down because of a hardware               failure.        12-15  Currently unused.    When the value of this 4-bit field is 0,1,2, or 3, bits 17-28 willhave the "unknown" indication.    Bit 1 in this message will always be set to zero and Hosts receivingthis message should discard without reporting an error type 6 messageswith bit 1 set to 1.  This will allow later addition of similar statusinformation on dead destination IMPs.Walden                                                          [Page 3]

RFC 611               Changes to IMP/Host Protocol         February 1974    The Dead Host Status message will be returned to the source Hostshortly (immediately, if possible) after each Destination Host Deadmessage. The Destination Host Dead message applies to a specificmessage-id (link) although the information contained in the DestinationHost Dead message should probably be reported to all users connected tothe dead Host.  The Dead Host Status message does not apply to aspecific message-id (link) and all users connected to the dead Hostshould be notified of the information contained in the Dead Host Statusmessage.    The modifications mentioned inSection 2 and 3 above will be putinto the network very soon, and we urge the Hosts to implement the codenecessary to take advantage of these modifications as soon as possible.This modification is backward compatible with the exception (!) thatHosts which have not done the implementation can receive a type 6message which they do not know how To handle and will presumably log asan error.       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by Alex McKenzie with    ]       [ support from GTE, formerly BBN Corp.           1/2000 ]Walden                                                          [Page 4]