1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc611.txt b/doc/rfc/rfc611.txt
new file mode 100644
index 0000000..432f527
--- /dev/null
+++ b/doc/rfc/rfc611.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+Walden                                                          [Page 1]
+
+RFC 611               Changes to IMP/Host Protocol         February 1974
+
+
+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.
+
+
+
+
+
+
+Walden                                                          [Page 2]
+
+RFC 611               Changes to IMP/Host Protocol         February 1974
+
+
+    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.
+
+
+
+Walden                                                          [Page 3]
+
+RFC 611               Changes to IMP/Host Protocol         February 1974
+
+
+    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 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Walden                                                          [Page 4]
+