rfc1005.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,813 行 · 第 1/5 页

Khanna & Malis                                                 [Page 13]

RFC 1005                                                        May 1987


AHIP-E addresses have the following format:


                  8     1   5       10
             +--------+-+-----+----------+
             |  HOST  |0|XXXXX|   PSN    |  Physical Address
             +--------+-+-----+----------+
             41     48         55      64
             (bit positions in the AHIP leader)
           (X = don't care)

                         AHIP-E Address Format
                               Figure 3.2

Logical names are 16-bit unsigned numbers that serve as a logical
identifier for one or more hosts.  A logical name is the concatenation
of two separate octets in the AHIP leader, bits 41-48 (Upper 8) and 57-
64 (Lower 8) in particular.


                         8      2   6       8
                     +--------+--+------+--------+
                     | UPPER  |11|XXXXXX| LOWER  |
                     +--------+--+------+--------+
                     41     48           57     64
                    (bit positions in the AHIP leader)
                           (X = don't care)


                          Logical Name Format
                               Figure 3.3

3.2  Name Translations

There are a number of factors that determine how a logical name is
translated by the PSN 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; and which legal
translations should not be attempted because a particular host port is
down.  These issues are discussed in the following sections.











Khanna & Malis                                                 [Page 14]

RFC 1005                                                        May 1987


3.2.1  Authorization and Effectiveness

Every host on a PSN, regardless of whether it is using the AHIP or
AHIP-E protocol to access the network, can have one or more logical
names.  Hosts using AHIP-E can then use these names to address the hosts
in the network independent of their physical locations.

At this point, several questions arise:  How are these names assigned,
how do they become known to the PSNs (so that translations to physical
addresses can be made), and how do the PSNs 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 PSNs by the Monitoring Center (MC).  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.  Physical addresses, which actually refer to
physical host ports, are always authorized in this sense.

When the PSN detects that a host has come up on one of its ports, it
makes effective the default name(s), if any, for that host.  This
default action is specified in the configuration table for that host,
and can be one of the following: Enable All Names, Enable No Names,
Enable One Particular Name.  In the case of an AHIP-E host, the default
name might not be the one that the host desires to be known as (recall
that several hosts may share the same port, or one host may prefer to be
known by different names at different times).  This requires that an
AHIP-E host be able to declare its name to the PSN.  This function is
performed by a new host-to-PSN message, the Name Declaration Message
(NDM), which lists the names that the host would like to be known by.
The PSN 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.

If a host is using the current AHIP protocol, it can still receive
messages from hosts via its logical name.  Of course, it can also
receive messages from a current AHIP host via its physical address as
well.  (Remember, the distinction between logical names and physical



Khanna & Malis                                                 [Page 15]

RFC 1005                                                        May 1987


addresses is that the addresses correspond to physical locations on the
network, while the names are strictly logical identifiers).

The third question above has by now already been answered. An AHIP-E
host can use the NDM message to tell the PSN which host it is (which
names it is known by).  Thus, even if this is a shared port, the PSN
knows which host is currently connected.

WHENEVER A HOST GOES DOWN, ITS NAMES AUTOMATICALLY BECOME NON-
EFFECTIVE.  When it comes back up, the default action (from the host's
configuration) is taken.  If the host wishes to be known by a name other
than the default, it will have to issue a NDM.  It will also have to do
this upon receipt of reset NOPS from the PSN.

3.2.2  Translation Policies

Several hosts can share the same logical name.  If more than one of
these hosts is up at the same time, any messages sent to that logical
name will be delivered to just one of the hosts sharing that name, and a
RFNM will be returned as usual.  However, the sending host will not
receive any indication of which host received the message, and
subsequent messages to that name are not guaranteed to be sent to the
same host.  Typically, hosts providing exactly the same service could
share the same logical name in this manner.

Similarly, when a host is multi-homed, the same logical 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 physical address or a
specific logical 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 administratively 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 PSN's translation tables, to find
   the first reachable physical host address.  This list is
   always searched from the top whenever a new virtual circuit
   connection has to be created.  This is the most commonly used
   policy.




Khanna & Malis                                                 [Page 16]

RFC 1005                                                        May 1987


o  Selection of the closest physical address, which uses the
   PSN's internal routing tables to find the translation to the
   destination PSN with the least cost path for the particular
   type-of-service whenever a new virtual circuit connection has
   to be created.

o  Use load leveling.  This is similar to the first policy, but
   differs in that searching the address list for a valid
   translation starts at the address following where the
   previous translation search ended whenever a new virtual
   circuit connection has to be created. This attempts to
   spread out the load from any one PSN's hosts to the various
   host ports associated with a particular name.  Note that
   this is NOT network-wide load leveling, which would require
   knowledge about flows throughout the network.

3.2.3  Reporting Destination Host Downs

As is explained in Report 1822, whenever regular messages are sent by a
host, the PSN opens a virtual circuit connection to each destination
host from the source host.  A new connection is opened for each new
source-address/destination-name (or address, as the case might
be)/handling-type/type-of-service combination.  A connection will stay
open at least as long as there are any outstanding (un-RFNMed) messages
using it and both the source and destination hosts stay up.  Connections
are also closed after a period of inactivity.

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 a physical address is being used to specify the
     destination host, then the source host will receive a type
     7, subtype 0 (Destination Host Dead) message from the PSN.

A2.  If a logical name is being used to specify the
     destination host, and the name maps to only one authorized
     host port,then a type 7, subtype 0 message will be sent to
     the source host.

A3.  If a logical name is being used to specify the destination
     host, and the name maps to more than one authorized host
     port, then the PSN 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



Khanna & Malis                                                 [Page 17]

RFC 1005                                                        May 1987


     15 (AHIP Name or Address Error), subtype 5 (no effective
     translations) message (see section 5.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
     the name maps to more than one destination port.  However,
     in the case of a version 0 or 1 host, a type 7, subtype 0
     message will be returned for each outstanding message.  See
     chapter 6 for further details on version numbers.

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 a physical 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 a logical name is being used to specify the
     destination host, then the source host will receive a type
     9 (Incomplete Transmission), subtype 6 (message lost due to
     logically addressed host going down) 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). However,in the case of a version 0 or 1 host, a
     type 7,subtype 0 message will be returned for each
     outstanding message. See chapter 6 for further details
     on version numbers.

3.3  Establishing Host-PSN Communications

When a host comes up on a PSN, or after there has been a break in the
communications between the host and its PSN (see 1822 (3.2)),the orderly
flow of messages between the host and the PSN needs to be properly (re-
)established.  This allows the PSN and host to recover from almost any
failure in the other or in their communications path, including a break
in mid-message.

The first messages that a host should send to its PSN are three NOPs.
Three messages are required to ensure that at least one message will be
properly read by the PSN (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 to
synchronize the PSN with the host, to inform the PSN about how much
padding the host requires between the message leader and its body and to
specify the host's AHIP-E version number to the PSN (see chapter 6).

Similarly, the PSN will send three NOPs to the host when it detects that



Khanna & Malis                                                 [Page 18]

RFC 1005                                                        May 1987


the host has come up.  The NOPs will be followed by an Interface Reset
message.  These NOPs will contain the physical address of the host
interface.

Once the PSN and the host have sent each other the above messages,
regular communications can commence.  See 1822(3.2) for further details
concerning the ready line, host tardiness, and other issues.

3.4  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 PSN to always deliver messages using a destination
name to the same host port.

In these cases, the host can submit a type 11 (Name Server Request)
message to the PSN, which requests the PSN to translate the destination
name and return a list of the addresses to which it maps.  The PSN 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 (for the particular type-of-
service specified in the Name Server Request message) from the PSN.  See
section 5.2 for a complete description of these messages' contents.

Using this information, the source host could make an informed decision
on which of the physical host ports corresponding to a logical name to
use and then send the messages to that port, rather than to the name.

The PSN also supports a different type of name service.  A host needs to
issue a Name Declaration Message to the PSN in order to change its
effective names, but it may not wish to keep its names in some table or
file in the host.  In this case, it can ask the PSN 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 PSN, and the PSN replies with a type 12 (Port List Reply) message.
It contains, for the host port over which the PSN received the request
and sent the reply, the number of names 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 5.2 contains a complete description of the reply's contents.






Khanna & Malis                                                 [Page 19]

RFC 1005                                                        May 1987


4  OTHER CHANGES

This section describes the enhancements to the AHIP protocol involving
type-of-service specification, subnet congestion feedback and network
precedence level feedback.  Note that only version 2 hosts will receive
the congestion and precedence messages described in this section.

4.1  Type-of-Service Specification

Bits 9 and 10 of the AHIP leader, currently unused, will be used by the
host to specify desired delay and throughput characteristics to the PSN.
Bit 11, also currently unused, will be used to specify reliability.  The
bits have the following meaning:

Bit 9:    delay bit

            0 -- normal delay
            1 -- low delay