RFC 611

1. A Reminder 🦋

RFC 611 ✨ Network Working Group · NIC # 21354 · February 14, 1974 Author: D. Walden, BBN-NET 💖 Title: TWO CHANGES T0 THE IMP/HOST PROTOCOL TO IMPROVE USER/NETWORK COMMUNICATIONS* The title block doesn't list a category, and it doesn't say this RFC obsoletes or updates anything. 🌸

Okay bestie, so when a host gets an IMP-Going Down message from its IMP (check page 3-15 of BBN Report 1822, Specifications for the Interconnection of a Host and an IMP), the host should pass that info along to its users on the network and to its local users too 📣. We also suggest the host keep that info around after the IMP goes down, so it can tell local users who try to use the network in the meantime 🫶.

Sections 2 and 3 are the glow-up. They describe changes to the IMP/Host protocol so the IMPs can share the same kind of info about hosts that are down 💅✨

2. Expansion of the Host-Going-Down Message 🎀

Here's the tea ☕. The type 2, Host-Going-Down, message (page 3-11 of BBN Report 1822) never let the host say why, when, or for how long it's going down 😭. This section fixes that by letting the host add all of that extra info 💜.

In a type 2, Host-Going-Down message, bits 17-28 tell everyone when the host is coming back up, bit-coded like this:

• bits 17-19: the day of the week the host comes 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, when the host comes back up 🕐
• bits 25-28: the five minute interval, from 0 to 11, within that hour when the host comes back up ⏰

*Please file this RFC with your copy of BBN Report 1822 until that report is updated. 📎

Okay, the three things above are all specified in Universal time (aka G.M.T.) 🌍. If the host is coming back more than a week away, it can set bits 17-28 all to ones 🙈. If it sets bits 17-27 to one and bit 28 to zero, that means the host doesn't know when it's coming back, which is so relatable 💀.

Bits 29-32 of the Host-Going-Down message should be used by the host to say why it's going down. Here's the code 👑:

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's assumed that as the go-down time gets close, the host will send warning messages to its network users himself, I mean itself 🫠. Right before going down, the host should send the Host-Going-Down message to its IMP. The IMP stores that message and sends it back to the source host along with Destination (Host) Dead messages 📬. The IMP will try to keep this message through IMP reloads where that makes sense 🔁. And the NCC can manually update the stored copy after a phone call from the host site, in case the host ends up down longer than it said, or if it didn't have time to say anything before going down 📞💖.

3. Addition of the Dead Host Status Message 🧚

The type 7, destination dead, message (page 3-16 of BBN Report 1822) doesn't let anyone say why the destination host is "dead" 😤. So a new IMP-to-Host message gets added to share status info on the dead host. It's type 6, Dead Host Status, and it gives the extra info like this 🌈:

Bits 17-28 mean the same thing as bits 17-28 in the Host-Going-Down message from Section 2 above ⏳.

Bits 29-32 mean this 💅:

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 this 4-bit field is 0, 1, 2, or 3, bits 17-28 get the "unknown" indication 🤷‍♀️.

⚠️ Bit 1 in this message will always be set to zero. Hosts that get this message should discard, without reporting an error, any type 6 messages with bit 1 set to 1. This leaves room for adding similar status info on dead destination IMPs later 🔮.

The Dead Host Status message gets sent back to the source host shortly after each Destination Host Dead message (immediately, if possible) 🏃‍♀️💨. The Destination Host Dead message applies to a specific message-id (link), but the info in it should probably be reported to all users connected to the dead host 📢. The Dead Host Status message doesn't apply to a specific message-id (link), so all users connected to the dead host should get the info in it 🫶.

Sections 2 and 3 are going into the network very soon, and we really urge hosts to write the code to use these changes ASAP 🚀. This change is backward compatible, with one exception (!) 😬: hosts that haven't implemented it can get a type 6 message they don't know how to handle, and they'll probably log it 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 ]