Three aids to improved network operation
RFC 381

Document Type RFC - Unknown (July 1972; No errata)
Updated by RFC 394
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 381 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       J. McQuillan
Request for Comments: 381                                      D. Walden
NIC: 11151                                  Bolt Beranek and Newman Inc.
                                                            26 July 1972

                Three Aids To Improved Network Operation

1.  Scheduled Software Maintenance

   As the ARPA Network has grown larger, we have found it difficult to
   find times when necessary new software can be slipped into the
   network without disrupting anyone.  For instance, there is always
   intrasite traffic between the machines at MIT, and there is almost
   always traffic between the AMES TIP and IMP--the sun never sets on
   the ARPA Network.  To minimize unscheduled disruptions and to
   simultaneously let us do what we have to do, we propose to schedule 7
   A.M. - 8 A.M. eastern time every Tuesday as a time when the IMPs can
   be reloaded.  We will probably not use this period every Tuesday, but
   we do reserve this period every Tuesday.  The above period is in
   addition to the several hours a month already scheduled at each site
   for hardware preventative maintenance.

   Because a network user may not know when his machine is scheduled for
   maintenance or because he may forget and work through the Tuesday
   morning software period, we propose to generalize the IMP-Going-Down
   IMP-to-Host control message so it may be used to remind the user.
   This message (described in detail below) will contain information
   that the IMP is going down in m times five minutes, for n times 5
   minutes, for a given reason.  Hosts (and the TIP) should use this
   information to remind all their Network users that the IMP will be
   going down after the stated interval.

   Occasionally there is an emergency reason for restarting or reloading
   an IMP.  For instance, while three Hosts at a site are functioning
   well, one Host cannot communicate with the IMP.  This sort of
   situation sometimes requires the IMP to be restarted.  Such a restart
   will be preceded by several minutes by an IMP-Going-Down Message to
   allow working users to save their work in such a way that they can
   restart once the IMP is back up.

   In both of these cases, as well as cases where an IMP is performing
   so poorly that is must be shut down quickly, a type 2 IMP-to-HOST
   message will be transmitted to the HOST about 30 seconds before the
   IMP goes down.  Finally, of course, there may be occasions when the
   IMP crashes so quickly that no warning is given, but the IMP will
   never be intentionally shut down in this way.

Mc Quillan, et. al.                                             [Page 1]
RFC 381         Three Aids To Improved Network Operation    26 July 1972

2.  IMP-to-Host Communication

   There have long been complaints that the IMP-to-Host error messages
   were not precise enough or were just plain ambiguous.  In RFC #312 we
   proposed some additional error messages.  These and other IMP-to-Host
   message changes will be made on August 14, 1972 and we encourage
   Hosts to modify their NCP's as appropriate by then.  Unmodified NCPs
   will probably continue to work after this change, but each site
   should look into this question carefully.  The table below lists all
   the IMP-to-Host messages and clearly indicates the changes which will
   be made.

   Type      Old Meaning             New Meaning

    0        Regular Messages        Same

    1        Error without           Error in Leader of Host-to-
             identification          IMP Message
                                          Bits 31,32=00 - IMP's
                                          error flip-flop set on
                                          the first 32 bits of a
                                          Host-to-IMP message which
                                          the IMP therefore cannot
                                          identify
                                     Bits 31,32=01 - Host-to-IMP
                                          message too short (less
                                          than 32 bits)
                                     Bits 31,32=10 - illegal
                                          Host-to-IMP code

    2       IMP Going Down           IMP Going Down
                                          Bits 17-32 coded as follows:
                                          All bits zero - going down in
                                          30 sec.
                                     Bits 17,18=01 - scheduled
                                          hardware PM
                                     Bits 17,18=10 - scheduled
                                          software reload
                                     Bits 17,18=11 - emergency
                                          reload or restart
                                     Bits 19-22 - how soon the
                                          IMP is going down - in
Show full document text