The RFC Archive
 The RFC Archive   RFC 381   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 381

Three aids to improved network operation

Last modified on Thursday, September 20th, 2001

Permanent link to RFC 381
Search GitHub Wiki for RFC 381
Show other RFCs mentioning RFC 381







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 top


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 5 minute units Bits 23-32 - how long the IMP will be down - in 5 minute units 3 Blocked Link Unassigned Mc Quillan, et. al. PAGE 2 top

RFC 381 Three Aids To Improved Network Operation 26 July 1972 4 NOF Same 5 RFNM Same 6 Link Table Full Unassigned 7 Destination Dead Destination Dead Bit 32=0 - the destination IMP is dead, or cannot be reached, or does not exist Bit 32=1 - the destination Host is dead or does not exist 8 Error with identi- Error in Data of Host-to IMP fication Message IMP's error flip-flop set on the data bits of a Host- to-IMP message identified by the given source and link 9 Incomplete Transmission Incomplete Transmission Bits 31,32=00 - the destination Host did not take the message for a long time Bits 31,32=01 - Host-to-IMP message too long (more than 8095 bits) Bits 31,32=10 - Host-to IMP message too slow. The last message took more than 15 secs. between the first bit and the last bit, and was discarded Bits 31,32=11 - Host-to- IMP message lost in the subnet Mc Quillan, et. al. PAGE 3 top

RFC 381 Three Aids To Improved Network Operation 26 July 1972 10 Unassigned IMP-Host Interface Reset The IMP's ready line has been dropped and pending output to the Host discarded (probably because the Host has not taken messages from the IMP for a long time). The IMP will return a type 1 message of subtype 0 at the completion of the next Host- to-IMP message. These changes can be summarized as follows: 1. There is now one and only one IMP-to-Host message in response to each Host-to-IMP regular message. 2. Message types 1, 2, 7 and 9 now carry additional information. 3. Message type 10 has been added. 4. Message types 3 and 6 have been discarded. 3. Network News Service We have instituted a Network news service. TIP users get the news by typing the TIP command @NEWS. Users of other Host can get the news by ICPing to socket 15600031 (octal) at the BBN Tenex. If you have further suggestions for improving the operation of the Network, we request your comments. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Lorrie Shiota 08/00] Mc Quillan, et. al. PAGE 4 top

Three aids to improved network operation RFC TOTAL SIZE: 9305 bytes PUBLICATION DATE: Thursday, September 20th, 2001 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 381: The IETF Trust, Thursday, September 20th, 2001
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement