RFC relevance of replication

As per Relevance of the word replication, we have this rfc below:

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

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

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

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

RFC 1276 Internet Directory Replication November 1991

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

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

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

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

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

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

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

o It is proven in operation. This RFCis simply documenting what
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
less. It will therefore be much more attractive to add into
implementation, as it is less effort, and can be further ahead
the standard

These procedures are an INTERIM approach. There are
deficiencies, both in terms of manageability and scalability
Transition to standard approaches are planned when
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

The distributed operations of X.500 assume that all DUAs and DSAs
fully interconnected with a global network service. For the
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
straightforward. We define the term community as an environment
direct (network) communication is possible. Communities may
separated because they operate different protocols, or because of
of physical connectivity. Example communities are the DARPA/
Internet, and the Janet private X.25 network. A network entity in
community is addressed by its Network Address. If two
entities are in the same community, they can by
communicate. A community is identified by a set of network
prefixes. For the approach to be useful, this set should be
(typically 1). For TCP/IP Networks, and X.25 Networks not
CONS, the approach is described in [HK91a] allows for communities
be defined for the networks of operational interest

This model can be used to determine whether a pair of
entities can communicate. For each entity, determine the
address (typically by directory lookup). Each network address in
presentation address will have a single associated community. The
of communities to which each application entity belongs can thus
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
or DSA (the calling entity) to resolve a query. The local
determines that the query must be progressed by another DSA (
referred-to DSA). The DSA will make a chain/referral choice.
chaining is prohibited by service control, a referral will
passed back. Otherwise, if the local DSA prefers to chain (e.g.,
for policy reasons) it will then chain. The remaining
is that the local DSA prefers to give a referral. It shall
do so if it believes that the calling entity can directly
to the referred-to DSA. If the calling entity is a DUA, it
be assumed to belong only to the community of the called
address. If the calling entity is a DSA, its communities
be determined by lookup of the DSA's presentation address in
directory. The communities of the referred-to DSA can

Hardcastle-Kille Page 3

RFC 1276 Internet Directory Replication November 1991

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

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

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

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

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

3 Alternative

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

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

Hardcastle-Kille Page 4

RFC 1276 Internet Directory Replication November 1991

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

4 Data

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

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

o Name resolution is simplified, and performance improved

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

Hardcastle-Kille Page 5

RFC 1276 Internet Directory Replication November 1991

5 DSA

All DSAs must be named in the DIT, and the master definition of
presentation address stored in this entry. X.500 (including some
the extension work) implies that the presentation address
is extensively replicated (manually). The management overhead
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
is done by giving DSAs names high in the DIT

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

6 Knowledge

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

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

2. The level below has an associated EDB (i.e., the DIT
downwards to use the data model of this specification).
attributes of this entry will be mastered in this entry.
entry will contain an attribute with the name of the DSA
holds the master of the associated EDB. Optionally, it
contain an attribute holding the names of DSAs which hold
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
specification. The entry in the EDB will contain a
attribute, which holds a subordinate reference (or
reference) to the DSA which holds the master entry. The
attributes of the entry will be mastered in the DSA pointed to
the reference. The DSA holding the master EDB, which
acts as an intermediate shadow for this entry, will read
attributes from the DSA indicated by the reference, so that
will have a full copy of the entry, using a standared DSP
operation. This technique is called ``spot shadowing''.
access control on the entry being spot shadowed must be
so that all attributes can be copied by the DSA holding the
EDB. DSAs taking slave copies of the EDB will not do
shadowing. However, the knowledge attributes will be copied,
may be used by this DSA (e.g., for modify operations).

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

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

Hardcastle-Kille Page 7

RFC 1276 Internet Directory Replication November 1991

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

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

MasterDSA ::=
WITH ATTRIBUTE-SYNTAX
SINGLE

SlaveDSA ::=
WITH ATTRIBUTE-SYNTAX
20
SubordinateReference ::=
WITH ATTRIBUTE-SYNTAX
SINGLE

CrossReference ::=
WITH ATTRIBUTE-SYNTAX
SINGLE

NonSpecificSubordinateReference ::=
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

___________________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
model defined here, and there is an Entry Data Block (EDB
containing the sibling entries. The Entry itself contains
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
public access

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

7 Replication
_______________________________________________________________________
GetEntryDataBlock ABSTRACT-
ARGUMENT
RESULT
ERRORS {nameError,ServiceError,SecurityError,EDBVersionError

EDBVersionError ABSTRACT-
PARAMETER versionHeld

GetEntryDataBlockArgument ::= SET { 10

----------------------------
1. These references are really the same. The function and
are the same. The name depends on where the reference is stored.
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
continuation [4] SEQUENCE {
EDBVersion
nextEntryPosition INTEGER }
},
maxEntries [5] INTEGER OPTIONAL 20
-- if omitted return whole EDB
-- one

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

RelativeEntry ::= SEQUENCE {
RelativeDistinguishedName
SET OF
}

EDBVersion ::= UTCTime 40

___________________Figure_2:__Replication_Protocol_____________________

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

Hardcastle-Kille Page 10

RFC 1276 Internet Directory Replication November 1991

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

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

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

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

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

This protocol will be used by DSAs to obtain copies of EDBs high
the tree (typically root and national EDBs). DSAs which need
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

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

Hardcastle-Kille Page 11

RFC 1276 Internet Directory Replication November 1991

private access control should not be transferred. There may
bilateral agreements on access control policy of the
(e.g., size limits on listing), which are implemented by (different
system specific techniques

8 New Application

A DSA which follows these procedures will support a
ApplicationContext ``Internet DSP'' defined in Appendix A. This
be stored in the DSAs entry, so that support of the extensions
here can easily be determined

9 Policy on Replication

To be effective, a directory configuration must be laid out.
protocols will need to be used in the framework of a pilot,
service providers making available data for replication
There is a requirement to manage the replication process. This can
done by a combination of local configuration (to register
agreements) and directory operations to set pointers to master
slave copies of the data

10 Use of the Directory by

Care must be taken by users of the directory when replication
available. This is not a change from current use of X.500, but
noted here as it is important. Normal read requests should allow
of copy information. If the user of the directory believes
information may be out of date (e.g., because an association could
be established), then the request should be repeated and use of
data prohibited by service controls

11 Migration and

The major scaling limit of this approach is the non-
update. This will put a limit on the maximum DIT fanout which can
supported. Given an average entry size of around a thousand bytes
and a maximum reasonable transfer size is tens of megabytes, then

Hardcastle-Kille Page 12

RFC 1276 Internet Directory Replication November 1991

fanout limit of this approach is of order 10 000. Note that
organisations will tend to be registered geographically (e.g., in
US, by State), so that the limit of the number of Organisations
somewhat larger. It should be noted that although the
technique described here is general, it is only intended for
levels of the DIT. These figures assume this
These techniques do not preclude use of other techniques
replication. It would be quite reasonable to replicate data
this approach, and that which will be defined in X.500(92).

[HK91a] S.E. Hardcastle-Kille. Encoding network addresses to
operation over non-osi lower layers. Request for
RFC 1277, Department of Computer Science, University
London, November 1991.

[HK91b] S.E. Hardcastle-Kille. Replication requirement to provide
internet directory using X.500. Request for
RFC 1275, Department of Computer Science, University
London, November 1991.

12 Security

Security considerations are not discussed in this memo

13 Author's

Steve Hardcastle-
Department of Computer
University College
Gower
WC1E 6

Phone: +44-71-380-7294

EMail: S.Kille@CS.UCL.AC.

Hardcastle-Kille Page 13

RFC 1276 Internet Directory Replication November 1991

A ASN.1 Summary and Object Identifier

There_are_a_few_object_identifiers_needed.__These_are_defined_here.____

InternetDSP TAGS ::=

APPLICATION-SERVICE-ELEMENT, PORT, APPLICATION-CONTEXT
aCSE, ABSTRACT
FROM Remote-Operations-Notation-extension {joint-iso-
remote-operations(4) notation-extension(2)}

10
id-as-mrse, id-as-mase, id-as-
FROM MTSAccessProtocol {joint-iso-ccitt mhs-motis(6)
protocols(0) modules(0) object-identifiers(0)}

chainedReadASE, chainedSearchASE,
FROM DirectorySystemProtocol {joint-iso-ccitt ds(5)
modules(1) dsp(12)}

DistinguishedName, RelativeDistinguishedName,
FROM InformationFramework {joint-iso-ccitt ds(5) 20
modules(1) InformationFramework(1)}

ATTRIBUTE, OBJECT-
FROM InformationFramework {joint-iso-ccitt ds(5)
modules(1) informationFramework(1)};

internet-dsp OBJECT IDENTIFIER ::= {ccitt data(9) pss(2342) 30
ucl(19200300) internet-dsp(107)}

--

at OBJECT IDENTIFIER ::= {internet-dsp at(1)}
oc OBJECT IDENTIFIER ::= {internet-dsp oc(2)}

-- Object Classes needed for

Hardcastle-Kille Page 14

RFC 1276 Internet Directory Replication November 1991

40
id-ac-idsp OBJECT IDENTIFIER ::= {internet-dsp ac-idsp(3))}
id-as-idsp OBJECT IDENTIFIER ::= {internet-dsp as-idsp(4))}
id-ase-replication OBJECT IDENTIFIER ::= {internet-dsp ase-replication(5))}

-- Attribute

master-dsa MasterDSA ::= {at 1}
slave-dsa SlaveDSA ::= {at 2}
subordinate-reference SubordinateReference ::= {at 3} 50
cross-reference CrossReference ::= {at 4}
nssr NonSpecificSubordinateReference ::= {at 5}

-- Object

internet-ds-non-leaf-object InternetDSNonLeafObject ::= {oc 1}
external-ds-object ExternalDSObject ::= {oc 2}

-- Operation and Error bindings 60

getEntryDataBlock GetEntryDataBlock ::= 10

eDBVersionError EDBVersionError ::= 10

-- Protocol

replicationASE APPLICATION-SERVICE-
OPERATIONS {getEntryDataBlock} 70
::= id-ase-

internet-dsp APPLICATION-
APPLICATION SERVICE ELEMENTS {aCSE
BIND
UNBIND
REMOTE OPERATIONS {rOSE
OPERATIONS OF { chainedReadADSm chainedSearchASE
chainedModifyASE, replicationASE }
ABSTRACT SYNTAXES { 80
id-as-acse
id-as-idsp }
::= id-ac-

Hardcastle-Kille Page 15

RFC 1276 Internet Directory Replication November 1991

90
InternetDSNonLeafObject ::= OBJECT-
SUBCLASS OF
MUST CONTAIN {masterDSA
MAY CONTAIN {slaveDSA

ExternalDSObject ::= OBJECT-
SUBCLASS OF
MAY CONTAIN {SubordinateReference, CrossReference
NonSpecificSubordinateReference
-- will contain exactly one of these references100

MasterDSA ::=
WITH ATTRIBUTE-SYNTAX
SINGLE

SlaveDSA ::=
WITH ATTRIBUTE-SYNTAX

SubordinateReference ::=
WITH ATTRIBUTE-SYNTAX AccessPoint 110
SINGLE

CrossReference ::=
WITH ATTRIBUTE-SYNTAX
SINGLE

NonSpecificSubordinateReference ::=
WITH ATTRIBUTE-SYNTAX

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

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

GetEntryDataBlock ABSTRACT-

Hardcastle-Kille Page 16

RFC 1276 Internet Directory Replication November 1991

ARGUMENT
RESULT
ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}130

EDBVersionError ABSTRACT-
PARAMETER versionHeld

GetEntryDataBlockArgument ::= SET {
entry [0] DistinguishedName
CHOICE {
sendIfMoreRecentThan [1] EDBVersion
getVersionNumber [2] NULL, 140
getEDB [3] NULL, -- force
continuation [4] SEQUENCE {
EDBVersion
nextEntryPosition INTEGER }
},
maxEntries [5] INTEGER
-- if omitted return whole EDB
-- one

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

160
RelativeEntry ::= SEQUENCE {
RelativeDistinguishedName
SET OF
}

EDBVersion ::=

___________________Figure_3:__Summary_of_the_ASN.1_____________________

Hardcastle-Kille Page 17

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX