Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-1-1+1


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
                                   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
  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

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc381.txt · Last modified: 2001/09/19 23:14 (external edit)