IMP Status Messages: Two changes to the IMP/Host Protocol to improve user/network communications
Enhanced IMP-to-Host messages for better host status communication
Walden, D.C., "Two changes to the IMP/Host Protocol to improve user/network communications", RFC 611, DOI 10.17487/RFC0611, February 1974, <https://www.rfc-editor.org/info/rfc611>.
@misc{rfc611,
series = {Request for Comments},
number = 611,
howpublished = {RFC 611},
publisher = {RFC Editor},
doi = {10.17487/RFC0611},
url = {https://www.rfc-editor.org/info/rfc611},
author = {D.C. Walden},
title = {{Two changes to the IMP/Host Protocol to improve user/network communications}},
pagetotal = 4,
year = 1974,
month = feb,
} RFC text
Contents
Network Working Group D. Walden
RFC # 611 BBN-NET
NIC # 21354 February 14, 1974
TWO CHANGES T0 THE IMP/HOST PROTOCOL
TO IMPROVE USER/NETWORK COMMUNICATIONS*
1. A Reminder
When a host receives an IMP-Going Down message from its IMP (see
page 3-15 of BBN Report 1822, Specifications for the Interconnection of
a Host and an IMP), the Host should forward the information included in
the IMP-Going-Down message to its users from the network and its local
users of the network. Further, we suggest that the Host keep this
information around after the IMP has gone down, in order to tell local
users who are attempting to use the network.
In the next two sections of the RFC, we describe modifications to
the IMP/Host protocol which will allow the IMPs to distribute the same
sort 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 BBN
Report 1822 has not previously allowed for any provision by the Host for
additional information such as why, when, and for how long the Host is
going down. The following describes a modification to the Host-Going-
Down message which permits the Host to supply this additiona1
information.
In a type 2, Host-Going-Down message, bits 17-28 give the time of
the 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 that
report is updated.
All 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 than
a week away by setting bits 17-28 all to ones. Setting all bits 17-27
to one and bit 28 to zero means it is unknown when the host is coming
back up.
Bits 29-32 of the Host-Going-Down message should be used by the Host
to specify the reason it is going down. These bits are coded as
follows:
Value Meaning
----- -------
0-4 Reserved for IMP use (see Section 3 below)
5 Scheduled P.M.
6 Scheduled Hardware Work
7 Scheduled Software Work
8 Emergency Restart
9 Power Outage
10 Software Breakpoint
11 Hardware Failure
l2-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. Just
before going down, the Host should send the Host-Going-Down message to
its IMP. The IMP will store this message and return it to the source
Host along with Destination (Host) Dead messages. The IMP will try to
preserve this message over IMP reloads where appropriate. The NCC will
be able to update manually the stored copy of this message in response
to a phone call from the Host site in the event the Host is going to be
down longer than it said or if it didn't have time to say before going
down.
3. Addition of the Dead Host Status Message
The type 7, destination dead, message described on page 3-16 of BBN
Report 1822, does not allow for providing the reason for the Destination
Host's being "dead". An additional IMP to Host message is therefore
being added which provides status information on the dead Host. This
message is type 6, Dead Host Status, and will provide the additional
information as follows:
Bits 17-28 have the same meanings as bits 17-28 in the Host-Going-
Down message described in Section 2 above.
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 will
have the "unknown" indication.
Bit 1 in this message will always be set to zero and Hosts receiving
this message should discard without reporting an error type 6 messages
with bit 1 set to 1. This will allow later addition of similar status
information on dead destination IMPs.
The Dead Host Status message will be returned to the source Host
shortly (immediately, if possible) after each Destination Host Dead
message. The Destination Host Dead message applies to a specific
message-id (link) although the information contained in the Destination
Host Dead message should probably be reported to all users connected to
the dead Host. The Dead Host Status message does not apply to a
specific message-id (link) and all users connected to the dead Host
should be notified of the information contained in the Dead Host Status
message.
The modifications mentioned in Section 2 and 3 above will be put
into the network very soon, and we urge the Hosts to implement the code
necessary to take advantage of these modifications as soon as possible.
This modification is backward compatible with the exception (!) that
Hosts which have not done the implementation can receive a type 6
message which they do not know how To handle and will presumably log as
an 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 ]
AI ELI5
On this page
§1The Problem: Silent Shutdowns
The original IMP/Host protocol allowed a host to send a Host-Going-Down message to its IMP to announce that it was shutting down, but the message had no fields for additional information. Network operators and users would see a host disappear, with no explanation of whether it was intentional maintenance, a crash, a power failure, or something else. They had no way to know when the host would return.
For remote users trying to access that host, or for system administrators managing network traffic, this lack of information was frustrating and inefficient. Operators at the Network Control Center (NCC) might spend time trying to diagnose problems that were actually just scheduled maintenance.
When a computer shut down, it would say so, but it couldn't say why or when it would come back. That was confusing for everyone waiting for it to come back.
§2Two Protocol Enhancements
The RFC proposes two complementary changes to the IMP/Host protocol.
First, expand the Host-Going-Down message (type 2) to include two new pieces of information. Bits 17-28 encode the time when the host will come back up (the day of the week, the hour of the day, and the 5-minute interval within that hour, all in Universal Time/GMT). Bits 29-32 provide a reason code: values 0-4 are reserved for IMP use, but hosts can specify scheduled PM maintenance, scheduled hardware work, scheduled software work, emergency restart, power outage, software breakpoint, or hardware failure. If a host doesn't know when it will come back, it can set bits 17-27 all to ones and bit 28 to zero.
Second, add a new Dead Host Status message (type 6) that the IMP can send to a source host to explain why a destination host is unreachable. This message carries the same timing and reason code information, allowing the source host to inform its users of what happened to the destination host. The RFC specifies different reason codes for Dead Host Status, ranging from "IMP has no information" to specific causes like hardware failure, power outage, or scheduled maintenance.
Now a shutting-down computer can say when it will be back and why (like "we are fixing the hardware" or "power went out"). Also, when one computer asks another and finds it is down, the network can explain why it is down.
§3Deployment and Compatibility
The RFC notes that these modifications were to be deployed "very soon" and urges hosts to implement the new message types as quickly as possible. The changes are mostly backward compatible, with one exception: older hosts that had not been updated would receive type 6 (Dead Host Status) messages they did not know how to handle, and would likely log these as errors.
The RFC recommends that the NCC retain the Host-Going-Down message even after a host has shut down, so it can tell local users who try to access the down host why it is unavailable and when it will return. The NCC could even update the message by phone if a host took longer to restart than originally expected.
Everyone was supposed to start using these new messages soon. Some old computers might be confused by the new message types at first, but that was okay. The network staff could also change a shutdown message if the computer ended up taking longer to come back than it said.