doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc381.txt b/doc/rfc/rfc381.txt
new file mode 100644
index 0000000..da7b21e
--- /dev/null
+++ b/doc/rfc/rfc381.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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 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
+
+
+
+Mc Quillan, et. al.                                             [Page 2]
+
+RFC 381         Three Aids To Improved Network Operation    26 July 1972
+
+
+
+    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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mc Quillan, et. al.                                             [Page 3]
+
+RFC 381         Three Aids To Improved Network Operation    26 July 1972
+
+
+   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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mc Quillan, et. al.                                             [Page 4]
+