rfc1005.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,733 行 · 第 1/5 页

     1.   Address Mapping Stability Requirement:

          Any current IP physical address with l (logical host) = 0
          should remain unchanged under the new design.  For example,
          the binary string corresponding to 10.0.0.51 should continue
          to refer to sri-nic.arpa (assuming, of course, that sri-nic
          continues to reside on psn 51, port 0).  This requirement is
          motivated by a desire to avoid a network-wide address
          switchover.

     2.   Existing implementation compatibility:

          Existing compliant implementations of AHIP should continue to
          function for destinations with addresses fitting the
          restrictions in 1.  In other words, such addresses should
          continue to refer to their original destinations, not only
          with the AHIP-E implementation (which is the condition in 1),
          but also with current ones.

     3.   Compatibility between X.25's IP address to subnet host mapping
          and AHIP's IP address to subnet host mapping:

          The AHIP-E IP to host mapping should be able to co-exist in
          some sense with the IP to host mapping specified by the DDN
          X.25 Specification [6].  In particular, restricted use of the
          revised IP to DDN host mapping should produce addresses that
          are consistent with the current X.25 mapping.  In other words,
          there should be a set that includes "sufficiently many"
          logical names and physical addresses, with the property that
          each address/name in the set maps onto the same host under
          both the AHIP and X.25 mappings.

     4.   Maximum number of PSNs that can be supported:

          The new design should support a maximum of more than 256 PSNs
          per network.










Khanna & Malis                                                  [Page 7]

RFC 1005                                                        May 1987


2.3  New Interpretation of IP Address Fields

The following is the new interpretation of the IP address field, in the
context of ARPANET-style networks:


            Proposed IP Address Interpretation

              8        8     1   5       10
          +--------+--------+-+-----+----------+
          | net #  |  HOST  |0|XXXXX|   PSN    |  Physical Address
          +--------+--------+-+-----+----------+
          0       7 8     15  17  21 22      31


              8        8      2   6       8
          +--------+--------+--+------+--------+
          | net #  | UPPER  |11|XXXXXX| LOWER  |  Logical Name
          +--------+--------+--+------+--------+
          0       7 8     15   18   23 24    31


                   16         2       14
          +-----------------+--+---------------+
          |                 |10|               |  Reserved Format
          +-----------------+--+---------------+
          0               15    18            31

                      (X = don't care)

                 New Class A IP Address Interpretation
                               Figure 2.2


The fields have the following meanings:

          HOST = host-number

          PSN = 10 bit PSN-number field

          UPPER = upper 8 bits of the 16-bit logical name

          LOWER = lower 8 bits of the 16-bit logical name








Khanna & Malis                                                  [Page 8]

RFC 1005                                                        May 1987


AHIP-E physical addresses and logical names have the following formats:

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


              8      2   6       8
          +--------+--+------+--------+
          | UPPER  |11|XXXXXX| LOWER  |  Logical Name
          +--------+--+------+--------+
          41     48           57     64
               (bit positions in the AHIP leader)


          +--------+--+---------------+
          |        |10|               |  Reserved Address Format
          +--------+--+---------------+
          41     48    51            64
               (bit positions in the AHIP leader)


                        AHIP-E Address and Name
                               Figure 2.3

The reserved address format is currently undefined and will be rejected
by the PSN, which will return an error message (message type 6, subtype
3) to the host.

    -----------------------------------------------------------------
   |This design does not require the AHIP-E host to do any processing|
   |of the address -- the host need only copy bits 8-31 of the IP    |
   |address into bits 41-64 of the AHIP leader.  The host no longer  |
   |needs to zero out bits 49-56 of the AHIP leader.  The PSN will   |
   |take care of the AHIP to subnet address conversion.  In other    |
   |words, bits 8-31 of the IP address field should be passed        |
   |unchanged to the PSN, which interprets them exactly as shown in  |
   |figure 2.3.                                                      |
    -----------------------------------------------------------------








Khanna & Malis                                                  [Page 9]

RFC 1005                                                        May 1987


2.4  Discussion of the New Mapping

This section presents an evaluation of the design in terms of the
requirements in section 2.2

     1.   Address mapping stability requirement:

          Current physical IP addresses will not have to be changed, as
          long as they have been following the convention of setting LH
          = 0.  This ensures that bit 16 is set to 0, indicating that
          the address is physical, and that the PSN number comes out
          right.


     2.   Existing implementation compatibility:

          The design meets this requirement, as the address that gets to
          the PSN has its second octet = 0, which results in its correct
          interpretation as a physical address.

     3.   Compatibility with the current X.25 IP address to DDN host
          mapping:

          The current X.25 IP to HOST mapping [6] is as follows: If h <
          64, the address is considered physical, i.e., it refers to
          host h on PSN i.  If h >= 64, the address is considered
          logical, i.e., it refers to the host whose logical name is h
          concatenated with i.

          The design is compatible in a limited sense with the current
          X.25 logical addressing implementation, as long as logical
          names are assigned such that host-number > 63 (also PSN-number
          < 256 which is automatic, given the 16-bit size of the logical
          name field) and physical addresses are in the range host-
          number < 64 and PSN- number < 256, with the appropriate
          setting of bits 16 and 17 of the IP address field.  This works
          because the X.25 mapping ignores the value of the l field,
          i.e., the third IP address octet.

          Given the desire to be able to address more than 64 hosts
          physically and for PSN numbers > 255, this address assignment
          restriction should not be considered permanent, but rather as
          an interim compromise until the hosts' X.25 implementations
          are revised to incorporate the new mapping between IP and DDN
          addresses.






Khanna & Malis                                                 [Page 10]

RFC 1005                                                        May 1987


     4.   Maximum number of PSNs that can be supported:

          The design allows addressing of up to 1024 PSNs per network.

2.5  Interoperability between Current AHIP and AHIP-E

This section discusses the interoperability between hosts using current
AHIP and AHIP-E.  It also discusses the general issue of current AHIP
host operation in the AHIP-E addressing environment.

The proposed modifications to AHIP have been designed with backward
compatibility in mind.  However, note that bits 41-64 of the PSN-to-host
leader (see 1822(3.4)) will always contain the physical address of the
source host.  This means that an error could occur when a host on a PSN
numbered greater than 255 attempts to send a message to a host running a
current AHIP implementation, which interprets the address of the source
host as one with PSN-number < 256.

There are other possibilities for errors, caused by incorrect address
translation between IP and current AHIP:

   1.  A host running current AHIP cannot physically address
       any host on a PSN numbered greater than 255 (see Figure
       3.1).  Consequently, an error will result if the host
       attempts to use an address from the NIC host table that
       has PSN-number > 255.

   2.  If a host running current AHIP attempts to use a
       logical name that it might have in its host table, an
       error will occur.  This is because the logical name flag
       bits 16 and 17 of the IP address, bits 49 and 50 of the
       AHIP leader.  Recal that bits 49 - 56 of the AHIP
       leader get set to zero with current AHIP (see figure
       2.1).

Since these errors cannot be detected by the subnetwork, it is essential
that all hosts implement at least version 1 AHIP-E (see chapter 6)
before PSN numbers over 255 and logical names are assigned.













Khanna & Malis                                                 [Page 11]

RFC 1005                                                        May 1987


Another aspect of interoperability has to do with the IP LH field, which
is currently used by a handful of Arpanet hosts to demultiplex a single
host port.  The 5 don't-care bits of the physical IP address (bits 17-
21) and the 6 don't-care bits of the IP logical name (bits 18-23) can be
used for this purpose -- in particular, the use of these bits is divided
between the network and external devices, based on administrative
agreement.  At the very least, the IP addresses of such hosts will have
to change to reflect the changed position of the LH field.  However, the
preferred way to demultiplex a single host port is via the mechanism of
logical names.  The only change this involves is to get the port
expander implementation to look at the entire IP address, rather than
just the LH field.







































Khanna & Malis                                                 [Page 12]

RFC 1005                                                        May 1987


3  LOGICAL ADDRESSING

The modifications to AHIP allow a host to use logical addressing to
communicate with other hosts on the network.  Basically, logical
addressing allows hosts to refer to each other using a logical name (see
section 3.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 in the network (especially
  important if the host has to move to another physical port).

o Allowing different hosts to share the same host port on a
  time-division basis.