RFC851 - ARPANET 1822L Host Access Protocol

2019-11-04 11:37:17

字体：大中小

来源：转载

供稿：网友

　　Request for Comments: 851
Obsoletes RFC: 802

The ARPANET 1822L Host access PRotocol

RFC851

Andrew G. Malis
ARPANET Mail: malis@bbn-unix

Bolt Beranek and Newman Inc.
50 Moulton St.
Cambridge, MA 02238

April 1983

This RFCspecifies the ARPANET 1822L Host Access Protocol, which
is a sUCcessor to the existing 1822 Host Access Protocol. 1822L
allows ARPANET hosts to use logical names as well as 1822's
physical port locations to address each other. The RFCis also
being presented as a solicitation of comments on 1822L,
especially from host network software implementers and
maintainers.

1822L Host Access Protocol April 1983
RFC851

Table of Contents

1 INTRODUCTION.......................................... 1
2 THE ARPANET 1822L HOST ACCESS PROTOCOL................ 4
2.1 Addresses and Names................................. 6
2.2 Name Translations................................... 8
2.2.1 Authorization and Effectiveness................... 8
2.2.2 Translation Policies............................. 11
2.2.3 Reporting Destination Host Downs................. 13
2.2.4 1822L and 1822 InterOperability.................. 16
2.3 Uncontrolled Packets............................... 18
2.4 Establishing Host-IMP Communications............... 20
2.5 Counting RFMS When Using 1822L..................... 22
2.6 1822L Name Server.................................. 24
3 1822L LEADER FORMATS................................. 27
3.1 Host-to-IMP 1822L Leader Format.................... 28
3.2 IMP-to-Host 1822L Leader Format.................... 35
4 REFERENCES........................................... 43

- i -

1822L Host Access Protocol April 1983
RFC851

FIGURES

1822 Address Format....................................... 6
1822L Name Format......................................... 7
1822L Address Format...................................... 7
Communications between different host types.............. 17
Host-to-IMP 1822L Leader Format.......................... 28
NDM Message Format....................................... 31
IMP-to-Host 1822L Leader Format.......................... 35
Name Server Reply Format................................. 39

- ii -

1822L Host Access Protocol April 1983
RFC851

1 INTRODUCTION

This RFCspecifies the ARPANET 1822L Host Access Protocol, which

will allow hosts to use logical addressing (i.e., host names that

are independent of their physical location on the ARPANET) to

communicate with each other. This new host access protocol is

known as the ARPANET 1822L (for Logical) Host Access Protocol,

and is a successor 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, the IMPs will continue

to support the 1822 protocol, and hosts using either protocol can

readily communicate with each other (the IMPs will handle the

translation automatically).

There is one major restriction to the new 1822L protocol: it

will be implemented in C/30 IMPs only, and will therefore only be

usable by hosts connected to C/30 IMPs, as 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 identify a host on a non-C/30 IMP. While this

is not a problem on the ARPANET, which only has C/30 IMPs, the

restriction will apply if logical addressing is used on any

network that mixes C/30 and non-C/30 IMPs.

- 1 -

1822L Host Access Protocol April 1983
RFC851

The RFC's terminology is consistent with that used in Report

1822, and any new terms will be defined when they are first used.

Familiarity with Report 1822 (section 3 in particular) is

assumed. As could be eXPected, the RFCmakes many references to

Report 1822. As a result, it uses, as a convenient abbreviation,

"see 1822(x)" instead of "please refer to Report 1822, section x,

for further details".

This RFCupdates, and obsoletes, RFC802. The changes from that

RFCinclude:

o The Short Blocking Feature, which had also been described in

RFC802, now has its own RFC, RFC852 [2]. It was moved to its

own RFC, since it is completely independent of logical

addressing.

o In section 2.2, descriptions of the three address selection

policies and of host error handling have been added.

o In section 2.3, the IMP's uncontrolled packet service has been

further improved. This applies to hosts using 1822 as well as

1822L.

o Pointers on using RFNM counting with 1822L have been added as

section 2.5.

- 2 -

1822L Host Access Protocol April 1983
RFC851

o Section 2.6 describes the new "1822L name server" in the IMP,

which makes use of two new Host-to-IMP messages to allow hosts

to do their own name-to-address mapping.

o In section 3.2, the suBTypes for the type 15 (1822L Name or

Address Error) IMP-to-Host message have been changed.

- 3 -

1822L Host Access Protocol April 1983
RFC851

2 THE ARPANET 1822L HOST ACCESS PROTOCOL

The ARPANET 1822L Host Access Protocol 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) [3] 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 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

a host and an IMP, and the specification in those leaders of the

source and/or destination host(s). Hosts have the choice of

- 4 -

1822L Host Access Protocol April 1983
RFC851

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

1822L Host Access Protocol April 1983
RFC851

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 -

1822L Host Access Protocol April 1983
RFC851

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

This format allows 1822L hosts to directly address hosts 0-63 at

IMPs 1-255 (IMP 0 does not exist). Note that the highest host

- 7 -

1822L Host Access Protocol April 1983
RFC851

numbers are reserved for addressing the IMP's internal fake

hosts. At this writing, the IMP has seven fake hosts, so host

numbers 57-63 address the IMP fake hosts, while host numbers 0-56

address real hosts external to the IMP. As the number of IMP

fake hosts changes, this boundary point will also change.

2.2 Name Translations

There are a number of factors that determine how an 1822L name is

translated by the IMP into a physical address on the network.

These factors include which translations are legal; in what order

different translations for the same name should be attempted;

which legal translations shouldn't be attempted because a

particular host port is down; and the interoperability between

1822 and 1822L hosts. These issues are discussed in the

following sections.

2.2.1 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, can have one or

more 1822L names (logical addresses). Hosts using 1822L can then

use these names to address the hosts in the network independent

of their physical locations. Because of the implementation

- 8 -

1822L Host Access Protocol April 1983
RFC851

constraints mentioned in the introduction, hosts on non-C/30 IMPs

cannot be assigned 1822L names. To circumvent this restriction,

however, 1822L hosts can also use 1822L addresses to access all

of the other hosts.

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:

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

- 9 -

1822L Host Access Protocol April 1983
RFC851

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

different names at different times). This requires the host to

declare itself to the IMP 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 were actually

authorized and can now 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 names (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

- 10 -

1822L Host Access Protocol April 1983
RFC851

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

and send the proper leader in each case (see section 2.2.4).

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.

2.2.2 Translation Policies

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

- 11 -

1822L Host Access Protocol April 1983
RFC851

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 the host. However, if

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

Three different address selection policies are available for the

name mapping process. When translated, each name uses one of the

three policies (the policy is pre-determined on a per-name

basis). The three policies are:

o Attempt each translation in the order in which the physical

addresses are listed in the IMP's translation tables, to find

- 12 -

1822L Host Access Protocol April 1983
RFC851

the first reachable physical host address. This list is

always searched from the top whenever an uncontrolled packet

is to be sent or an end-to-end connection has to be created.

This is the most commonly used policy.

o Selection of the closest physical address, which uses the

IMP's routing tables to find the translation to the

destination IMP with the least delay path.

o Use load leveling. This is similar to the second policy, but

differs in that searching the address list for a valid

translation starts at the address following where the previous

translation search ended. This attempts to spread out the

load from any one IMP's hosts to the various host ports

associated with a particular name. Note that this is NOT

network-wide load leveling, which would require a distributed

algorithm and tables.

2.2.3 Reporting Destination Host Downs

As was explained in report 1822, and as will be discussed in

greater detail in section 2.5, whenever regular messages are sent

by a host, the IMP opens a subnetwork connection to each

destination host from the source host. A connection will stay

open at least as long as there are any outstanding (un-RFNMed)

- 13 -

1822L Host Access Protocol April 1983
RFC851

messages using it and both the source and destination hosts stay

up.

However, the destination host may go down for some reason during

the lifetime of a connection. If the host goes down while there

are no outstanding messages to it in the network, then the

connection is closed and no other action is taken until the

source host submits the next message for that destination. At

that time, ONE of the following events will occur:

A1. If 1822 or an 1822L address is being used to specify the

destination host, then the source host will receive a type 7

(Destination Host Dead) message from the IMP.

A2. If an 1822L name is being used to specify the destination

host, and the name maps to only one authorized host port,

then a type 7 message will also be sent to the source host.

A3. If an 1822L name is being used to specify the destination

host, and the name maps to more than one authorized host

port, then the IMP attempts to open a connection to another

authorized and effective host port for that name. If no

such connection can be made, the host will receive a type 15

(1822L Name or Address Error), subtype 5 (no effective

translations) message (see section 3.2). Note that a type 7

message cannot be returned to the source host, since type 7

messages refer to a particular destination host port, and

- 14 -

1822L Host Access Protocol April 1983
RFC851

the name maps to more than one destination port.

Things get a bit more complicated if there are any outstanding

messages on the connection when the destination host goes down.

The connection will be closed, and one of the following will

occur:

B1. If 1822 or an 1822L address is being used to specify the

destination host, then the source host will receive a type 7

message for each outstanding message.

B2. If an 1822L name is being used to specify the destination

host, then the source host will receive a type 9 (Incomplete

Transmission), subtype 3 (message lost due to network

failure) message for each outstanding message. The next

time the source host submits another message for that same

destination name, the previous algorithm will be used

(either step A2 or step A3).

The above two algorithms also apply when a host stays up, but

declares the destination name for an existing connection to no

longer be effective. In this case, however, the type 7 messages

above will be replaced by type 15, subtype 3 (name not effective)

messages.

Section 2.3 discusses how destination host downs are handled for

uncontrolled packets.

- 15 -

1822L Host Access Protocol April 1983
RFC851

2.2.4 1822L and 1822 Interoperability

As has been previously stated, 1822 and 1822L hosts can

intercommunicate, and the IMPs will automatically handle any

necessary leader and address format conversions. However, not

every combination of 1822 and 1822L hosts allows full

interoperability with regard to the use of 1822L names.

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.

- 16 -

1822L Host Access Protocol April 1983
RFC851

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

- 17 -

1822L Host Access Protocol April 1983
RFC851

2.3 Uncontrolled Packets

Uncontrolled packets (see 1822(3.6)) present a unique problem for

the 1822L protocol. Uncontrolled packets 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 packets need to carry all of their overhead with

them, including source and destination names. If 1822L names are

used when sending an uncontrolled packet, additional information

is now required by the subnetwork when the packet is transferred

to the destination IMP. This means that less host-to-host data

can be contained in the packet than is possible between 1822

hosts.

Uncontrolled packets that are sent between 1822 hosts may contain

not more than 991 bits of data. Uncontrolled packets that are

sent to and/or from 1822L hosts are limited to 32 bits less, or

not more than 959 bits. Packets that exceed this length will

result in an error indication to the host, and the packet 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 packet without

notification.

- 18 -

1822L Host Access Protocol April 1983
RFC851

Other enhancements that are provided for uncontrolled packet

service are a notification to the host of any errors that are

detected by the host's IMP when it receives the packet. A host

will be notified if an uncontrolled packet contains an error in

the 1822L name specification, such as if the name is not

authorized or effective, if the remote host is unreachable (which

is indicated by none of its names being effective), if network

congestion control throttled the packet before it left the source

IMP, or for any other reason the source IMP was not able to send

the packet on its way.

In most cases, the host will not be notified if the uncontrolled

packet was lost once it was transmitted by the source IMP.

However, the IMP will attempt to notify the source host if a

logically-addressed uncontrolled packet was mistakenly sent to a

host that the source IMP thought was effective, but which turned

out to be dead or non-effective at the destination IMP. This

non-delivery notice is sent back to the source IMP as an

uncontrolled packet from the destination IMP, so the source host

is not guaranteed to receive this indication.

If the source IMP successfully receives the non-delivery notice,

then the source host will receive a type 15 (1822L Name or

Address Error), subtype 6 (down or non-effective port) message.

If the packet is resubmitted or another packet is sent to the

- 19 -

1822L Host Access Protocol April 1983
RFC851

same destination name, and there are no available effective

translations, then the source host will receive a type 15,

subtype 5 (no effective translations) message if the destination

name has more than one mapping; or will receive either a type 7

(Destination Host Dead) or a type 15, subtype 3 (name not

effective) message if the destination name has a single

translation.

Those enhancements to the uncontrolled packet service that are

not specific to logical addressing will be available to hosts

using 1822 as well as 1822L. However, logically-addressed

uncontrolled packets must be used in order to receive any

indication that the packet was lost once it has left the source

IMP.

2.4 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

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.

- 20 -

1822L Host Access Protocol April 1983
RFC851

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

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

- 21 -

1822L Host Access Protocol April 1983
RFC851

further details concerning the ready line, host tardiness, and

other issues.

2.5 Counting RFMS When Using 1822L

When a host submits a regular message using an 1822 leader, the

IMP checks for an existing simplex virtual circuit connection

from the source host to the destination host. If such a

connection already exists, it is used. Otherwise, a new

connection from the source host port to the destination host port

is opened. In either case, there may be at most eight messages

outstanding on that connection at any one time. If a host

submits a ninth message on that connection before it receives a

reply for the first message, then the host will be blocked until

the reply is sent for the first message.

Such connections can stay open for some time, but are timed out

after three minutes of no activity, or can be closed if there is

contention for the connection blocks in either the source or

destination IMP. However, a connection will never be closed as

long as there are any outstanding messages on it. This allows a

source host to count the number of replies it has received for

messages to each destination host address in order to avoid being

blocked by submitting a ninth outstanding message on any

- 22 -

1822L Host Access Protocol April 1983
RFC851

connection.

When a host submits a regular message using an 1822L leader, a

similar process occurs, except that in this case, connections are

distinguished by the source name/destination name combination.

When the message is received from a host, the IMP first looks for

an open connection for that same source name/destination name

pair. If such a connection is found, then it is used, and no

further name translation is performed. If, however, no open

connection was found, then the destination name is translated,

and a connection opened to the physical host port. As long as

there are any outstanding messages on the connection it will stay

open, and it will have the same restriction that only eight

messages may be outstanding at any one time. Thus, a source host

can still count replies to avoid being blocked, but they must be

counted on a source name/destination name pair basis, instead of

just by destination host address as before.

Since connections are based on the source name as well as the

destination name, this implies that there may be more than one

open connection from physical host port A to physical host port

B, which would allow more than 8 outstanding messages

simultaneously from the first to the second port. However, for

this to occur, either the source or destination names, or both,

must differ from one connection to the next. For example, if the

- 23 -

1822L Host Access Protocol April 1983
RFC851

names "543" and "677" both translate to physical port 3 on IMP

51, then the host on that port could open four connections to

itself by sending messages from "543" to "543", from "543" to

"677", from "677" to "543", and from "677" to "677".

As has already been stated, the destination names in regular

messages are only translated when connections are first opened.

Once a connection is open, that connection, and its destination

physical host port, will continue to be used until it is closed.

If, in the meantime, a "better" destination host port belonging

to the same destination name became available, it would not be

used until the next time a new connection is opened to that

destination name.

2.6 1822L Name Server

There may be times when a host wants to perform its own

translations, or might need the full list of physical addresses

to which a particular name maps. For example, a connection-based

host-to-host protocol may require that the same physical host

port on a multi-homed host be used for all messages using that

host-to-host connection, and the host does not wish to trust the

IMP to always deliver messages using a destination name to the

same host port.

- 24 -

1822L Host Access Protocol April 1983
RFC851

In these cases, the host can submit a type 11 (Name Server

Request) message to the IMP, which requests the IMP to translate

the destination 1822L name and return a list of the addresses to

which it maps. The IMP will respond with a type 11 (Name Server

Reply) message, which contains the selection policy in use for

that name, the number of addresses to which the name maps, the

addresses themselves, and for each address, whether it is

effective and its routing distance from the IMP. See section 3.2

for a complete description of the message's contents.

Using this information, the source host can make an informed

decision on which of the physical host ports corresponding to an

1822L name to use, and can subsequently send the messages to that

port, rather than to the name.

The IMP also supports a different type of name service. A host

needs to issue a Name Declaration Message to the IMP in order to

make its names effective, but it may not wish to keep its names

in some table or file in the host. In this case, it can ask the

IMP to tell it which names it is authorized to use.

In this case, the host submits a type 12 (Port List Request)

message to the IMP, and the IMP replies with a type 12 (Port List

Reply) message. It contains, for the host port over which the

IMP received the request and sent the reply, the number of names

- 25 -

1822L Host Access Protocol April 1983
RFC851

that map to the port, the list of names, and whether or not each

name is effective. The host can then use this information in

order to issue the Name Declaration Message. Section 3.2

contains a complete description of the reply's contents.

- 26 -

1822L Host Access Protocol April 1983
RFC851

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

- 27 -

1822L Host Access Protocol April 1983
RFC851

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
+--------+-+------+----------------+
TLeader
Unused RFlags 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

- 28 -

1822L Host Access Protocol April 1983
RFC851

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.

- 29 -

1822L Host Access Protocol April 1983
RFC851

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 may occur.

3: Uncontrolled Packet - The IMP will perform no

message-control functions for this type of

message, and network flow and congestion control

may cause loss of the packet. 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.1), 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 leader padding, contains the number of 1822L

names 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

- 30 -

1822L Host Access Protocol April 1983
RFC851

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

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

- 31 -

1822L Host Access Protocol April 1983
RFC851

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

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.4 for a further discussion

on the use of the NOP message.

Type 8: Error with Message ID - see 1822(3.3).

Type 11: Name Server Request - This allows the host to use

the IMP's logical addressing tables as a name server.

The destination name in the 1822L leader is translated,

and the IMP replies with a Name Server Reply message,

which lists the physical host addresses to which the

destination name maps.

Type 12: Port List Request - This allows the physical host

to request the list of names that map to the host port

over which this request was received by the IMP. The

IMP replies with a Port List Reply message, which lists

the names that map to the port.

Types 5-7,9-10,13-255: Unassigned.

- 32 -

1822L Host Access Protocol April 1983
RFC851

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

contain the source host's 1822L address (see figure 4 in

section 2.2.4).

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

- 33 -

1822L Host Access Protocol April 1983
RFC851

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.4).

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 [4] 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.

Bits 81-96: Unused, must be zero.

- 34 -

1822L Host Access Protocol April 1983
RFC851

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
+--------+-+------+----------------+
TLeader
Unused RFlags 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

- 35 -

1822L Host Access Protocol April 1983
RFC851

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, 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).

Type 2: IMP Going Down - See 1822(3.4).

- 36 -

1822L Host Access Protocol April 1983
RFC851

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 (see figure 6). 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) - See

1822(3.4).

Type 8: Error in Data - See 1822(3.4).

Type 9: Incomplete Transmission - See 1822(3.4).

Type 10: Interface Reset - See 1822(3.4).

Type 11: Name Server Reply - This reply to the Name Server

Request host-to-IMP message contains a word with the

selection policy and the number of physical addresses

to which the destination name maps, followed by two

words per physical address: the first word contains an

- 37 -

1822L Host Access Protocol April 1983
RFC851

1822L address, and the second word contains a bit

signifying whether or not that particular translation

is effective and the routing distance (in 6.4 ms units)

to the address's IMP. In figure 8, EFF is 1 for

effective and 0 for non-effective, and POL is a two-bit

number indicating the selection policy for the name

(see section 2.2.2):

0: First reachable.

1: Closest physical address.

2: Load leveling.

3: Unused.

- 38 -

1822L Host Access Protocol April 1983
RFC851

1 16 17 32 33 48
+----------------+----------------+----------------+

0E00 000B 0000

+----------------+----------------+----------------+
49 64 65 80 81 96
+----------------+----------------+----------------+

dest. name 0000 0000

+----------------+----------------+----------------+
97 112 113 128 129 144
+-+--------------+----------------+-+--------------+
P E
O # of addrs 1822L addr #1 F routing dist
L F
+-+--------------+----------------+-+--------------+
145 160 161 176
+----------------+-+--------------+
E
1822L addr #2 F routine dist etc.
F
+----------------+-+--------------+

Figure 8. Name Server Reply Format

Type 12: Port List Reply - This is the reply to the Port

List Request host-to-IMP message. It contains the

number of names that map to this physical host port,

followed by two words per name: the first word contains

an 1822L name that maps to this port, and the second

contains either a zero or a one, signifying whether or

not that particular translation is effective. The

format is identical to the type 3 NDM Reply message

- 39 -

1822L Host Access Protocol April 1983
RFC851

(see figure 6).

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 physical host to which this singly-homed

Destination Host name translated is authorized and

up, but not effective. If the host was 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.4).

5: The multi-homed Destination Host name is authorized,

but has no available effective translations.

6: A logically-addressed uncontrolled packet was sent

to a dead or non-effective host port. However, if

it is resubmitted, there may be another effective

host port to which the IMP may be able to attempt

- 40 -

1822L Host Access Protocol April 1983
RFC851

to send the packet.

7: Logical addressing is not in use in this network.

8-15: Unassigned.

Types 13-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 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 and 15, this field

contains the destination host field used in a previous type

0 message sent by this host.

Bits 65-76: Message ID:

For message types 0, 5, 7-9, 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

- 41 -

1822L Host Access Protocol April 1983
RFC851

and 6.

Bits 77-80: Sub-type:

This field is used as a modifier by message types 0-2, 5-7,

9, and 15.

Bits 81-96: Message Length:

This field is contained in type 0, 3, 11, and 12 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.

- 42 -

1822L Host Access Protocol April 1983
RFC851

4 REFERENCES

[1] Specifications for the Interconnection of a Host and an IMP,

BBN Report 1822, December 1981 Revision.

[2] A. Malis, The ARPANET Short Blocking Feature, Request For

Comments 852, April 1983.

[3] E. C. Rosen et. al., ARPANET Routing Algorithm Improvements,

Internet Experimenter's Note 183 (also published as BBN

Report 4473, Vol. 1), August 1980, pp. 55-107.

[4] J. Postel, Assigned Numbers, Request For Comments 820,

January 1983, p. 11.

- 43 -

1822L Host Access Protocol April 1983
RFC851

INDEX

1822...................................................... 4
1822 address.............................................. 6
1822 host................................................. 5
1822L..................................................... 4
1822L address............................................. 7
1822L host................................................ 5
1822L name................................................ 6
address selection policy................................. 12
authorized................................................ 9
blocking................................................. 22
closest physical address................................. 13
connection............................................... 22
destination host..................................... 33, 41
effective................................................ 10
first reachable.......................................... 12
handing type......................................... 29, 36
host downs............................................... 13
leader flags......................................... 29, 36
link field............................................... 34
load leveling............................................ 13
logical addressing........................................ 4
message ID........................................... 34, 41
message length........................................... 42
message type......................................... 30, 36
multi-homing.............................................. 4
name server...................................... 24, 32, 37
NDM.................................................. 10, 30
NDM reply............................................ 10, 37
NOC....................................................... 9
NOP........................................... 5, 20, 32, 37
priority bit............................................. 29
regular message...................................... 30, 36
RFNM................................................. 22, 37
source host.......................................... 33, 41
standard message......................................... 30
sub-type............................................. 34, 42
symmetric................................................. 5
trace bit............................................ 29, 36
uncontrolled packet.................................. 18, 30

上一篇：RFC849 - Suggestions for improved host table distribution

下一篇：RFC852 - ARPANET short blocking feature