doc: Add RFC documents

1 files changed, 2672 insertions, 0 deletions

diff --git a/doc/rfc/rfc802.txt b/doc/rfc/rfc802.txt
new file mode 100644
index 0000000..1efebcf
--- /dev/null
+++ b/doc/rfc/rfc802.txt
@@ -0,0 +1,2672 @@
+          		    
+            		      
+
+
+
+
+
+
+
+
+
+
+
+         RFC 802: The ARPANET 1822L Host Access Protocol
+
+
+
+
+
+
+
+
+                         Andrew G. Malis
+                     Netmail: malis@bbn-unix
+
+
+
+
+
+
+
+
+                  Bolt Beranek and Newman Inc.
+
+
+
+
+
+
+
+
+                          November 1981
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+                        Table of Contents
+
+
+
+
+1   INTRODUCTION.......................................... 1
+2   THE ARPANET 1822L HOST ACCESS PROTOCOL................ 4
+2.1   Addresses and Names................................. 6
+2.2   Name Authorization and Effectiveness................ 8
+2.3   Uncontrolled Messages.............................. 14
+2.4   The Short-Blocking Feature......................... 15
+2.4.1   Host Blocking.................................... 16
+2.4.2   Reasons for Host Blockage........................ 19
+2.5   Establishing Host-IMP Communications............... 22
+3   1822L LEADER FORMATS................................. 25
+3.1   Host-to-IMP 1822L Leader Format.................... 26
+3.2   IMP-to-Host 1822L Leader Format.................... 34
+4   REFERENCES........................................... 42
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              - i -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+                             FIGURES
+
+
+
+
+1822 Address Format....................................... 6
+1822L Name Format......................................... 7
+1822L Address Format...................................... 7
+Communications between different host types.............. 13
+Host-to-IMP 1822L Leader Format.......................... 27
+NDM Message Format....................................... 30
+IMP-to-Host 1822L Leader Format.......................... 35
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                             - ii -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+1  INTRODUCTION
+
+
+This document proposes two major changes to the  current  ARPANET
+
+host  access  protocol.  The first change will allow hosts to use
+
+logical addressing (i.e., host addresses that are independent  of
+
+their  physical location on the ARPANET) to communicate with each
+
+other, and the second will allow a host to shorten the amount  of
+
+time  that  it  may  be  blocked  by  its IMP after it presents a
+
+message to the network (currently,  the  IMP  can  block  further
+
+input from a host for up to 15 seconds).
+
+
+The new host access protocol is known as the ARPANET  1822L  (for
+
+Logical)  Host  Access Protocol, and it represents an addition to
+
+the current ARPANET 1822 Host Access Protocol, which is described
+
+in  sections  3.3  and  3.4 of BBN Report 1822 [1].  Although the
+
+1822L protocol uses different  Host-IMP  leaders  than  the  1822
+
+protocol,  hosts  using  either  protocol can readily communicate
+
+with each other (the IMPs handle the translation automatically).
+
+
+The new option for shortening the host blocking timeout is called
+
+the short-blocking feature, and it replaces the non-blocking host
+
+interface described in section 3.7 of Report 1822.  This  feature
+
+will  be  available  to  all  hosts  on  C/30  IMPs (see the next
+
+paragraph), regardless of whether they  use  the  1822  or  1822L
+
+protocol.
+
+
+
+                              - 1 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+There is one major restriction  to  the  new  capabilities  being
+
+described.   Both  the  1822L  protocol  and  the  short-blocking
+
+feature will be implemented on C/30 IMPs only, and will therefore
+
+only be useable by hosts connected to C/30 IMPs, as the Honeywell
+
+and Pluribus IMPs do not have sufficient memory to hold  the  new
+
+programs  and  tables.   This restriction also means that logical
+
+addressing cannot be used to address a host on  a  non-C/30  IMP.
+
+However, the ARPANET will shortly be completely converted to C/30
+
+IMPs, and at that time this  restriction  will  no  longer  be  a
+
+problem.
+
+
+I will try to keep my terminology consistent with  that  used  in
+
+Report  1822, and will define new terms when they are first used.
+
+Of course, familiarity with Report 1822 (section 3 in particular)
+
+is assumed.
+
+
+This document  makes  many  references  to  Report  1822.   As  a
+
+convenient  abbreviation,  I  will  use  "see 1822(x)" instead of
+
+"please refer to Report 1822, section x, for further details".
+
+
+This document is a proposal, not a description of an  implemented
+
+system.   Thus,  described  features  are subject to change based
+
+upon responses to this  document  and  restrictions  that  become
+
+evident  during  implementation.   However,  any such changes are
+
+expected to be minor.  A new RFC will be made available once  the
+
+
+
+                              - 2 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+implementation  is  complete containing the actual as-implemented
+
+description.
+
+
+Finally, I would like to thank Dr. Eric C. Rosen, who wrote  most
+
+of section 2.4, and James G. Herman, Dr. Paul J. Santos Jr., John
+
+F.  Haverty, and Robert M. Hinden, all of  BBN,  who  contributed
+
+many of the ideas found herein.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              - 3 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+2  THE ARPANET 1822L HOST ACCESS PROTOCOL
+
+
+The ARPANET  1822L  Host  Access  Protocol,  which  replaces  the
+
+ARPANET  1822  Host  Access  Protocol  described  in Report 1822,
+
+sections 3.3 and 3.4, allows a host to use logical addressing  to
+
+communicate  with other hosts on the ARPANET.  Basically, logical
+
+addressing allows hosts to refer to each  other  using  an  1822L
+
+name  (see section 2.1) which is independent of a host's physical
+
+location in the network.  IEN 183 (also published as  BBN  Report
+
+4473)  [2]  gives  the  use  of  logical  addressing considerable
+
+justification.  Among the advantages it cites are:
+
+
+o The ability to refer to each host on  the  network  by  a  name
+
+  independent of its location on the network.
+
+
+o Allowing different hosts to share  the  same  host  port  on  a
+
+  time-division basis.
+
+
+o Allowing a host to use multi-homing (where a single  host  uses
+
+  more than one port to communicate with the network).
+
+
+o And allowing several hosts that provide  the  same  service  to
+
+  share the same name.
+
+
+The main differences between the 1822 and 1822L protocols are the
+
+format of the leaders that are used to introduce messages between
+
+
+
+
+                              - 4 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+a host and an IMP, and the specification in those leaders of  the
+
+source  and/or  destination  host(s).   Hosts  have the choice of
+
+using the 1822 or the 1822L protocol.  When a host comes up on an
+
+IMP,  it declares itself to be an 1822 host or an 1822L host host
+
+by the type of NOP message (see section 3.1) it uses.   Once  up,
+
+hosts  can  switch  from  one protocol to the other by issuing an
+
+appropriate NOP.  Hosts that do not use the 1822L  protocol  will
+
+still  be  addressable by and can communicate with hosts that do,
+
+and vice-versa.
+
+
+Another difference between the two protocols  is  that  the  1822
+
+leaders are symmetric, while the 1822L leaders are not.  The term
+
+symmetric means that in the 1822 protocol, the exact same  leader
+
+format  is used for messages in both directions between the hosts
+
+and IMPs.  For example, a leader sent from a host  over  a  cable
+
+that  was  looped  back onto itself (via a looping plug or faulty
+
+hardware) would arrive back at the host and appear to be a  legal
+
+message  from  a  real host (the destination host of the original
+
+message).  In contrast, the 1822L headers are not symmetric,  and
+
+a  host  can  detect  if  the  connection to its IMP is looped by
+
+receiving a message with the wrong leader  format.   This  allows
+
+the host to take appropriate action upon detection of the loop.
+
+
+
+
+
+
+
+                              - 5 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+2.1  Addresses and Names
+
+
+The 1822 protocol defines one form of host specification, and the
+
+1822L  protocol  defines  two additional ways to identify network
+
+hosts.  These three forms are 1822 addresses,  1822L  names,  and
+
+1822L addresses.
+
+
+1822 addresses are  the  24-bit  host  addresses  found  in  1822
+
+leaders.  They have the following format:
+
+
+
+       1              8 9                              24
+      +----------------+---------------------------------+
+      |                |                                 |
+      |  Host number   |           IMP number            |
+      |                |                                 |
+      +----------------+---------------------------------+
+
+                 Figure 1. 1822 Address Format
+
+
+
+These fields are quite large, and the ARPANET will never use more
+
+than  a  fraction of the available address space.  1822 addresses
+
+are used in 1822 leaders only.
+
+
+1822L names are 16-bit unsigned numbers that serve as  a  logical
+
+identifier  for  one  or  more  hosts.   1822L  names have a much
+
+simpler format:
+
+
+
+
+
+
+
+
+                              - 6 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+
+
+
+                1                             16
+               +--------------------------------+
+               |                                |
+               |           1822L name           |
+               |                                |
+               +--------------------------------+
+
+                  Figure 2. 1822L Name Format
+
+
+
+The 1822L names are just 16-bit  unsigned  numbers,  except  that
+
+bits  1  and  2 are not both zeros (see below).  This allows over
+
+49,000 hosts to be specified.
+
+
+1822 addresses cannot be used in 1822L leaders, but there may  be
+
+a  requirement for an 1822L host to be able to address a specific
+
+physical host port or IMP fake host.  1822L  addresses  are  used
+
+for  this  function.   1822L addresses form a subset of the 1822L
+
+name space, and have both bits 1 and 2 off.
+
+
+
+               1   2  3          8 9             16
+             +---+---+------------+----------------+
+             |   |   |            |                |
+             | 0 | 0 |   host #   |   IMP number   |
+             |   |   |            |                |
+             +---+---+------------+----------------+
+
+                 Figure 3. 1822L Address Format
+
+
+
+
+
+
+
+
+                              - 7 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+This format gives 1822L hosts the  ability  to  directly  address
+
+hosts  0-59  at  IMPs 1-255 (IMP 0 does not exist).  Host numbers
+
+60-63 are reserved for addressing the four  fake  hosts  at  each
+
+IMP.
+
+
+
+
+2.2  Name Authorization and Effectiveness
+
+
+Every host on a C/30 IMP, regardless of whether it is  using  the
+
+1822 or 1822L protocol to access the network, will be assigned at
+
+least one 1822L name (logical address).  Other 1822L  hosts  will
+
+use  this name to address the host, wherever it may be physically
+
+located.  Because of the implementation constraints mentioned  in
+
+the introduction, hosts on non-C/30 IMPs cannot be assigned 1822L
+
+names.  To circumvent this restriction, however, 1822L hosts  can
+
+use  1822L addresses to access all other hosts on the network, no
+
+matter where they reside.
+
+
+At this point, several questions  arise:   How  are  these  names
+
+assigned,  how  do  they  become  known  to  the  IMPs  (so  that
+
+translations to physical addresses can be made), and how  do  the
+
+IMPs know which host is currently using a shared port?  To answer
+
+each question in order:
+
+
+
+
+
+
+
+                              - 8 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+Names are assigned by a central network administrator.  When each
+
+name  is  created, it is assigned to a host (or a group of hosts)
+
+at one or more specific host ports.  The host(s) are  allowed  to
+
+reside at those specific host ports, and nowhere else.  If a host
+
+moves, it will keep the same name, but the administrator  has  to
+
+update  the  central  database  to  reflect  the  new  host port.
+
+Changes to this database are  distributed  to  the  IMPs  by  the
+
+Network  Operations  Center  (NOC) at BBN.  For a while, the host
+
+may be allowed to reside at either of (or both) the new  and  old
+
+ports.   Once  the  correspondence between a name and one or more
+
+hosts ports where it may be used has been made  official  by  the
+
+administrator,   that  name  is  said  to  be  authorized.  1822L
+
+addresses, which actually  refer  to  physical  host  ports,  are
+
+always authorized in this sense.
+
+
+Once a host has been assigned one or more names, it  has  to  let
+
+the  IMPs  know  where it is and what name(s) it is using.  There
+
+are two cases to consider, one for 1822L hosts  and  another  for
+
+1822  hosts.   The following discussion only pertains to hosts on
+
+C/30 IMPs.
+
+
+When an IMP sees an 1822L host come up on a host  port,  the  IMP
+
+has  no way of knowing which host has just come up (several hosts
+
+may share the same port, or one host may prefer to  be  known  by
+
+
+
+
+                              - 9 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+different  names  at different times).  This requires the host to
+
+let the IMP know what is happening before it  can  actually  send
+
+and  receive messages.  This function is performed by a new host-
+
+to-IMP message, the Name Declaration Message (NDM),  which  lists
+
+the  names  that  the  host  would  like to be known by.  The IMP
+
+checks its tables to see if each of the names is authorized,  and
+
+sends an NDM Reply to the host saying which names in the list can
+
+be used for sending and receiving messages (i.e., which names are
+
+effective). A host can also use an NDM message to change its list
+
+of effective addresses (it can add to and delete from  the  list)
+
+at  any  time.  The only constraint on the host is that any names
+
+it  wishes  to  use  can  become  effective  only  if  they   are
+
+authorized.
+
+
+In the second case, if a host comes up on a C/30  IMP  using  the
+
+1822 protocol, the IMP automatically makes the first name the IMP
+
+finds in its tables for that host become effective.   Thus,  even
+
+though  the host is using the 1822 protocol, it can still receive
+
+messages from 1822L hosts via its 1822L name.  Of course, it  can
+
+also receive messages from an 1822L host via its 1822L address as
+
+well.   (Remember,  the  distinction  between  1822L  names   and
+
+addresses  is that the addresses correspond to physical locations
+
+on  the  network,  while   the   names   are   strictly   logical
+
+identifiers).   The  IMPs translate between the different leaders
+
+
+
+                             - 10 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+and send the proper leader in each case (more on this below).
+
+
+The third question above has by now already been answered.   When
+
+an  1822L  host comes up, it uses the NDM message to tell the IMP
+
+which host it is (which names it is known by).  Even if this is a
+
+shared port, the IMP knows which host is currently connected.
+
+
+Whenever a host goes down, its names  automatically  become  non-
+
+effective.   When it comes back up, it has to make them effective
+
+again.
+
+
+Several hosts can share the same 1822L name.  If more than one of
+
+these  hosts  is  up  at the same time, any messages sent to that
+
+1822L name will be delivered to just one  of  the  hosts  sharing
+
+that  name,  and  a RFNM will be returned as usual.  However, the
+
+sending host will  not  receive  any  indication  of  which  host
+
+received  the  message,  and subsequent messages to that name are
+
+not guaranteed to be sent to the  same  host.   Typically,  hosts
+
+providing  exactly  the  same  service could share the same 1822L
+
+name in this manner.
+
+
+Similarly, when a host is multi-homed, the same  1822L  name  may
+
+refer  to  more  than  one  host  port (all connected to the same
+
+host).  If the host is up on only one of those ports,  that  port
+
+will  be  used for all messages addressed to it.  However, if the
+
+
+
+
+                             - 11 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+host were up  on  more  than  one  port,  the  message  would  be
+
+delivered  over  just  one  of  those ports, and the subnet would
+
+choose which port to use.  This port selection could change  from
+
+message  to  message.   If  a  host wanted to insure that certain
+
+messages were delivered to it on specific ports,  these  messages
+
+could  use  either  the  port's 1822L address or a specific 1822L
+
+name that referred to that port alone.
+
+
+Some further details are required on communications between  1822
+
+and  1822L  hosts.   Obviously, when 1822 hosts converse, or when
+
+1822L hosts converse, no conversions between leaders and  address
+
+formats  are  required.   However,  this becomes more complicated
+
+when 1822 and 1822L hosts converse with each other.
+
+
+The   following   figure   illustrates   how   these   addressing
+
+combinations  are  handled,  showing  how  each  type of host can
+
+access every other type of host.  There are three types of hosts:
+
+"1822  on  C/30"  signifies  an  1822 host that is on a C/30 IMP,
+
+"1822L" signifies an 1822L host (on a C/30  IMP),  and  "1822  on
+
+non-C/30"  signifies  a  host  on  an  non-C/30 IMP (which cannot
+
+support the 1822L protocol).  The table entry shows the  protocol
+
+and  host address format(s) that the source host can use to reach
+
+the destination host.
+
+
+
+
+
+
+                             - 12 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+
+
+
+                            Destination Host
+  Source
+  Host    | 1822 on C/30   | 1822L          | 1822 on non-C/30
+  --------+----------------+----------------+-----------------
+          |                |                |
+  1822 on | 1822           | 1822           | 1822
+  C/30    |                | (note 1)       |
+          |                |                |
+  --------+----------------+----------------+-----------------
+          |                |                |
+          | 1822L, using   | 1822L, using   | 1822L, using
+  1822L   | 1822L name or  | 1822L name or  | 1822L address
+          |address (note 2)| address        | only (note 2)
+          |                |                |
+  --------+----------------+----------------+-----------------
+          |                |                |
+  1822 on | 1822           | 1822           | 1822
+  non-C/30|                | (note 1)       |
+          |                |                |
+  --------+----------------+----------------+-----------------
+
+  Note 1: The message is presented  to  the  destination  host
+          with  an 1822L leader containing the 1822L addresses
+          of the source  and  destination  hosts.   If  either
+          address  cannot be encoded as an 1822L address, then
+          the message is not delivered and and  error  message
+          is sent to the source host.
+
+  Note 2: The message is presented  to  the  destination  host
+          with  an  1822 leader containing the 1822 address of
+          the source host.
+
+
+     Figure 4. Communications between different host types
+
+
+
+
+
+
+
+
+
+
+
+
+                             - 13 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+2.3  Uncontrolled Messages
+
+
+Uncontrolled messages (see 1822(3.6)) present  a  unique  problem
+
+for  the  1822L  protocol.  Uncontrolled messages use none of the
+
+normal ordering and error-control mechanisms in the IMP,  and  do
+
+not  use  the  normal  subnetwork  connection  facilities.   As a
+
+result, uncontrolled messages need to carry all of their overhead
+
+with  them, including source and destination addresses.  If 1822L
+
+addresses  are  used  when  sending  an   uncontrolled   message,
+
+additional information is now required by the subnetwork when the
+
+message is transferred to the destination IMP.  This  means  that
+
+less  host-to-host  data  can be contained in the message than is
+
+possible between 1822 hosts.
+
+
+Uncontrolled messages  that  are  sent  between  1822  hosts  may
+
+contain  not  more  than 991 bits of data.  Uncontrolled messages
+
+that are sent to and/or from 1822L hosts are limited to  32  bits
+
+less,  or  not  more  than  959  bits.  Messages that exceed this
+
+length will result in an error indication to the  host,  and  the
+
+message  will  not  be sent.  This error indication represents an
+
+enhancement to the previous level of service provided by the IMP,
+
+which  would  simply  discard an overly long uncontrolled message
+
+without notification.
+
+
+
+
+
+
+                             - 14 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+Other enhancements that are  provided  for  uncontrolled  message
+
+service  are  a  notification  to the host of any message-related
+
+errors that are detected by the host's IMP when it  receives  the
+
+message.   A  host  will  be  notified if an uncontrolled message
+
+contains an error in the 1822L name specification,  such  as  the
+
+name  not being authorized or effective, or if the remote host is
+
+unreachable (which is  indicated  by  none  of  its  names  being
+
+effective),  or  if  network  congestion  control  throttled  the
+
+message before it left the source IMP.   The  host  will  not  be
+
+notified  if  the  uncontrolled  message was lost for some reason
+
+once it was transmitted by the source IMP.
+
+
+
+
+2.4  The Short-Blocking Feature
+
+
+The short-blocking feature of the 1822  and  1822L  protocols  is
+
+designed  to  allow a host to present messages to the IMP without
+
+causing the IMP to not accept further messages from the host  for
+
+long amounts of time (up to 15 seconds).  It is a replacement for
+
+the non-blocking host interface described in 1822(3.7), and  that
+
+description should be ignored.
+
+
+
+
+
+
+
+
+
+
+                             - 15 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+2.4.1  Host Blocking
+
+
+Most commonly, when a source host submits a message  to  an  IMP,
+
+the  IMP  immediately  processes that message and sends it on its
+
+way to its destination host.  Sometimes, however, the IMP is  not
+
+able  to  process  the message immediately.  Processing a message
+
+requires a significant number of resources, and when the  network
+
+is heavily loaded, there can sometimes be a long delay before the
+
+necessary resources become available.  In  such  cases,  the  IMP
+
+must  make  a decision as to what to do while it is attempting to
+
+gather the resources.
+
+
+One possibility is for the IMP to stop  accepting  messages  from
+
+the  source  host  until  it has gathered the resources needed to
+
+process the message just submitted.  This strategy  is  known  as
+
+blocking  the  host,  and is basically the strategy that has been
+
+used in the ARPANET up to the present.  When  a  host  submits  a
+
+message  to  an  IMP, all further transmissions from that host to
+
+that IMP are blocked until the message can be processed.
+
+
+It is important to note, however, that not all  messages  require
+
+the  same  set  of resources in order to be processed by the IMP.
+
+The particular set of resources needed will depend on the message
+
+type, the message length, and the destination host of the message
+
+(see below).  Therefore, although it might take a  long  time  to
+
+
+
+                             - 16 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+gather  the  resources needed to process some particular message,
+
+it might take only a short time to gather the resources needed to
+
+process  some  other  message.   This  fact exposes a significant
+
+disadvantage in the strategy of blocking the host.  A host  which
+
+is  blocked may have many other messages to submit which, if only
+
+they could be submitted, could be processed immediately.   It  is
+
+"unfair"  for  the IMP to refuse to accept these message until it
+
+has gathered the resources for  some  other,  unrelated  message.
+
+Why  should messages for which the IMP has plenty of resources be
+
+delayed for an arbitrarily long amount of time just  because  the
+
+IMP lacks the resources needed for some other message?
+
+
+A simple way to alleviate the problem would be to place  a  limit
+
+on  the  amount of time during which a host can be blocked.  This
+
+amount  of  time  should  be  long  enough  so  that,   in   most
+
+circumstances,  the  IMP  will  be  able  to gather the resources
+
+needed to process the message within the given time period.   If,
+
+however, the resources cannot be gathered in this period of time,
+
+the IMP will flush the message, sending a  reply  to  the  source
+
+host   indicating   that  the  message  was  not  processed,  and
+
+specifying the reason that it could not be  processed.   However,
+
+the  resource gathering process would continue.  The intention is
+
+that the host  resubmit  the  message  in  a  short  time,  when,
+
+hopefully,   the   resource   gathering   process  has  concluded
+
+
+
+                             - 17 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+successfully.   In  the  meantime,  the  host  can  submit  other
+
+messages,  which may be processed sooner.  This strategy does not
+
+eliminate the phenomenon of host blocking, but  only  limits  the
+
+time  during  which  a  host is blocked.  This shorter time limit
+
+will generally fall somewhere in the range of 100 milliseconds to
+
+2  seconds,  with  its value possibly depending on the reason for
+
+the blocking.
+
+
+Note, however, that there  is  a  disadvantage  to  having  short
+
+blocking  times.  Let us say that the IMP accepts a message if it
+
+has all the resources needed to process it.  The ARPANET provides
+
+a  sequential  delivery  service,  whereby messages with the same
+
+priority, source host, and destination host are delivered to  the
+
+destination  host in the same order as they are accepted from the
+
+source host.  With short blocking times, however,  the  order  in
+
+which  the  IMP accepts messages from the source host need not be
+
+the same as  the  order  in  which  the  source  host  originally
+
+submitted  the messages.  Since the two data streams (one in each
+
+direction) between the host and the IMP are not synchronized, the
+
+host  may  not  receive the reply to a rejected message before it
+
+submits subsequent messages of the same  priority  for  the  same
+
+destination host.  If a subsequent message is accepted, the order
+
+of acceptance differs from the order of original submission,  and
+
+the ARPANET will not provide the same type of sequential delivery
+
+
+
+                             - 18 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+that it has in the past.
+
+
+Up to now, type 0 (regular)  messages  have  only  had  sub-types
+
+available  to  request the standard blocking timeout.  The short-
+
+blocking feature makes available new  sub-types  that  allow  the
+
+host  to  request  messages to be short-blocking, i.e. only cause
+
+the host to be blocked for a short amount of time if the  message
+
+cannot be immediately processed.   See section 3.1 for a complete
+
+list of the available sub-types.
+
+
+If sequential delivery by the subnet is a strict requirement,  as
+
+would  be  the  case  for  messages  produced  by NCP, the short-
+
+blocking feature cannot be used.  For messages produced  by  TCP,
+
+however,  the  use  of  the short-blocking feature is allowed and
+
+recommended.
+
+
+
+
+2.4.2  Reasons for Host Blockage
+
+
+There are a number of reasons why a message could  cause  a  long
+
+blockage  in  the  IMP,  which would result in the rejection of a
+
+short-blocking message.  The IMP  signals  this  rejection  of  a
+
+short-blocking message by using the Incomplete Transmission (Type
+
+9) message, using the sub-type field to  indicate  which  of  the
+
+above  reasons  caused the rejection of the message.  See section
+
+
+
+
+                             - 19 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+3.2 for a summary of the Incomplete Transmission  message  and  a
+
+complete  list of its sub-types.  The sub-types that apply to the
+
+short-blocking feature are:
+
+
+6.  Connection setup-delay: Although the IMP  presents  a  simple
+
+    message-at-a-time  interface  to  the  host,  it  provides an
+
+    internal  connection-oriented  (virtual   circuit)   service,
+
+    except  in  the  case  of  uncontrolled messages (see section
+
+    2.3).   Two  messages  are  considered  to  be  on  the  same
+
+    connection  if they have the same source host (i.e., they are
+
+    submitted to the same IMP over the same host interface),  the
+
+    same priority, and the same destination host name or address.
+
+    The subnet maintains internal connection set-up and tear-down
+
+    procedures.   Connections  are set up as needed, and are torn
+
+    down  only  after  a  period  of  inactivity.   Occasionally,
+
+    network  congestion or resource shortage will cause a lengthy
+
+    delay in connection set-up.  During this period, no  messages
+
+    for  that  connection can be accepted, but other messages can
+
+    be accepted.
+
+
+7.  End-to-end flow  control:  For  every  message  that  a  host
+
+    submits  to  an  IMP  (except  uncontrolled messages) the IMP
+
+    eventually  returns  a  reply  to  the  host  indicating  the
+
+    disposition  of  the  message.   Between  the  time  that the
+
+
+
+
+                             - 20 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+    message is submitted and  the  time  the  host  receives  the
+
+    reply,  the  message  is  said to be outstanding. The ARPANET
+
+    allows  only  eight  outstanding  messages   on   any   given
+
+    connection.   If  there  are  eight outstanding messages on a
+
+    given connection, and a ninth is  submitted,  it  cannot  the
+
+    accepted.  If  a message is refused because its connection is
+
+    blocked due to flow control, messages  on  other  connections
+
+    can still be accepted.
+
+
+    End-to-end flow control is the  most  common  cause  of  host
+
+    blocking in the ARPANET at present.
+
+
+8.  Destination IMP buffer space shortage: If the host submits  a
+
+    message  of  more  than  1008  bits  (exclusive of the 96-bit
+
+    leader), buffer space at the destination IMP must be reserved
+
+    before  the  message  can  be  accepted.  Buffer space at the
+
+    destination IMP is always reserved on a per-connection basis.
+
+    If  the  destination  IMP  is  heavily loaded, there may be a
+
+    lengthy wait for the buffer space;  this  is  another  common
+
+    cause  of  blocking  in  the  present  ARPANET.  Messages are
+
+    rejected  for  this  reason  based  on   their   length   and
+
+    connection;  messages  of  1008 or fewer bits or messages for
+
+    other connections may still be acceptable.
+
+
+
+
+
+
+                             - 21 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+9.  Congestion control: A message may be refused for  reasons  of
+
+    congestion  control if the path via the intermediate IMPs and
+
+    lines to the destination IMP is too heavily loaded to  handle
+
+    additional  traffic.   Messages  to other destinations may be
+
+    acceptable, however.
+
+
+10.  Local resource shortage: Sometimes the source IMP itself  is
+
+    short  of buffer space, table entries, or some other resource
+
+    that it needs to accept a message.  Unlike the other  reasons
+
+    for message rejection, this resource shortage will affect all
+
+    messages equally,  except  for  uncontrolled  messages.   The
+
+    message's size or connection is not relevant.
+
+
+The short-blocking feature is available  to  all  hosts  on  C/30
+
+IMPs,  whether they are using the 1822 or 1822L protocol, through
+
+the use of Type 0, sub-type 1 and 2 messages.  A host using these
+
+sub-types  should  be  prepared  to  correctly  handle Incomplete
+
+Transmission messages from the IMP.
+
+
+
+
+2.5  Establishing Host-IMP Communications
+
+
+When a host comes up on an IMP, or after there has been  a  break
+
+in   the  communications  between  the  host  and  its  IMP  (see
+
+1822(3.2)), the orderly flow of messages between the host and the
+
+
+
+
+                             - 22 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+IMP  needs  to  be properly (re)established.  This allows the IMP
+
+and host to recover from most any failure  in  the  other  or  in
+
+their communications path, including a break in mid-message.
+
+
+The first messages that a host should send to its IMP  are  three
+
+NOP  messages.   Three  messages  are  required to insure that at
+
+least one message will be properly read by the IMP (the first NOP
+
+could be concatenated to a previous message if communications had
+
+been broken in mid-stream, and the third provides redundancy  for
+
+the   second).    These   NOPs   serve  several  functions:  they
+
+synchronize the IMP with the host, they tell  the  IMP  how  much
+
+padding  the  host  requires  between  the message leader and its
+
+body, and they also tell the IMP whether the host will  be  using
+
+1822 or 1822L leaders.
+
+
+Similarly, the IMP will send three  NOPs  to  the  host  when  it
+
+detects  that  the host has come up.  Actually, the IMP will send
+
+six NOPs, alternating three 1822  NOPs  with  three  1822L  NOPs.
+
+Thus, the host will see three NOPs no matter which protocol it is
+
+using.   The  NOPs  will  be  followed  by  two  Interface  Reset
+
+messages,  one of each style.  If the IMP receives a NOP from the
+
+host while the above sequence is occurring,  the  IMP  will  only
+
+send  the  remainder  of  the NOPs and the Interface Reset in the
+
+proper style.  The 1822 NOPs will contain the 1822 address of the
+
+
+
+
+                             - 23 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+host interface, and the 1822L NOPs will contain the corresponding
+
+1822L address.
+
+
+Once the IMP  and  the  host  have  sent  each  other  the  above
+
+messages, regular communications can commence.  See 1822(3.2) for
+
+further details concerning the ready line,  host  tardiness,  and
+
+other issues.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                             - 24 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+3  1822L LEADER FORMATS
+
+
+The following sections describe the formats of the  leaders  that
+
+precede  messages  between  an 1822L host and its IMP.  They were
+
+designed to be as compatible with the 1822 leaders  as  possible.
+
+The  second,  fifth,  and  sixth  words  are identical in the two
+
+leaders, and all  of  the  existing  functionality  of  the  1822
+
+leaders has been retained.  The first difference one will note is
+
+in the first word.  The 1822 New Format Flag is now also used  to
+
+identify  the  two  types of 1822L leaders, and the Handling Type
+
+has been moved to the second byte.  The third  and  fourth  words
+
+contain the Source and Destination 1822L Name, respectively.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                             - 25 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+3.1  Host-to-IMP 1822L Leader Format
+
+
+
+
+
+               1      4 5      8 9             16
+              +--------+--------+----------------+
+              |        |  1822L |                |
+              | Unused |  H2I   | Handling Type  |
+              |        |  Flag  |                |
+              +--------+--------+----------------+
+               17    20 21 22 24 25            32
+              +--------+-+------+----------------+
+              |        |T|Leader|                |
+              | Unused |R|Flags |  Message Type  |
+              |        |C|      |                |
+              +--------+-+------+----------------+
+               33                              48
+              +----------------------------------+
+              |                                  |
+              |           Source Host            |
+              |                                  |
+              +----------------------------------+
+               49                              64
+              +----------------------------------+
+              |                                  |
+              |         Destination Host         |
+              |                                  |
+              +----------------------------------+
+               65                     76 77    80
+              +-------------------------+--------+
+              |                         |        |
+              |       Message ID        |Sub-type|
+              |                         |        |
+              +-------------------------+--------+
+               81                              96
+              +----------------------------------+
+              |                                  |
+              |              Unused              |
+              |                                  |
+              +----------------------------------+
+
+           Figure 5. Host-to-IMP 1822L Leader Format
+
+
+
+
+
+                             - 26 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+Bits 1-4: Unused, must be set to zero.
+
+
+Bits 5-8: 1822L Host-to-IMP Flag:
+
+     This field is set to decimal 13 (1101 in binary).
+
+
+Bits 9-16: Handling Type:
+
+     This  field  is  bit-coded  to  indicate  the   transmission
+
+     characteristics  of  the connection desired by the host. See
+
+     1822(3.3).
+
+     Bit 9: Priority Bit:
+
+          Messages with this bit on will be treated  as  priority
+
+          messages.
+
+     Bits 10-16: Unused, must be zero.
+
+
+Bits 17-20: Unused, must be zero.
+
+
+Bit 21: Trace Bit:
+
+     If equal to one, this message is designated for  tracing  as
+
+     it proceeds through the network.  See 1822(5.5).
+
+
+Bits 22-24: Leader Flags:
+
+     Bit 22: A flag available for use by  the  destination  host.
+
+          See 1822(3.3) for a description of its use by the IMP's
+
+          TTY fake host.
+
+     Bits 23-24: Reserved for future use, must be zero.
+
+
+
+
+
+                             - 27 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+Bits 25-32: Message Type:
+
+     Type 0: Regular Message  -  All  host-to-host  communication
+
+          occurs  via  regular  messages, which have several sub-
+
+          types, found in bits 77-80.  These sub-types are:
+
+          0: Standard - The IMP uses its full message  and  error
+
+               control facilities, and host blocking (see section
+
+               2.4) may occur.
+
+          1: Standard, short-blocking - See section 2.4.
+
+          2: Uncontrolled, short-blocking - See section 2.4.
+
+          3: Uncontrolled - The  IMP  will  perform  no  message-
+
+               control  functions  for  this type of message, and
+
+               network flow and congestion control  (see  section
+
+               2.4)  may  cause  loss  of  the message.  Also see
+
+               1822(3.6) and section 2.3.
+
+          4-15: Unassigned.
+
+     Type 1: Error Without Message ID - See 1822(3.3).
+
+     Type 2: Host Going Down - see 1822(3.3).
+
+     Type 3: Name Declaration Message (NDM)  -  This  message  is
+
+          used by the host to declare which of its 1822L names is
+
+          or is not effective (see section 2.2), or to  make  all
+
+          of  its  names non-effective.  The first 16 bits of the
+
+          data portion of the NDM message, following  the  leader
+
+          and  any  padding,  contains  the  number of 1822L name
+
+
+
+
+                             - 28 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+          entries contained in the message.  This is followed  by
+
+          the 1822L name entries, each 32 bits long, of which the
+
+          first 16 bits is a 1822L name and the  second  16  bits
+
+          contains  either  of  the  integers  zero or one.  Zero
+
+          indicates that the name should not  be  effective,  and
+
+          one  indicates  that the name should be effective.  The
+
+          IMP will reply with a NDM Reply  message  (see  section
+
+          3.2)  indicating  which  of the names are now effective
+
+          and which are not.  Pictorially, a NDM message has  the
+
+          following   format  (including  the  leader,  which  is
+
+          printed in hexadecimal):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                             - 29 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+
+
+
+            1             16 17            32 33            48
+           +----------------+----------------+----------------+
+           |                |                |                |
+           |      0D00      |      0003      |      0000      |
+           |                |                |                |
+           +----------------+----------------+----------------+
+            49            64 65            80 81            96
+           +----------------+----------------+----------------+
+           |                |                |                |
+           |      0000      |      0000      |      0000      |
+           |                |                |                |
+           +----------------+----------------+----------------+
+            97           112 113          128 129          144
+           +----------------+----------------+----------------+
+           |                |                |                |
+           |  # of entries  |  1822L name #1 |     0 or 1     |
+           |                |                |                |
+           +----------------+----------------+----------------+
+           145           160 161          176
+           +----------------+----------------+
+           |                |                |
+           |  1822L name #2 |     0 or 1     |       etc.
+           |                |                |
+           +----------------+----------------+
+
+                  Figure 6. NDM Message Format
+
+
+
+          An  NDM  with  zero  entries  will  cause  all  current
+
+          effective names for the host to become non-effective.
+
+     Type 4: NOP - This allows the IMP to  know  which  style  of
+
+          leader  the  host wishes to use.  A 1822L NOP signifies
+
+          that the host wishes to use 1822L leaders, and an  1822
+
+          NOP signifies that the host wishes to use 1822 leaders.
+
+          All of the other remarks concerning the NOP message  in
+
+
+
+
+                             - 30 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+          1822(3.3)  still  hold.   The  host should always issue
+
+          NOPs in groups of three to insure proper  reception  by
+
+          the IMP.  Also see section 2.5 for a further discussion
+
+          on the use of the NOP message.
+
+     Type 8: Error with Message ID - see 1822(3.3).
+
+     Types 5-7,9-255: Unassigned.
+
+
+Bits 33-48: Source Host:
+
+     This field contains one of the  source  host's  1822L  names
+
+     (or,  alternatively,  the 1822L address of the host port the
+
+     message  is  being  sent   over).    This   field   is   not
+
+     automatically filled in by the IMP, as in the 1822 protocol,
+
+     because the host may be known by several names and may  wish
+
+     to use a particular name as the source of this message.  All
+
+     messages from the same host need not use the  same  name  in
+
+     this  field.   Each  source  name, when used, is checked for
+
+     authorization, effectiveness, and actually belonging to this
+
+     host.  Messages using names that do not satisfy all of these
+
+     requirements will not be delivered, and will instead  result
+
+     in  an  error  message being sent back into the source host.
+
+     If the host places its 1822L  Address  in  this  field,  the
+
+     address is checked to insure that it actually represents the
+
+     host port where the message originated.  If the  message  is
+
+     destined for an 1822 host on a non-C/30 IMP, this field MUST
+
+
+
+                             - 31 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+     contain the source host's 1822L address  (see  Figure  4  in
+
+     section 2.2).
+
+
+Bits 49-64: Destination Host:
+
+     This field  contains  the  1822L  name  or  address  of  the
+
+     destination  host.   If it contains a name, the name will be
+
+     checked for effectiveness, with an error message returned to
+
+     the  source  host  if  the  name  is  not effective.  If the
+
+     message is destined for an 1822 host on a non-C/30 IMP, this
+
+     field MUST contain the destination host's 1822L address (see
+
+     Figure 4 in section 2.2).
+
+
+Bits 65-76: Message ID:
+
+     This is a host-specified identification used in all  type  0
+
+     and  type  8  messages, and is also used in type 2 messages.
+
+     When used in type 0 messages, bits 65-72 are also  known  as
+
+     the  Link  Field,  and  should  contain  values specified in
+
+     Assigned  Numbers  [3]  appropriate  for  the   host-to-host
+
+     protocol being used.
+
+
+Bits 77-80: Sub-type:
+
+     This field is used as a modifier by message types 0,  2,  4,
+
+     and 8.
+
+
+
+
+
+
+
+                             - 32 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+Bits 81-96: Unused, must be zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                             - 33 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+3.2  IMP-to-Host 1822L Leader Format
+
+
+
+
+
+               1      4 5      8 9             16
+              +--------+--------+----------------+
+              |        |  1822L |                |
+              | Unused |  I2H   | Handling Type  |
+              |        |  Flag  |                |
+              +--------+--------+----------------+
+               17    20 21 22 24 25            32
+              +--------+-+------+----------------+
+              |        |T|Leader|                |
+              | Unused |R|Flags |  Message Type  |
+              |        |C|      |                |
+              +--------+-+------+----------------+
+               33                              48
+              +----------------------------------+
+              |                                  |
+              |           Source Host            |
+              |                                  |
+              +----------------------------------+
+               49                              64
+              +----------------------------------+
+              |                                  |
+              |         Destination Host         |
+              |                                  |
+              +----------------------------------+
+               65                     76 77    80
+              +-------------------------+--------+
+              |                         |        |
+              |       Message ID        |Sub-type|
+              |                         |        |
+              +-------------------------+--------+
+               81                              96
+              +----------------------------------+
+              |                                  |
+              |          Message Length          |
+              |                                  |
+              +----------------------------------+
+
+           Figure 7. IMP-to-Host 1822L Leader Format
+
+
+
+
+
+                             - 34 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+Bits 1-4: Unused and set to zero.
+
+
+Bits 5-8: 1822L IMP-to-Host Flag:
+
+     This field is set to decimal 14 (1110 in binary).
+
+
+Bits 9-16: Handling Type:
+
+     This has the value assigned by the source host (see  section
+
+     3.1).   This  field is only used in message types 0, 5-9, 11
+
+     and 15.
+
+
+Bits 17-20: Unused and set to zero.
+
+
+Bit 21: Trace Bit:
+
+     If equal to one, the source host designated this message for
+
+     tracing as it proceeds through the network.  See 1822(5.5).
+
+
+Bits 22-24: Leader Flags:
+
+     Bit 22: Available as a destination host flag.
+
+     Bits 23-24: Reserved for future use, set to zero.
+
+
+Bits 25-32: Message Type:
+
+     Type 0: Regular Message  -  All  host-to-host  communication
+
+          occurs  via  regular  messages, which have several sub-
+
+          types.  The sub-type field (bits 77-80) is the same  as
+
+          sent in the host-to-IMP leader (see section 3.1).
+
+     Type 1: Error in Leader - See 1822(3.4).
+
+
+
+
+                             - 35 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+     Type 2: IMP Going Down - See 1822(3.4).
+
+     Type 3: NDM Reply - This is a reply to the  NDM  host-to-IMP
+
+          message  (see  section  3.1).   It  will  have the same
+
+          number of entries as the  NDM  message  that  is  being
+
+          replying  to,  and  each  listed  1822L  name  will  be
+
+          accompanied by a zero or a one.  A zero signifies  that
+
+          the  name  is  not  effective, and a one means that the
+
+          name is now effective.
+
+     Type 4: NOP - The host should discard this message.   It  is
+
+          used    during    initialization    of   the   IMP/host
+
+          communication.  The Destination Host field will contain
+
+          the  1822L  Address of the host port over which the NOP
+
+          is being sent.  All other fields are unused.
+
+     Type 5: Ready for Next Message (RFNM) - See 1822(3.4).
+
+     Type 6: Dead Host Status - See 1822(3.4).
+
+     Type 7: Destination Host or IMP Dead  (or  unknown)  -  This
+
+          message  is  sent  in  response  to  a  message  for  a
+
+          destination which the IMP cannot reach.  The message to
+
+          the "dead" destination is discarded.  See 1822(3.4) for
+
+          a complete list of the applicable sub-types.   If  this
+
+          message  is in response to a standard (type 0, sub-type
+
+          0 or 1) message, it will be followed  by  a  Dead  Host
+
+          Status  message,  which gives further information about
+
+
+
+
+                             - 36 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+          the status of the dead host.  If  this  message  is  in
+
+          response  to  an uncontrolled (type 0, sub-type 2 or 3)
+
+          message, only sub-type 1 (The destination host  is  not
+
+          up) will be used, and it will not be followed by a Dead
+
+          Host Status message.
+
+     Type 8: Error in Data - See 1822(3.4).
+
+     Type 9: Incomplete Transmission - The  transmission  of  the
+
+          named  message  was  incomplete  for  some  reason.  An
+
+          incomplete transmission message is similar to  a  RFNM,
+
+          but  is  a  failure  indication  rather  than a success
+
+          indication.  This message is also used  by  the  short-
+
+          blocking feature to indicate that the named message was
+
+          rejected because it would have caused to IMP  to  block
+
+          the  host  for  a long amount of time.  See section 2.4
+
+          for more details concerning the short-blocking feature.
+
+          The message's sub-types are:
+
+          0: The destination host  did  not  accept  the  message
+
+               quickly enough.
+
+          1: The message was too long.
+
+          2: The host took more than 15 seconds to  transmit  the
+
+               message  to  the  IMP.  This time is measured from
+
+               the last bit of the leader through the last bit of
+
+               the message.
+
+
+
+
+                             - 37 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+          3: The message was lost in the network due  to  IMP  or
+
+               circuit failures.
+
+          4: The IMP could not accept the entire  message  within
+
+               15 seconds because of unavailable resources.  This
+
+               sub-type is only used in  response  to  non-short-
+
+               blocking  messages.   If  a short-blocking message
+
+               timed out, it will be responded to with one of the
+
+               sub-types 6-10.
+
+          5: Source IMP I/O failure occurred  during  receipt  of
+
+               this message.
+
+          Sub-types 6-10 are all issued in response to  a  short-
+
+          blocking  message that timed out (would have caused the
+
+          host to become blocked for a long amount of time).  The
+
+          sub-types are designed to give the host some indication
+
+          of why it timed out and what other messages would  also
+
+          time  out.   See  section  2.4.2  for  further  details
+
+          concerning each of these sub-types.
+
+          6: The message timed out because of  connection  set-up
+
+               delay.   Further  messages to the same host (if on
+
+               the same connection) may also be affected.
+
+          7: The message timed out  because  of  end-to-end  flow
+
+               control.  Further messages to the same host on the
+
+               same connection will also be affected.
+
+
+
+
+                             - 38 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+          8: Destination IMP buffer shortage caused  the  message
+
+               to  time  out.  This affects multi-packet standard
+
+               messages  to  the  specified  host,  but   shorter
+
+               messages  or  messages  to hosts on other IMPs may
+
+               not be affected.
+
+          9: Network congestion control caused the message to  be
+
+               rejected.  Messages to hosts on other IMPs may not
+
+               be affected, however.
+
+          10: Local resource shortage kept  the  IMP  from  being
+
+               able  to  accept  the  message  within  the short-
+
+               blocking timeout period.
+
+          11-15: Unassigned.
+
+     Type 10: Interface Reset - See 1822(3.4).
+
+     Type 15: 1822L Name or Address Error - This message is  sent
+
+          in  response  to  a  type  0  message  from a host that
+
+          contained an erroneous Source Host or Destination  Host
+
+          field.  Its sub-types are:
+
+          0: The Source Host 1822L name is not authorized or  not
+
+               effective.
+
+          1: The Source Host 1822L address  does  not  match  the
+
+               host port used to send the message.
+
+          2: The Destination Host 1822L name is not authorized.
+
+          3: The Destination Host 1822L name  is  authorized  but
+
+
+
+
+                             - 39 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+               not  effective,  even though the named host is up.
+
+               If the host were actually down, a type  7  message
+
+               would be returned, not a type 15.
+
+          4: The Source or  Destination  Host  field  contains  a
+
+               1822L  name,  but the host being addressed is on a
+
+               non-C/30 IMP (see Figure 4 in section 2.2).
+
+          5-15: Unassigned.
+
+     Types 11-14,16-255: Unassigned.
+
+
+Bits 33-48: Source Host:
+
+     For type 0 messages, this field contains the 1822L  name  or
+
+     address  of  the  host  that  originated  the  message.  All
+
+     replies to the message should be sent to the host  specified
+
+     herein.   For  message  types  5-9,  11  and  15, this field
+
+     contains the source host field used in  a  previous  type  0
+
+     message sent by this host.
+
+
+Bits 49-64: Destination Host:
+
+     For type 0 messages, this field contains the 1822L  name  or
+
+     address  that  the  message  was  sent  to.  This allows the
+
+     destination host to detect  how  it  was  specified  by  the
+
+     source  host.   For message types 5-9, 11 and 15, this field
+
+     contains the destination host field used in a previous  type
+
+     0 message sent by this host.
+
+
+
+
+                             - 40 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+Bits 65-76: Message ID:
+
+     For message types 0, 5, 7-9, 11 and 15, this  is  the  value
+
+     assigned  by  the  source  host to identify the message (see
+
+     section 3.1).  This field is also used by  message  types  2
+
+     and 6.
+
+
+Bits 77-80: Sub-type:
+
+     This field is used as a modifier by message types 0-2,  4-7,
+
+     9, 11 and 15.
+
+
+Bits 81-96: Message Length:
+
+     This field is contained in type 0 and type 3 messages  only,
+
+     and  is  the actual length in bits of the message (exclusive
+
+     of leader, leader padding, and hardware padding) as computed
+
+     by the IMP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                             - 41 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+4  REFERENCES
+
+
+[1]  Specifications for the Interconnection of a Host and an IMP,
+
+     BBN Report 1822, May 1978 Revision.
+
+
+[2]  E. C. Rosen et. al., ARPANET Routing Algorithm Improvements,
+
+     IEN  183 (also published as BBN Report 4473, Vol. 1), August
+
+     1980, pp. 55-107.
+
+
+[3]  J. Postel, Assigned Numbers, RFC 790, September 1981, p. 10.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                             - 42 -
+
+
+
+
+RFC 802                                           Andrew G. Malis
+
+
+
+                              INDEX
+
+
+
+
+1822...................................................... 4
+1822 address.............................................. 6
+1822 host................................................. 5
+1822L..................................................... 4
+1822L address............................................. 7
+1822L host................................................ 5
+1822L name................................................ 6
+authorized................................................ 9
+blocking................................................. 16
+congestion control................................... 22, 39
+connection........................................... 20, 38
+destination host..................................... 32, 40
+effective................................................ 10
+flow control......................................... 20, 38
+handing type......................................... 27, 35
+incomplete transmission message...................... 19, 37
+leader flags......................................... 27, 35
+link field............................................... 32
+logical addressing........................................ 4
+message ID........................................... 32, 41
+message length........................................... 41
+message type......................................... 28, 35
+multi-homing.............................................. 4
+NDM.................................................. 10, 28
+NDM reply............................................ 10, 36
+NOC....................................................... 9
+NOP........................................... 5, 22, 30, 36
+outstanding.............................................. 21
+priority bit............................................. 27
+regular message...................................... 28, 35
+RFNM..................................................... 36
+short-blocking feature................................... 15
+short-blocking message............................... 19, 28
+source host.......................................... 31, 40
+standard message......................................... 28
+sub-type............................................. 32, 41
+symmetric................................................. 5
+trace bit............................................ 27, 35
+uncontrolled message................................. 14, 28
+
+
+
+
+
+                             - 43 -
+
+
+
+
+
+
+