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