rfc1277.txt

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

Network Working Group                            S.E. Hardcastle-Kille
Requests for Comments 1277                   University College London
                                                         November 1991


                      Encoding Network Addresses
            to support operation over non-OSI lower layers




Status of this Memo
    This RFC specifies an IAB standards track protocol for the
    Internet community, and requests discussion and suggestions for
    improvements.  Please refer to the current edition of the ``IAB
    Official Protocol Standards'' for the standardization state and
    status of this protocol.  Distribution of this memo is unlimited.
Abstract

    The OSI Directory specifies an encoding of Presentation Address,
    which utilises OSI Network Addresses as defined in the OSI
    Network Layer standards [CCI88] [ISO87a].  The OSI Directory, and
    any OSI application utilising the OSI Directory must be able use
    these Network Addresses to identify end systems.  Currently, OSI
    applications are often run over lower layers other than the OSI
    Network Service.  It is neither reasonable nor desirable for
    groups wishing to investigate and use OSI Applications in
    conjunction with the OSI Directory to be dependent on a global
    OSI Network Service.  This document defines a new network address
    format, and rules for using some existing network address
    formats.  The scope of this document is:

1.  Any TCP/IP network supporting COTS using RFC 1006.

2.  Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is
    not used to provide CONS (i.e., only DTE and not Network address
    is carried).


    The approach could also be extended to use with other means of
    providing COTS (or CLTS). It is not appropriate for use where
    CONS or CLNS is used to provide COTS (or CLTS).




RFC 1277           Encoding Network Addresses            November 1991


1  Introduction

The OSI Directory specifies an encoding of Presentation Address, which
utilises OSI Network Addresses as defined in the OSI Network Layer
standards [CCI88] [ISO87a].  The OSI Directory, and any OSI
application utilising the OSI Directory must be able use these Network
Addresses to identify end systems.
Currently, OSI applications are often run over lower layers other than
the OSI Network Service.  It is neither reasonable nor desirable for
groups wishing to investigate and use OSI Applications in conjunction
with the OSI Directory to be dependent on a global OSI Network
Service.  This RFCdefines mechanisms to encode addressing information
within Network Addresses, in order to support this type of working.
In particular, support is defined for RFC 1006 mapping of COTS onto
TCP/IP and COTS mapped onto X.25(1980) [RC87, CCI80].

Where an OSI application is run over CLNS on the internet, the NSAP
Guidelines of RFC 1237 should be followed [CGC91].
This document must be read in the context of ISO 8348 Addendum 2
[ISO87b].  It will not be meaningful on its own.


1.1  Historical Note

This document was originally published as UCL Research Note RN/89/13
and as a project THORN internal document [Kil89].  It was devised in
response to two projects which faced this requirement, and was agreed
as a common approach.  The projects were:


 o  The THORN project, which is an Esprit Project building an OSI
    Directory [SA88].

 o  The ISODE project [Ros90], and in particular the QUIPU directory
    being developed at UCL [Kil88].

The proposal has been implemented, and the viability of the solution
demonstrated.







Hardcastle-Kille                                                Page 1




RFC 1277           Encoding Network Addresses            November 1991


2  Problem Statement

When utilising the OSI Directory, the OSI location of an End System
will be determined by a Network Address, which is taken from a
Presentation Address, looked up in the OSI Directory.
OSI applications are currently operated over the following lower
layers.


 o  An international X.25 network, which routes on the basis of X.121
    addresses.  By and large this is X.25(80), but some parts are now
    X.25(84) and will carry Network Addresses as user data.  OSI
    Transport is mapped onto the variant of X.25 which is available.

 o  Large private X.25 networks, which do not have DNICs, but are
    otherwise similar to the previous (in particular Janet).

 o  Isolated networks running Connection Oriented Network Service
    (e.g., Pink Book Ethernets).

 o  Isolated networks running Connectionless Network Service (e.g.,
    MAP LANs).

 o  The Connectionless Network Service Protocol (CLNP) pilot,
    currently taking place in the NSFNet and NORDUNet communities.

 o  Isolated TCP/IP LANs, utilising RFC 1006 to support the OSI
    Transport Service[RC87].

 o  The DARPA/NSF Internet, using RFC 1006.

In general, these systems need to be interconnected by the use of
transport bridging or application relaying.  Operation of transport
bridges causes a number of problems which it is desirable to avoid.
Only some applications can support relaying, and this is not always
satisfactory.


2.1  The ``Right Solution''

It is worth noting briefly what the intended (OSI) solution is.  There
is a single global network service.  Network Addresses are globally
allocated, and do not imply anything about routing or location.  An


Hardcastle-Kille                                                Page 2




RFC 1277           Encoding Network Addresses            November 1991


End System is attached to one or more subnetworks at Subnetwork Points
of Attachment (SNPAs).  Intermediate Systems join subnetworks, again
being attached at SNPAs.  Routing is achieved by repeated binding of
Network Address to SNPA (initially at the Originating End System, and
then at each Intermediate System).  This binding is achieved by
network level routing mechanisms.
This can only work in a pure OSI environment with a single ubiquitous
network service (either connectionless or connection-oriented), and so
is not sufficient for the problem being addressed by this note.


2.2  General Approach

This section describes the use of network addresses, and gives a
functional overview of the problem being takceled.  The means of
connecting to a remote Application Entity is broadly as follows.

1.  Look up the Application Entity in the OSI Directory to obtain the
    Presentation Address 1.

2.  Extract each Network Address from the Presentation Address, and
    determine if it can be used (and how).

3.  Determine an order of preference for the Network Addresses.

4.  Attempt to connect to one or more of the Network Addresses.


This note is concerned with the second step, and will probably have
implications on the third.  There is currently no directory service to
provide step 2, and so this (interim) approach must be algorithmic.
All addressing information required for the network must be extracted
from the network address.
This note describes the use of Network Addresses for networks which do
not provide the OSI Network Service (CLNS or CONS), and places
constraints on the use of X.121 form network addresses when used for
an OSI Network Service.  The following types of Network Address are
discussed in this note:

----------------------------
    1. Strictly an Application Entity should have only one
Presentation Address.  In practice it may have several, and the
network addresses of each Presentation Address should be considered.


Hardcastle-Kille                                                Page 3




RFC 1277           Encoding Network Addresses            November 1991


 o  Use of X.121 form Network Addresses.

 o  A special encoding of Telex form Network Addresses.


3  Network addresses with X.121 AFI

This note defines an approach for use of network addresses with the
X.121 AFI.
The IDP of network addresses is used to allow worldwide administration
of the NSAP address space.  As such, not all values of the IDP will in
practice have topological significance (which implies that in some
cases the IDP will not be sufficient for network layer routing).
However, it is recommended that any End System using the Connection
Oriented Network Service and with access to the international X.25
service uses the X.121 form of NSAP address relative to its access
point.  This allows routing across the worldwide X.25 based public
data networks to be based on the X.121 addresses.  Allocation of DSP
(Domain Specific Part) within this form of address is a private issue.

The IDP is primarily an allocation mechanism, and the user (end
system) cannot in principle assume any implied routing.  However, due
to the lack of a network directory service, it is recommended that any
End System with Connection Oriented Network Service and access to the
international X.25 service uses X.121 form relative to its access
point.  Allocation of DSP (Domain Specific Part) is a private issue.
Conversely it is recommended that if an X.121 IDP (Initial Domain
Part) form Network Address is interpreted, then the X.121 address will
provide a route (by defining an SNPA on the international X.25
network).  There may be additional and perhaps preferable routes which
can be determined by private means.
If the DSP is absent, the form should be interpreted as implying a
mapping of Transport onto X.25(80).


4  New Network Address Format


This section defines a new network address format.  The scope of this
format is currently:

1.  Any TCP/IP network supporting COTS using RFC 1006.



Hardcastle-Kille                                                Page 4




RFC 1277           Encoding Network Addresses            November 1991


2.  Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is
    not used to provide CONS (i.e., only DTE and not Network address
    is carried), except where the international X.25 service is used
    and no PID or CUDF is required.
    These exceptions are the cases which are handled by use of X.121
    AFI (Section 3).  The intention is to use the X.121 AFI wherever
    possible, and the formats defined in this section are for the
    remaining cases.

The approach could also be extended to use with other means of
providing COTS (or CLTS). It is not appropriate for use where CONS or
CLNS is used to provide COTS (or CLTS).


4.1  Requirements

The requirements for use of OSI over existing networks not supporting
CONS or CLNS, when using the OSI Directory are:


1.  The information for the layers below Transport must be obtained
    from the Network Address.  This is essential, because we wish to
    use the OSI Directory in a standard manner, and the Network
    Address is the information available.

2.  The Network Addresses must be globally unique, as they can be
    looked up by anyone with access to the Directory.

3.  The Network Address should be allocated so that confusion with a
    ``real'' Network Address (i.e., one which defines an NSAP using
    CONS or CLNS as opposed to X.25(80) or RFC 1006) is unlikely.

4.  Network Addresses must be interpretable on the basis of a well
    known information, or on information which can be obtained from
    the (application level) OSI Directory.  (This RFConly uses well
    known information).

5.  The identity of the network in question must be deducible from the
    Network Address

6.  All network specific addressing information (including the SNPA)
    must be deducible from the Network Address



Hardcastle-Kille                                                Page 5




RFC 1277           Encoding Network Addresses            November 1991


4.2  IDP Choice

The IDP is used with Telex AFI. The Telex AFI is used because:

 o  It gives the largest DSP

 o  It is less likely than other forms to be used for ``real'' Network
    Addresses


The following AFIs might have been chosen, but are not used for the
reasons given:

 o  Local (the values must be globally unique)

 o  X.121 (because it may be confused with other uses of OSI network
    addresses)

 o  DCC and ICD (because it may be confused with other uses of OSI
    network addresses)

The IDI should be assigned in a manner appropriate to the use of the
encoding.  For example, for operation on a private network within an