Browse Prior Art Database

Three aids to improved network operation (RFC0381)

IP.com Disclosure Number: IPCOM000005387D
Original Publication Date: 1972-Jul-26
Included in the Prior Art Database: 2001-Sep-21
Document File: 5 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.M. McQuillan: AUTHOR

Abstract

1. Scheduled Software Maintenance

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 49% of the total text.

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 int...