📄 rfc851.txt
字号:
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
RFC 851
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
RFC 851
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
RFC 851
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
RFC 851
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
RFC 851
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
RFC 851
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
RFC 851
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
RFC 851
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
RFC 851
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -