/
►
RFC 802
This document is obsolete. Please
refer to
RFC 851 .
RFC 802 : The ARPANET 1822L Host Access Protocol
Andrew G. Malis
Netmail: malis@bbn-unix
Bolt Beranek and Newman Inc.
November 1981
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 -
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 -
1 INTRODUCTIONThis 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 -
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 -
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 contributedmany of the ideas found herein.
- 3 -
2 THE ARPANET 1822L HOST ACCESS PROTOCOLThe 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 -
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 -
2.1 Addresses and NamesThe 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 1822leaders. 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 -
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 EffectivenessEvery 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 -
2.3 Uncontrolled MessagesUncontrolled 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 -
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 FeatureThe 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 -
2.4.1 Host BlockingMost 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 -
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 BlockageThere 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 -
3.2 for a summary of the Incomplete Transmission message and acomplete 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 -
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 -
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 CommunicationsWhen 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 -
3 1822L LEADER FORMATSThe 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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -