summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc802.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc802.txt')
-rw-r--r--doc/rfc/rfc802.txt2672
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 -
+
+
+
+
+
+
+