rfc1276.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

5  DSA Naming

All DSAs must be named in the DIT, and the master definition of the
presentation address stored in this entry.  X.500 (including some of
the extension work) implies that the presentation address information
is extensively replicated (manually).  The management overhead implied
by this is not acceptable.
Care must be taken to prevent deadlock in determining a DSAs address.
This is solved by:


1.  Use of a well known DSA with ``root knowledge''

2.  Naming DSAs in a manner which prevents deadlocks.  Currently this
    is done by giving DSAs names high in the DIT.

The Internet Pilot will need to define detailed policies for naming
DSAs, in conjunction with the replication policy.  This will be
defined in a future RFC.


6  Knowledge Representation


Knowledge information is represented in the DIT. It seems unreasonable
to manage this by any other means.  Knowledge information is
represented in an entry by use of knowledge attributes.  These
attributes are considered separately from all the other attributes in
the entry which are termed ``user attributes''.  Each entry in a
master EDB will be in one of four categories.

1.  The entry is a leaf entry mastered in this EDB, and so only
    contains user attributes

2.  The level below has an associated EDB (i.e., the DIT continues
    downwards to use the data model of this specification).  All
    attributes of this entry will be mastered in this entry.  The
    entry will contain an attribute with the name of the DSA which
    holds the master of the associated EDB. Optionally, it will
    contain an attribute holding the names of DSAs which hold slave
    EDBs.  The entry may not hold a subordinate reference attribute.
    The DIT is followed by use of the master and slave attributes.



Hardcastle-Kille                                                Page 6




RFC 1276         Internet Directory Replication          November 1991


3.  The entry is mastered in a DSA which does not follow this
    specification.  The entry in the EDB will contain a master
    attribute, which holds a subordinate reference (or cross
    reference) to the DSA which holds the master entry.  The user
    attributes of the entry will be mastered in the DSA pointed to by
    the reference.  The DSA holding the master EDB, which actually
    acts as an intermediate shadow for this entry, will read these
    attributes from the DSA indicated by the reference, so that it
    will have a full copy of the entry, using a standared DSP Read
    operation.  This technique is called ``spot shadowing''.  Any
    access control on the entry being spot shadowed must be configured
    so that all attributes can be copied by the DSA holding the master
    EDB. DSAs taking slave copies of the EDB will not do spot
    shadowing.  However, the knowledge attributes will be copied, and
    may be used by this DSA (e.g., for modify operations).

4.  The entries at the level below are held in DSAs which do not
    follow this specification, and all of these are indicated by a set
    of NSSRs (Non Specific Subordinate Reference).  The NSSRs are
    stored as an attribute of the entry.  The user attributes are
    either mastered in the EDB.
    It is important to note that NSSRs are stored at the level above
    subordinate references.  At a given point in the DIT, if there are
    subordinate references, these are stored in shadow entries below
    that point, and named by the RDN. If there are NSSRs, they are
    stored in the entry itself, as there is no RDN associated with an
    NSSR. This approach is cleanest where there are either NSSRs or
    subordinate references, but not both.  For example, consider an
    Organisation HP, whose many OUs are stored in a set of DSAs
    indicated by by NSSRs.  Here, the NSSR attributes will be used to
    identify these DSAs.
    This model of replication is not tightly integrated with NSSRs.
    Where there is a mixture of NSSRs and Subordinate references at a
    given point in the DIT, this is handled by giving a single
    subordinate reference to a DSA which follows standard X.500
    distributed operations and can cleanly handle this mixture.  In
    practice, this is equivalent to not allowing a mixture of
    subordinate references and NSSRs.

The information framework needed to support this is defined in
Figure_1.______________________________________________________________




Hardcastle-Kille                                                Page 7




RFC 1276         Internet Directory Replication          November 1991



InternetDSNonLeafObject ::= OBJECT-CLASS
        SUBCLASS OF top
        MUST CONTAIN {masterDSA}
        MAY CONTAIN {slaveDSA}

ExternalDSObject ::= OBJECT-CLASS
        SUBCLASS OF top
        MAY CONTAIN {SubordinateReference, CrossReference,          10
                NonSpecificSubordinateReference}
                        -- will contain exactly one of these references

MasterDSA ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
    SINGLE VALUE

SlaveDSA ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
                                                                    20
SubordinateReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint
    SINGLE VALUE

CrossReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint
    SINGLE VALUE

NonSpecificSubordinateReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint                               30

AccessPoint ::= SET {
        ae-title [0] Name,
        address  [2] PresentationAddress OPTIONAL }

                -- Same definition as X.500 AccessPoint,
                -- but presentation address is optional


___________________Figure_1:__Knowledge_Attributes_____________________

Two object classes are defined to support this approach:




Hardcastle-Kille                                                Page 8




RFC 1276         Internet Directory Replication          November 1991


InternetDSNonLeafObject This is for where the level below follows the
    model defined here, and there is an Entry Data Block (EDB)
    containing the sibling entries.  The Entry itself contains master
    data.  The associated attributes are:

    MasterDSA The name of the DSA where the master EDB is held.

    SlaveDSA The names of DSAs which hold slave copies of the EDB for
        public access.

ExternalDSObject This is for where the entry and levels below are
    mastered according to X.500.  There are attributes corresponding
    to the standard knowledge references, which are used to resolve
    queries.  The presentation address is optional in these
    attributes.  If not present, it should be looked up in the DSAs
    own entry.  For NonSpecificSubordinateReference, the master of the
    entry will be in the master EDB, For SubordinateReference or
    CrossReference1 the DSA which masters the EDB will ``spot shadow''
    the entry, by reading it at intervals.  This will ensure that the
    master EDB contains a copy of each entry.  Single level searching
    can then be done efficiently where it is not required to access
    the master copy of the data.  DSAs holding slave copies of the EDB
    do not perform spot shadowing, but do receive copies of the
    references.


7  Replication Protocol
_______________________________________________________________________
GetEntryDataBlock ABSTRACT-OPERATION
        ARGUMENT GetEntryDataBlockArgument
        RESULT GetEntryDataBlockResult
        ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}

EDBVersionError ABSTRACT-ERROR
        PARAMETER versionHeld EDBVersion


GetEntryDataBlockArgument ::= SET {                                 10

----------------------------
    1. These references are really the same.  The function and value
are the same.  The name depends on where the reference is stored.  It
may be preferable to have only one attribute.


Hardcastle-Kille                                                Page 9




RFC 1276         Internet Directory Replication          November 1991


        entry [0] DistinguishedName,
        CHOICE {
                sendIfMoreRecentThan [1] EDBVersion,
                getVersionNumber [2] NULL,
                getEDB [3] NULL,        -- force retrieval
                continuation [4] SEQUENCE {
                        EDBVersion,
                        nextEntryPosition INTEGER }
                },
        maxEntries [5] INTEGER OPTIONAL                             20
                        -- if omitted return whole EDB in
                        -- one operation
}

GetEntryDataBlockResult ::= SEQUENCE {
                versionHeld [0] EDBVersion,
                [1] SEQUENCE OF RelativeEntry OPTIONAL,
                        -- if omitted, only version is returned
                nextEntryPostion INTEGER OPTIONAL
                        -- if omitted there are no more entries     30
        }



RelativeEntry ::= SEQUENCE {
        RelativeDistinguishedName,
        SET OF Attribute
        }

EDBVersion ::= UTCTime                                              40

___________________Figure_2:__Replication_Protocol_____________________

A ROS operation to support replication is defined in Figure 2.  This
pulls an entire copy of the EDB. In normal use, the initiator
specifies the EDB Version held.  If the responder has a more recent
version, then all of the entries in the EDB are returned.  There are
options to rerequest only the version of EDB held, or to return the
full EDB irrespective of the version held by the initiator.
For large EDBs, transfer of an entire EDB in a single operation would
lead to very large ROS PDUs.  This gives a definite scaling
limitation.  To overcome this, the protocol allows an EDB to be
retrived in chunks of a size (in number of entries) specified by the


Hardcastle-Kille                                               Page 10




RFC 1276         Internet Directory Replication          November 1991


initiator.  The responder specifies a number which indicates the next
entry to be transferred.  The same operation can be used to retrieve
the next chunk of the EDB, with EDBVersion and the same integer as
parameters.
This approach is simple to implement.  It is less efficient than an
incremental technique.  When scaling dictates that an incremental
technique must be used, it is expected that a suitable standard will
be available.
An implementation issue that must be noted is how to deal with updates
whilst a multi-operation transfer is in progress.  There are two
possible approaches:


1.  Refuse/block updates until the EDB is transferred.  This may cause
    problems where the rate of update and transfer is high, as this
    may make update very difficult (for the manager).

2.  Create a new version of the EDB, whilst retaining the old EDB to
    complete the bulk transfer.  A suitable retentions strategy would
    be to hold an EDB version as long as the association on which it
    is being pulled it remains active.

3.  Allow the update and fail subsequent transfer requests for the
    EDB. This may cause both transfer failure and excessive waste of
    bandwidth due to retries if the rate of update and transfer is
    high.

If option 1.  or 3.  is chosen, for a widely replicated EDB where the
update rate is greater than a few changes per day, it is recommended
to configure the master EDB in a DSA which only replicates to one
other DSA. This second DSA can then control its update rate, and
safely perform a large fanout of replications (option 3).  The first
DSA will have reasonable availability for modifications (option 1).

This protocol will be used by DSAs to obtain copies of EDBs high in
the tree (typically root and national EDBs).  DSAs which need these
copies should establish bilateral agreements to access them2.
This protocol should only transfer user attributes.  In particular,
implementation specific attributes such as those needed to support

----------------------------
    2. QUIPU defines some attributes to register such agreements, but
these are probably not appropriate for this specification.


Hardcastle-Kille                                               Page 11




RFC 1276         Internet Directory Replication          November 1991