rfc1276.txt

RFC 的详细文档！

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






          Replication and Distributed Operations extensions
             to provide an Internet Directory using X.500







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
    Some requirements on extensions to X.500 are described in the
    RFC[HK91b], in order to build an Internet Directory using
    X.500(1988).  This document specifies a set of solutions to the
    problems raised.  These solutions are based on some work done for
    the QUIPU implementation, and demonstrated to be effective in a
    number of directory pilots.  By documenting a de facto standard,
    rapid progress can be made towards a full-scale pilot.  These
    procedures are an INTERIM approach.  There are known
    deficiencies, both in terms of manageability and scalability.
    Transition to standard approaches are planned when appropriate
    standards are available.  This RFCwill be obsoleted at this
    point.




RFC 1276         Internet Directory Replication          November 1991


Contents

1   Approach                                                         2

2   Extensions to Distributed Operations                             3


3   Alternative DSAs                                                 4

4   Data Model                                                       5


5   DSA Naming                                                       6

6   Knowledge Representation                                         6

7   Replication Protocol                                             9


8   New Application Context                                         12

9   Policy on Replication Procedures                                12


10  Use of the Directory by Applications                            12

11  Migration and Scaling                                           12

12  Security Considerations                                         13


13  Author's Address                                                13

A   ASN.1 Summary and Object Identifier Allocation                  14


List of Figures

    1      Knowledge Attributes  .   .   .   .   .   .   .   .       8

    2      Replication Protocol  .   .   .   .   .   .   .   .      10
    3      Summary of the ASN.1  .   .   .   .   .   .   .   .      17



Hardcastle-Kille                                                Page 1




RFC 1276         Internet Directory Replication          November 1991


1  Approach

There are a number of non-negotiable requirements which must be met
before a directory can be deployed on the Internet [HK91b].  These
problems are being tackled in the standards arena, but there is
currently no stable solution.  One approach would be to attempt to
intercept the standard.  Difficulties with this would be:


 o  Defining a coherent intercept would be awkward, and the effort
    would probably be better devoted to working on the standard.  It
    is not even clear that such an intercept could be defined.

 o  The target is moving, and it is always tempting to track it, thus
    causing more delay.

 o  There would be a delay involved with this approach.  It would be
    too late to be useful for a rapid start, and sufficiently close to
    the timing of the final standard that many would choose not to
    implement it.

Therefore, we choose to take a simple approach.  This is a good deal
simpler than the full X.500 approach, and is based on operational
experience.  The advantages of this approach are:


 o  It is proven in operation.  This RFCis simply documenting what is
    being done already.

 o  There will be a minimum of delay in starting to use the approach.

 o  The approach is simpler, and so the cost of implementation is much
    less.  It will therefore be much more attractive to add into an
    implementation, as it is less effort, and can be further ahead of
    the standard.

These procedures are an INTERIM approach.  There are known
deficiencies, both in terms of manageability and scalability.
Transition to standard approaches are planned when appropriate
standards are available.  This RFCwill be obsoleted at this point.





Hardcastle-Kille                                                Page 2




RFC 1276         Internet Directory Replication          November 1991


2  Extensions to Distributed Operations

The distributed operations of X.500 assume that all DUAs and DSAs are
fully interconnected with a global network service.  For the Internet
Pilot, this assumption is invalid.  DSAs may be operated over TCP/IP,
TP4/CLNS, or TP0/CONS.
The extension to distributed operations to support this situation is
straightforward.  We define the term community as an environment where
direct (network) communication is possible.  Communities may be
separated because they operate different protocols, or because of lack
of physical connectivity.  Example communities are the DARPA/NSF
Internet, and the Janet private X.25 network.  A network entity in a
community is addressed by its Network Address.  If two network
entities are in the same community, they can by definition
communicate.  A community is identified by a set of network address
prefixes.  For the approach to be useful, this set should be small
(typically 1).  For TCP/IP Networks, and X.25 Networks not providing
CONS, the approach is described in [HK91a] allows for communities to
be defined for the networks of operational interest.

This model can be used to determine whether a pair of application
entities can communicate.  For each entity, determine the presentation
address (typically by directory lookup).  Each network address in the
presentation address will have a single associated community.  The set
of communities to which each application entity belongs can thus be
determined.  If the two application entities have a common community,
then they can communicate directly.
Two extensions to the standard distributed operations are needed.


1.  Consider a DSA (the local DSA) which is contacted by either a DUA
    or DSA (the calling entity) to resolve a query.  The local DSA
    determines that the query must be progressed by another DSA (the
    referred-to DSA). The DSA will make a chain/referral choice.  If
    chaining is prohibited by service control, a referral will be
    passed back.  Otherwise, if the local DSA prefers to chain (e.g.,
    for policy reasons) it will then chain.  The remaining situation
    is that the local DSA prefers to give a referral.  It shall only
    do so if it believes that the calling entity can directly connect
    to the referred-to DSA. If the calling entity is a DUA, it should
    be assumed to belong only to the community of the called network
    address.  If the calling entity is a DSA, its communities should
    be determined by lookup of the DSA's presentation address in the
    directory.  The communities of the referred-to DSA can be

Hardcastle-Kille                                                Page 3




RFC 1276         Internet Directory Replication          November 1991


    determined from its presentation address, which will either be
    present in the reference or can be looked up in the directory.  If
    the calling entity and the referred-to DSA do not have a common
    community, then chaining shall be used.  Otherwise, a referral may
    be passed back to the calling entity.

2.  Consider that a DSA (or DUA), termed here the local entity is
    following a referral (to a referred-to DSA). In some cases, the
    local entity and referred-to DSA will not be able to communicate
    directly (i.e., not have a common community).  There are two
    approaches to solve this:

   (a)  Pass the query to a DSA it would use to resolve a query for
        the entry one level higher in the DIT. This will work,
        provided that this DSA follows this specification.  This
        default mechanism will work without additional configuration.

   (b)  Use a ``relay DSA'' to access the community.  A relay DSA is
        one which can chain the query on to the remote community.  The
        relay DSA must belong to both the remote community and to at
        least one community to which the local entity belongs.  The
        choice of relay DSA for a given community will be manually
        configured by a DSA manager to enable access to a community to
        which there is not direct connectivity.  Typically this will
        be used where the default DSA is a poor choice (e.g., because
        relaying is not authorised through this DSA).

    A DSA conforming to this specification shall follow these
    procedures.  A DUA may also follow these procedures, and this will
    give improvements in some circumstances (i.e., the ability to
    resolve certain queries without use of chaining).  However, this
    specification does not place requirements on DUAs.


3  Alternative DSAs

There is a need to give information on slave copies of data.  This can
be done using the standard protocol, but modifying the semantics.
This relies on the fact that there may only be a single subordinate
reference or cross reference.

If there is a need to include references to master and slave data (EDB
copies) in a referral, then this should be done in a referral by
specifying a subordinate reference with multiple values.  This cannot

Hardcastle-Kille                                                Page 4




RFC 1276         Internet Directory Replication          November 1991


be a standard subordinate reference, which would only have a single
value.  Therefore, this usage does not conflict with standard
references.  The first reference is the master copy, and subsequent
references are slave copies.


4  Data Model

The X.500 data model takes the unit of mastering data as the entry.  A
DSA may hold an arbitrary collection of entries.  We restrict this
model so that for the replication protocol defined in this
specification the base unit of replication (shadowing) is the complete
set of immediate subordinate entries of a given entry, termed an Entry
Data Block (EDB). An EDB is named by its parent entry.  It contains
the relative distinguished names of all of the children of the entry,
and each of the child entries.  For each entry, this comprises all
attributes of the entry, the relative distinguished name, and
knowledge information associated with the entry.  If a DSA holds
(non-cached) information on an entry, it will hold information on all
of its siblings.  One DSA will hold a master EDB. This will contain
two types of entry:

1.  Entries for which this DSA is the master.

2.  Slave copies of entries which are mastered in another DSA,
    indicated by a subordinate reference.  This copy must be
    maintained automatically by the DSA holding the master EDB.


Thus the master EDB contains a mixture of master entries, and entries
which are mastered elsewhere and shadowed by the DSA holding the
master EDB on an entry by entry basis.  Other DSAs may hold slave
copies of this EDB (slave EDBs), which are replicated in their
entirity directly or indirectly from the master EDB. This approach has
the following advantages.

 o  Name resolution is simplified, and performance improved.

 o  Single level searching and listing have good performance, and are
    straightforward to implement.  In a more general case of applying
    the standard, without sophisticated replication, these operations
    might require to access very many DSAs and be prohibitively
    expensive.


Hardcastle-Kille                                                Page 5




RFC 1276         Internet Directory Replication          November 1991