Three aids to improved network operation
BBN reserves Tuesday mornings for IMP reloads, adds warnings before shutdowns and reworks the IMP-to-Host messages.
McQuillan, J.M., "Three aids to improved network operation", RFC 381, DOI 10.17487/RFC0381, July 1972, <https://www.rfc-editor.org/info/rfc381>.
@misc{rfc381,
series = {Request for Comments},
number = 381,
howpublished = {RFC 381},
publisher = {RFC Editor},
doi = {10.17487/RFC0381},
url = {https://www.rfc-editor.org/info/rfc381},
author = {J.M. McQuillan},
title = {{Three aids to improved network operation}},
pagetotal = 4,
year = 1972,
month = jul,
} RFC text
Contents
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.
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
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
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]
AI ELI5
On this page
§1Scheduled Software Maintenance
As the network grew, BBN found it difficult to slot in new software without disrupting anyone. There is always traffic between the machines at MIT and almost always between the AMES TIP and IMP, since the sun never sets on the ARPA Network. So BBN reserves 7 A.M. to 8 A.M. eastern time every Tuesday for reloading IMPs. It will probably not use the period every week, but it reserves it. This is on top of the several hours a month already scheduled at each site for hardware preventative maintenance.
Emergency restarts and reloads can still happen, and a restart will be preceded by several minutes of warning with an IMP-Going-Down message. In every case where the IMP is shut down intentionally, a type 2 IMP-to-Host message is sent about 30 seconds before it goes down. An IMP may crash too quickly to warn anyone, but it will never be intentionally shut down that way.
Every Tuesday morning at seven the helpers might switch off a machine for a little while. They only do it at that time so that nobody is surprised.
§2IMP-to-Host Messages
Users had long complained that IMP-to-Host error messages were not precise enough. The new meanings, which include the additions proposed in RFC 312, take effect on August 14, 1972. Hosts are encouraged to update their NCPs by then; unmodified NCPs will probably keep working, but each site should check.
The generalized type 2 IMP Going Down message uses bits 17 to 32. Bits 17,18 say why (01 scheduled hardware PM, 10 scheduled software reload, 11 emergency reload or restart), bits 19 to 22 say how soon in 5 minute units, and bits 23 to 32 say how long in 5 minute units. All bits zero means going down in 30 seconds. Hosts and the TIP should use it to remind their users.
The changes in summary: there is now exactly one IMP-to-Host message for each regular Host-to-IMP message; types 1, 2, 7 and 9 carry extra information; type 10 is added; types 3 and 6 are discarded. Type 9 now distinguishes, for example, a message too long (more than 8095 bits) from one too slow (more than 15 seconds between first and last bit).
The machine used to say only that something went wrong. Now it says what went wrong and when it will switch off, like a teacher giving a reason and a time instead of just saying no.
- 0Regular — Regular messages; unchanged.
- 1Error in leader — Error in the leader of a Host-to-IMP message.
- 2IMP Going Down — Now carries the reason, how soon and how long.
- 3Unassigned — Was Blocked Link.
- 4NOF — Unchanged.
- 5RFNM — Unchanged.
- 6Unassigned — Was Link Table Full.
- 7Destination Dead — Bit 32 tells destination IMP dead from destination Host dead.
- 8Error in data — Error in the data bits of an identified Host-to-IMP message.
- 9Incomplete Transmission — Bits 31,32 give the cause.
- 10Interface Reset — IMP-Host interface reset; new type.
§3Network News Service
The third aid is a network news service. TIP users read the news by typing the command @NEWS. Users of other hosts can get it by ICPing to socket 15600031 (octal) at the BBN Tenex. The note ends by asking for further suggestions to improve network operation.
There is now a bulletin board for the network. You can read it by typing a short command, and others can visit the right door number.