(unknown)
"Uppili.Srinivasan" <[email protected]> Sun, 19 Oct 2003 18:41:47 -0700
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <003201c396ab$5b4c31c0$93c81990@acer> |
This is a multi-part message in MIME format.
------=_NextPart_000_002E_01C39670.A6BE51A0
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_002F_01C39670.A6BE51A0"
------=_NextPart_001_002F_01C39670.A6BE51A0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Drafts Editor -
Please publish the attached as draft-ietf-ldup-model-09.txt.
LDUPers -
Attached is the latest version of the LDUP Profiles draft. I have made =
the changes that have been suggested by various reviewers. Most notably, =
thanks to Jerry Maziarsky for a detailed review and comments to address =
areas ambiguity. =20
Per the plan stated in Vienna, I would like to submit this for WG last =
call.
The following edits have been made in this version of the draft:
(1) The relationships between different deployment configurations =
(single vs multi-master) and consistency models (synchronous vs =
asynchronous) are clarified.=20
(2) The architecture spells out that the DITs of replicating directories =
need not be symmetric. Only the areas under replication need be. =20
(3) A section is added to highlight availability considerations when =
nodes are added, deleted or upgraded without adversely affecting total =
system up-time, since one of the objectives of replication is high =
availability.=20
(4) The scope of LDUP is clarified as not for only among homogenous =
DSAs (same vendor) but also for heterogeneous DSAs (multi-vendor).
Thanks,
Uppili Srinivasan
------=_NextPart_001_002F_01C39670.A6BE51A0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D""><FONT size=3D2>Drafts Editor =
-<BR><BR>Please=20
publish the attached as draft-ietf-ldup-model-09.txt.<BR><BR>LDUPers=20
-<BR><BR>Attached is the latest version of the LDUP Profiles =
draft. I have=20
made the changes that have been suggested by various reviewers. Most =
notably,=20
thanks to Jerry Maziarsky for a detailed review and comments to address =
areas=20
ambiguity. <BR><BR>Per the plan stated in Vienna, I would =
like to=20
submit this for WG last call.<BR><BR>The following edits have been made =
in this=20
version of the draft:<BR><BR>(1) The relationships between different =
deployment=20
configurations (single vs multi-master) and consistency models =
(synchronous vs=20
asynchronous) are clarified. <BR><BR>(2) The architecture spells out =
that the=20
DITs of replicating directories need not be symmetric. Only the =
areas=20
under replication need be. <BR><BR>(3) A section is added to =
highlight=20
availability considerations when nodes are added, deleted or upgraded =
without=20
adversely affecting total system up-time, since one of the objectives of =
replication is high availability. <BR><BR>(4) The scope of LDUP is =
clarified as=20
not for only among homogenous DSAs (same vendor) but also for=20
heterogeneous DSAs (multi-vendor).<BR><BR>Thanks,<BR>Uppili=20
Srinivasan</FONT></BODY></HTML>
------=_NextPart_001_002F_01C39670.A6BE51A0--
------=_NextPart_000_002E_01C39670.A6BE51A0
Content-Type: text/plain;
name="draft-ietf-ldup-model-09.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-ldup-model-09.txt"
=20
Internet Draft John Merrells
Document: draft-ietf-ldup-model-09.txt Sleepy Cat Software, Inc
Expires: March 2004 Uppili Srinivasan
Oracle Corportation
Ed Reed
Novell Corporation
October =
2003
=20
=20
LDAP Replication Architecture=20
=20
Status of this Memo=20
=20
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.=20
=20
Internet-Drafts are working documents of the Internet Engineering=20
Task Force (IETF), its areas, and its working groups. Note that=20
other groups may also distribute working documents as Internet-
Drafts.=20
=20
Internet-Drafts are draft documents valid for a maximum of six=20
months and may be updated, replaced, or obsoleted by other documents=20
at any time. It is inappropriate to use Internet-Drafts as=20
reference material or to cite them other than as "work in progress."=20
=20
The list of current Internet-Drafts can be accessed at=20
http://www.ietf.org/1id-abstracts.html=20
The list of Internet-Draft Shadow Directories can be accessed at=20
http://www.ietf.org/shadow.html=20
=20
This draft, file name draft-ietf-ldup-model-08.txt, is intended to=20
be become a Proposed Standard RFC, to be published by the IETF=20
Working Group LDUP. Distribution of this document is unlimited.=20
Comments should be sent to the LDUP Replication mailing list=20
<[email protected]> or to the authors.=20
=20
This Internet-Draft expires September 2003=20
=20
1 Abstract=20
=20
This architectural document outlines a suite of schema and protocol=20
extensions to LDAPv3 that enables the robust, reliable, server-to-
server exchange of directory content and changes.=20
=20
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20
this document are to be interpreted as described in RFC 2119=20
[RFC2119]. The sections below reiterate these definitions and=20
include some additional ones.=20
=20
=0C LDAP Replication Architecture Model October 2003 =20
=20
=20
2 Table of Contents=20
Status of this Memo.................................................1=20
1 Abstract ........................................................1=20
2 Table of Contents ...............................................2=20
3 Introduction ....................................................3=20
3.1 Scope 3=20
3.2 Document Objectives 4=20
3.3 Document Non-Objectives 5=20
3.4 Existing Implementations 5=20
3.5 Terms and Definitions 6=20
3.6 Deployment Topologies and Associated Consistency Models 7=20
3.7 LDAP Constraints 8=20
4 Replication Environment .........................................9=20
4.1 Primary Replica 9=20
4.2 Master Replica 10=20
4.3 Read-Only Replica 10=20
4.4 Fractional Replicas 10=20
5 Information Model ..............................................10=20
5.1 Sub-Entries 11=20
5.2 Glue Entries 11=20
5.3 Unique Identifiers 11=20
5.4 Change Sequence Number 11=20
5.5 Entries, Semantics and Relationships 13=20
5.6 Root DSE Attributes 13=20
5.7 Replication Context Auxiliary Object Class and Entries 14=20
5.8 Replica Object Class and Entries 14=20
5.9 Lost and Found Entry 14=20
5.10 Replication Agreement Object Class and Entries 14=20
6 Replication of Directory Administrative Policy Information .....16=20
6.1 Schema Replication 16=20
7 Change Representation and Update Resolution ....................16=20
7.1 Entry Creation and Deletion 17=20
7.2 Attribute Creation and Deletion 17=20
7.3 Attribute Value Changes 17=20
7.4 Update Inconsistency 18=20
8 LDUP Update Transfer Protocol Framework ........................18=20
8.1 Replication Session Initiation 18=20
8.2 Start Replication Session 19=20
8.3 Update Transfer 19=20
8.4 End Replication Session 20=20
8.5 Major States of Replicas 20=20
8.6 Integrity & Confidentiality 21=20
9 LDUP Update Protocols ..........................................21=20
9.1 Replication Updates and Update Primitives 21=20
9.2 Fractional Updates 22 10 =
LDUP Full Update Transfer Protocol .............................22=20
10.1 Full Update Transfer 22=20
10.2 Replication Update Generation 22=20
10.3 Replication Update Consumption 22=20
=20
=0C LDAP Replication Architecture Model October =
2003 =20
10.4 Full Update, End Replication Session 22=20
10.5 Interrupted Transmission 22=20
11 LDUP Incremental Update Transfer Protocol ......................23=20
11.1 Update Vector 23=20
11.2 Supplier Initiated, Incremental Update, Start Replication=20
Session 24 =
11.3 Replication Update Generation 24=20
11.4 Replication Update Consumption 25=20
11.5 Update Resolution Procedures 25=20
11.6 Incremental Update, End Replication Session 27=20
11.7 Interrupted Transmission 27=20
12 Purging State Information ......................................27=20
12.1 Purge Vector 27=20
12.2 Purging Deleted Entries, Attributes, and Attribute Values 28=20
13 Replication Configuration and Management .......................28=20
14 Availability Considerations ....................................30=20
15 Security Considerations ........................................30=20
15.1 Audit Capabilities 31=20
16 Acknowledgements ...............................................31=20
17 References .....................................................31=20
18 Authors' Address ...............................................34=20
19 Appendix A _ LDAP Constraints ..................................34=20
19.1 LDAP Constraints Clauses 34=20
19.2 LDAP Data Model Constraints 35=20
19.3 LDAP Operation Behaviour Constraints 36=20
19.4 New LDAP Constraints 37=20
=20
3 Introduction=20
=20
3.1 Scope=20
=20
This architectural document provides an outline of an LDAP based=20
replication scheme. Further detailed design documents will draw=20
guidance from here.=20
=20
The design proceeds from prior work in the industry, including=20
concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory=20
Information Shadowing Protocol (DISP) [X525], experience with widely=20
deployed distributed directories in network operating systems,=20
electronic mail address books, and other database technologies. The=20
emphasis of the design is on:=20
=20
a) Simplicity of operation.=20
b) Flexibility of configuration.=20
c) Manageability of replica operations among mixed heterogeneous=20
vendor LDAP servers under common administration.=20
=20
d) Security of content and configuration information when LDAP=20
servers from more than one administrative authority are=20
interconnected.=20
=20
=0C LDAP Replication Architecture Model October =
2003 =20
=20
The architecture and the protocols are intended to support=20
heterogeneous directory networks consisting of LDAP server instances=20
based on different vendor implementations.=20
=20
A range of deployment scenarios is supported, including multi-master=20
and single-master topologies. Replication networks may include=20
transitive and redundant relationships between LDAP servers.=20
=20
The controlling framework used to define the relationships, types,=20
and state of replicas of the directory content is defined. In this=20
way the directory content can itself be used to monitor and control=20
the replication network. The directory schema is extended to define=20
object classes, auxiliary classes, and attributes that describe=20
areas of the namespace which are replicated, LDAP servers which hold=20
replicas of various types for the various partitions (_Replication=20
Contexts_) of the namespace, LDAP Access Points (network addresses)=20
where such LDAP servers may be contacted, which namespace replicas=20
are held on given LDAP servers, and the progress of replication=20
operations. Among other things, this knowledge of where directory=20
content is located could serve as the basis for dynamic generation=20
of LDAP referrals.=20
=20
An update transfer protocol, which actually brings a replica up to=20
date with respect to changes in directory content at another=20
replica, is defined using LDAPv3 protocol extensions. The=20
representation of directory content and changes will be defined by=20
the LDAP Replication Update Transfer Protocol sub-team. Incremental=20
and full update transfer mechanisms are described. Replication=20
protocols are required to include initial population, change=20
updates, and removal of directory content.=20
=20
Security information, including access control policy will be=20
treated as directory content by the replication protocols. =20
Confidentiality and integrity of replication information is required=20
to be provided by lower-level transport/session protocols such as=20
IPSEC and/or TLS.=20
=20
3.2 Document Objectives=20
The objectives of this document are:=20
=20
a) To present the architecture and theory of operation for LDUP so=20
that it provides a consistent basis for all detailed design=20
documents associated with this LDAP replication service. The=20
Information Model, Update Transfer Protocol, and Update Resolution=20
Procedure documents are among the targeted LDUP design documents.=20
b) To provide an architectural solution for each clause of the=20
requirements document [LDUP Requirements].=20
c) To collect and summarize LDAP Data Model and Operational Behavior=20
constraints defined for LDAP in RFC 2251 [See Appendix A], that are=20
to be preserved in LDAP replication.=20
=20
=0C LDAP Replication Architecture Model October 2003
=20
d) Where possible, to derive and present appropriate information=20
from other ongoing IETF work (to the extent necessary to further=20
define LDUP). The purpose such an exercise would be to avoid tying=20
the LDUP working group to the schedule of any other working group.=20
=20
e) Present some useful concepts and their utility that are supported=20
in existing commercial directory products. Even if these concepts=20
were not adopted by subsequent LDUP protocol standards, it would=20
still be useful to relate the LDUP design choices and alternatives.=20
=20
In addition to the above objectives document has to address, it=20
should do so without infringing upon known registered intellectual=20
property rights.=20
=20
=20
3.3 Document Non-Objectives=20
=20
This document does not address the following issues, as they are=20
considered beyond the scope of the Working Group.=20
A) How LDAP becomes a distributed directory. There are many issues=20
beyond replication that should be considered. Such as, support for=20
external references, algorithms for computing referrals from the=20
distributed directory knowledge, etc.=20
=20
B) Specifying management protocols to create Replication Contexts or=20
new Replicas. LDAP may be sufficient for this. The document=20
describes how new Replication Contexts and Replicas are represented,=20
in the directory, as entries, attributes, and attribute values.=20
=20
C) How transactions will be replicated. However, the architecture=20
should not knowingly prevent or impede them, given the Working=20
Group's incomplete understanding of the issues at this time.=20
=20
D) The problems of replication between implementations without a=20
common schema representation, and hence require information mapping=20
to achieve synchronization between them.=20
=20
3.4 Existing Implementations=20
=20
In order to define a standard replication scheme that may be readily=20
implemented we must consider the architectures of current LDAP=20
server implementations. Existing systems currently support=20
proprietary replication schemes based on one of two general=20
approaches: log-based or state-based. The approach chosen in=20
subsequent LDUP protocol design is neither stipulated nor assumed in=20
this architecture draft, although certain sections of this document=20
contain discussions of issues in the above approaches. =20
=20
Implementations based on the original University of Michigan LDAP=20
server code record LDAP operations to a operation log. During a=20
replication session operations are replayed from this log to bring=20
the Consumer replica up to date. Example implementations of this=20
=20
LDAP Replication Architecture Model October 2003 =20
type at this time are the IBM SecureWay, Innosoft, Netscape, Open LDAP =
and Oracle directory servers.=20
=20
3.5 Terms and Definitions=20
The definitions from the Replication Requirements document have been=20
copied here and extended.=20
=20
For brevity, an LDAP server implementation is referred to throughout=20
as 'the server'.=20
=20
The LDAP update operations; Add, Delete, Modify, Modify RDN (LDAPv2)=20
and Modify DN (LDAPv3), are collectively referred to as LDAP Update=20
Operations.=20
=20
A Naming Context is a subtree of entries in the Directory=20
Information Tree (DIT). There may be multiple Naming Contexts=20
stored on a single server. Naming Contexts are defined in section 17=20
of [X501].=20
=20
A _Replication Context_ represents a section of DIT defining a unit=20
of administration for replication. A Replication Context is based=20
at an entry identified as its root and includes all its subordinate=20
entries down the tree to its leaves, or until another Replication=20
Context is encountered. A Naming Context held by a server may be=20
made up of one or more non-overlapping Replication Contexts. Non-
replicated portions of a Naming Context may not be explicitly=20
identified as a Replication Context.=20
=20
A Replica is a replicated instance of a _Replication Context.=20
=20
A _Replication Context_ is said to be single-mastered if there is=20
only one Replica where it may be updated, and multi-mastered if=20
there is more than one Replica where it may be updated.=20
=20
A Replication Relationship is established between two or more=20
Replicas that are hosted on servers that cooperate to service a=20
common area (the Replication Context) of the DIT. =20
=20
The DIT of servers that host replicas need not be entirely=20
symmetric. The DIT areas of the related Replicas among the servers=20
are expected to be symmetric, but each server could potentially=20
maintain additional DIT areas that are independent.=20
=20
A Replication Agreement is defined between two parties of a=20
Replication Relationship. A Replication Agreement is associated=20
with a set of replicas and defines properties such as the Update=20
Transfer Protocol to be used, and the Replication Schedule of a=20
Replication Session.=20
=20
A Replication Session is an LDAP session between the two servers=20
identified by a replication agreement. Interactions occur between=20
=20
LDAP Replication Architecture Model October 2003 =20
the two servers, resulting in the transfer of updates from the=20
supplier replica to the consumer replica.=20
=20
The Initiator of a Replication Session is the initiating server.=20
=20
A Responder server responds to the replication initiation request=20
from the Initiator server.=20
=20
A Supplier server is the source of the updates to be transferred.=20
=20
A Consumer server is the recipient of the update sequence.=20
=20
The Update Transfer Protocol is the means by which the Replication=20
Session proceeds. It defines the protocol for exchanging updates=20
between the Replication Relationship partners.=20
=20
A Replication Update is an LDAP Extended Operation that contains=20
updates to be applied to the DIT. The Update Transfer Protocol=20
carries a sequence of these messages from the Supplier to the=20
Consumer.=20
=20
The Update Resolution Procedures repair constraint violations that=20
occur when updates to a multi-mastered Replica collide.=20
=20
A Fractional Entry Specification is a list of entry attributes to be=20
included, or a list of attributes to be excluded in a replica. An=20
empty specification implies that all entry attributes are included.=20
=20
A Fractional Entry is an entry that contains only a subset of its=20
original attributes. It results from the replication of changes=20
governed by a Fractional Entry Specification.=20
A Fractional Replica is a replica that holds Fractional Entries of=20
its Replication Context.=20
=20
3.6 Deployment Topologies and Associated Consistency Models=20
=20
This replication architecture supports a loose consistency model=20
between replicas of a naming context. It does not attempt to provide=20
the appearance of a single copy of a replica. The contents of each=20
replica may be different, but over time they will be converging=20
towards the same state. This architecture is not intended to support=20
LDAP Clients that require a tight consistency model, where the state=20
of all replicas is always equivalent. =20
=20
While LDUP architecture does not support tight consistency where all=20
replicas are identical in content all the time, LDAP clients can=20
achieve different levels of consistency by following appropriate=20
configuration and access discipline, depending upon the LDUP=20
replication topology.=20
=20
Three levels of consistency are available to LDAP Clients, which are=20
characterized by their LDAP replication deployment topologies.=20
Single-Server, where there is just the Replication Context and no=20
=20
=0C LDAP Replication Architecture Model October 2003 =
replicas. Single-master, where there are replicas, but only one may=20
be updated. And, multi-master, where there is more than one replica=20
to which LDAP update operations may be directed. The consistency=20
properties of each model are rooted in their serialization of read=20
and write operations.=20
=20
1) A single-server deployment of a Replication Context provides=20
tight consistency to LDAP applications. LDAP Clients have no choice=20
but to direct all their operations to a single server, serializing=20
both read and write operations.=20
=20
2) A single-mastered deployment of a Replication Context provides=20
both tight and loose consistency to LDAP applications. LDAP Clients=20
must direct all write operations to the single Master Replica, but=20
may direct their reads to any of the replicas. A client experiences=20
tight consistency by directing all its operations to the single=20
Master Replica, and loose consistency by directing any read=20
operations to any other replica.=20
=20
3) A multi-mastered deployment of a Replication Context can provide=20
only loose consistency to LDAP applications. Across the system=20
writes and reads are not serialized. An LDAP Client could direct=20
their read and write operations to a single Master Replica, but they=20
will not receive tight consistency as interleaved writes could be=20
occurring at another replica.=20
=20
Tight consistency can be achieved in a multi-master deployment for a=20
particular LDAP application if and only if all instances of its=20
client are directed towards the same Master Replica, and the=20
application data is not updated by any other LDAP application.=20
Introducing these constraints to an application ensures that writes=20
are serialized providing tight consistency for the application.=20
=20
Future work could make use of the architecture proposed in this=20
document as a basis for allowing clients to request session=20
guarantees from a server when establishing a connection.=20
=20
3.7 LDAP Constraints=20
=20
The LDAP-v3 Internet RFC [LDAPv3] defines a set of Data Model and=20
Operation Behavior constraints that a compliant LDAP server must=20
enforce. The server must reject an LDAP Update Operation if its=20
application to the target entry would violate any one of these LDAP=20
Constraints. [Appendix A contains the original text clauses from RFC=20
2251, and also a summary.]=20
=20
In the case of a single-server or single-mastered Replication=20
Context all LDAP Constraints are immediately enforced at the single=20
Master Replica. An error result code is returned to an LDAP Client=20
that presents an operation that would violate the constraints.=20
=20
In the case of a multi-mastered Replication Context not all LDAP=20
Constraints can be immediately enforced at the Master Replica to=20
which the LDAP Update Operation is applied. This loosely consistent=20
=20
=0C LDAP Replication Architecture Model October 2003 =
=20
replication architecture ensures that at each replica all constraints =
are imposed, but as updates are replicated constraint violations arise =
that cannot be reported to the appropriate client. Any constraint =
violations that occur are repaired by a set of update=20
resolution procedures.=20
=20
Any LDAP client that has been implemented to expect immediate=20
enforcement of all LDAP Constraints may not behave as expected=20
against a multi-mastered Replication Context.=20
=20
4 Replication Environment=20
=20
The replication environment would consist of two or more replicas,=20
each characterized with a "replica type". The following replica=20
types are recognized. =20
=20
Note that LDUP protocol design could choose to not support all the=20
types defined below.=20
=20
4.1 Primary Replica=20
=20
The Primary Replica is a full copy of the Replica, to which all=20
applications that require tight consistency should direct their LDAP=20
Operations. There can be only one Primary Replica within the set of=20
Replicas of a given Replication Context. It is also permissible for=20
none of the Replicas to be designated the Primary. The Primary=20
Replica MUST NOT be a Fractional Replica.=20
=20
Some commercial directory products support the notion of a primary=20
replica. This would mean that one of the replicas can be configured=20
to be the "primary" (at any point in time) and certain attributes=20
could be marked as "critical", meaning that they could only be=20
altered on a primary. This configuration would cause all other=20
replicas to deny alterations to these critical attributes and to direct =
such modifications transparently (via referrals) to the designated =
primary.
To remain simple, LDUP Update Protocol is NOT REQUIRED to support =
"Primary Replica". Where necessary, it may be possible for =
administrators to implement appropriate access policies and other means =
of operation redirection to enforce the "primary replica" conventions.=20
=20
=0C LDAP Replication Architecture Model October 2003 =
=20
4.2 Master Replica=20
=20
A Master Replica is a Replica that accepts all the LDAP Update=20
Operations, but is not the Primary Replica. There could be none,=20
one, or many Master Replicas within the set of Replicas of a given=20
Replication Context. A Master Replica MUST NOT be a Fractional=20
Replica for this version of LDUP.=20
=20
4.3 Read-Only Replica=20
=20
A Read-Only Replica will accept only non-modifying LDAP operations=20
against data subject to replication. Modifications to DSA-operation=20
attributes, which are not replicated, may of course still be=20
allowed. All other modification operations shall be referred to a=20
Master Replica. The server referred to may be a Supplier of this=20
Replica. =20
=20
4.4 Fractional Replicas=20
=20
Fractional Replicas must always be Read-Only. All LDAP Update=20
Operations must be referred to a Master Replica in this version of=20
LDUP. The server referred to may be a Supplier of this Fractional=20
Replica.=20
=20
5 Information Model=20
=20
This section describes the schema elements that represent the=20
replication topology and replication run time information. The=20
operational information for replication is administered through=20
these entries. The LDUP Working Group will work towards defining an=20
Internet standard to fully detail all these schema elements.=20
=20
LDAP Replication Architecture Model October 2003 =20
=20
5.1 Sub-Entries=20
=20
Replication management entries are to be stored at the base of the=20
Replication Context. They will be of a `ldapSubentry' objectclass=20
to exclude them from regular searches. Entries with the objectclass=20
ldapSubentry are not returned as the result of a search unless a=20
control is included in the request to make them visible.=20
=20
5.2 Glue Entries=20
=20
A glue entry is an entry that contains knowledge of its name only.=20
No other information is held with it. Such glue entries will be=20
distinguished through a special object class defined for that=20
purpose. Glue entries may be created during a replication session to=20
repair a constraint violation.=20
=20
5.3 Unique Identifiers=20
=20
Distinguished names can change, so are therefore unreliable as=20
identifiers. A Unique Identifier must therefore be assigned to each=20
entry as it is created. This identifier will be stored as an=20
operational attribute of the entry, named `entryUUID'. The entryUUID=20
attribute is single valued. A consistent algorithm for generating=20
such unique identifiers should be defined for use in the LDUP=20
standards documents that detail the LDUP information model and LDUP=20
protocols.=20
=20
5.4 Change Sequence Number=20
=20
Change Sequence Numbers (CSNs) are used to impose a total ordering=20
upon the causal sequence of updates applied to all the replicas of a=20
Replication Context. Every LDAP Update Operation is assigned at=20
least one CSN. A Modify operation MUST be assigned one CSN per=20
modification.=20
=20
5.4.1 CSN Composition=20
=20
A CSN is formed of four components. In order of significance they=20
are; the time, a change count, a Replica Identifier, and a=20
modification number. The CSN is composed thus to ensure the=20
uniqueness of every generated CSN. When CSNs are compared to=20
determine their ordering they are compared component by component:=20
first the time, then the change count, then the replica identifier,=20
and finally the modification number.=20
=20
The time component is a year-2000-safe (year 9999-safe, really)=20
representation of the real world time, with a granularity of one=20
second.=20
=20
Because many LDAP Update Operations, at a single replica, may be=20
applied to the same data in a single second, the change count=20
component of the CSN is provided to further order the changes. Each=20
replica maintains a count of LDAP update operations applied against=20
=20
LDAP Replication Architecture Model October 2003 =20
it. It is reset to zero at the start of each second, and is=20
monotonically increasing within that second, incremented for each=20
and every update operation. Should LDAP Update Operations occur at=20
different replicas, to the same data, within the same single second,=20
and happen to be assigned the same change count number, then the=20
Replica Identifier is used to further order the changes.=20
=20
The Replica Identifier is the value of the RDN attribute on the=20
Replica Subentry that represents the Replica. The Replica Identifier=20
could be assigned programmatically or administratively, in either=20
case short values are advised to minimize resource usage. The=20
IA5CaseIgnoreString syntax is used to compare and order Replica=20
Identifier values.=20
=20
The fourth and final CSN component, the modification number, is used=20
for ordering the modifications within an LDAP Modify operation.=20
=20
5.4.2 CSN Representation=20
=20
The preferred CSN representation is: yyyy mm dd hh:mi:ssz # 0xSSSS #=20
replica id # 0xssss=20
=20
The `z' in the time stipulates that the time is expressed in GMT=20
without any daylight savings time offsets permitted, and the 0xssss=20
represents the hexadecimal representation of an unsigned integer.=20
Implementations must support 16 bit change counts and should support=20
longer ones (32, 64, or 128 bits).=20
=20
An example CSN would be " 1998081018:44:31z#0x000F#1#0x0000 ". The=20
update assigned this CSN would have been applied at time=20
1998081018:44:31z happened to be the 16th operation which was=20
applied in that second, was made against the replica with identifier=20
`1', and was the first modification of the operation that caused the=20
change.=20
=20
5.4.3 CSN Generation=20
=20
Because Change Sequence Numbers are primarily based on timestamps,=20
clock differences between servers can cause unexpected change=20
ordering. The synchronization of server clocks is not required,=20
though it is preferable that clocks are accurate. If timestamps are=20
not accurate, and a server consistently produces timestamps that are=20
significantly older than those of other servers, its updates will=20
not have effect and the real world time ordering of updates will not=20
be maintained.=20
=20
However, an implementation may choose to require clock=20
synchronization. The Network Time Protocol [NTP] [SNTP] offers a=20
protocol means by which heterogeneous server hosts may be time=20
synchronized.=20
=20
The modifications that made up an LDAP Modify operation are=20
presented in a sequence. This must be preserved when the resultant=20
changes of this operation are replicated.=20
=20
LDAP Replication Architecture Model October 2003 =20
=20
5.5 Entries, Semantics and Relationships=20
=20
This section defines the organization of operational data for=20
directory replication in terms of the relative placement of the=20
entries that represent Replication Contexts, its Replicas, and their=20
associated Replication agreements. This section also describes the=20
purpose of these objects and abstractly describes their content.=20
=20
A Replication Context defines an area of DIT with independent=20
replication policies. There are many mechanisms available to=20
identify the set of Replication Contexts in a Directory, including=20
through special auxiliary classes or through operational attributes=20
in root DSE pointing to such entries. The LDUP information model=20
standards will detail an appropriate mechanism.=20
=20
Entries representing the set of Replicas associated with a=20
Replication Context are created immediately below (children) the=20
Replication Context entries. Replica entries are defined as=20
subentries and are intended to hold attributes that identify the=20
Replica's LDAP Access Point, its Replica Type, and if it is a=20
Fractional Replica, the attributes it does or does not hold. The=20
attribute value of the entry's Relative Distinguished Name (RDN) is=20
termed the Replica Identifier and is used as a component of each CSN=20
associated with the replica.=20
=20
Immediately subordinate to each Replica Subentry are the entries=20
representing the Replication Agreements between this replica and=20
another replica on some other server in the network. A Replication=20
Agreement entry is associated with exactly one remote replica. These=20
entries are defined to hold attributes identifying the remote=20
Replica associated with this agreement, the scheduling policy for=20
replication operations, including times when replication is to be=20
performed, when it is not to be performed, or the policies governing=20
event-driven replication initiation another Replica, the scheduling=20
policy for replication operations, including times when replication=20
is to be performed, when it is not to be performed, or the policies=20
governing event-driven replication initiation.=20
=20
5.6 Root DSE Attributes=20
=20
=20
The Root DSE attributes carry information that is essential to the=20
operation of the local DSA itself. Each node has its own=20
independent copy of such attributes and hence these are not to be=20
replicated to other nodes. In general this is true for all=20
operational attributes of type "DsaOperation".=20
=20
LDUP information model itself will define Root DSE attributes to=20
identify the set of Replication Contexts and replicas present in an=20
LDAP server.=20
=20
=20
=20
=0C LDAP Replication Architecture Model October 2003 =20
5.7 Replication Context Auxiliary Object Class and Entries=20
=20
Each Replication Context contains attributes that hold common=20
configuration and policy information for all replicas of the=20
Replication Context.=20
=20
A Replication Context Creation attribute records when and where the=20
Replication Context was created.=20
=20
The Replication Context is based at the entry given the auxiliary=20
class, and continues down the tree until leaf entries or another=20
Replication Context is encountered.=20
=20
5.8 Replica Object Class and Entries=20
=20
A replica type characterizes each Replica. This may be Primary,=20
Updateable, or Read-Only. The Replica entry will also include a=20
Fractional Entry Specification for a Fractional Replica.=20
There is a need to represent network addresses of servers holding=20
replicas involved in Replication Agreements. For this, the LDUP=20
information model will define an attribute with an appropriate=20
syntax to represent an LDAP server addresses with which to contact=20
replicas.=20
=20
An Update Vector describes the point to which the Replica has been=20
updated, in respect to all the other Replicas of the Replication=20
Context. The vector is used at the initiation of a replication=20
session to determine the sequence of updates that should be=20
transferred.=20
=20
Enabling LDAP to be a fully distributed service is not an objective=20
for the design of LDUP information model, though the information=20
stored in replica entries could facilitate certain distributed=20
operations.=20
=20
5.9 Lost and Found Entry=20
=20
When replicating operations between servers, conflicts may arise=20
that cause a parent entry to be removed causing its child entries to=20
become orphaned. In this case the Update Resolution Procedures will=20
make the Lost and Found Entry the child's new superior.=20
=20
Each Replica Entry names its Lost and Found Entry, which would=20
usually be an entry below the Replica Entry itself. This well-known=20
place allows administrators, and their tools, to find and repair=20
abandoned entries.=20
=20
5.10 Replication Agreement Object Class and Entries=20
=20
The Replication Agreement defines:=20
=20
1. The schedule for Replication Sessions initiation.=20
=20
LDAP Replication Architecture Model October 2003 =20
2. The server that initiates the Replication Session, either the=20
Consumer or the Supplier.=20
=20
3. The authentication credentials that will be presented between=20
servers.=20
=20
4. The network/transport security scheme that will be employed in=20
order to ensure data confidentiality and integrity.=20
=20
5. The replication protocols and relevant protocol parameters to be=20
used for Full and Incremental updates. An OID is used to identify=20
the update transfer protocol, thus allowing for future extensions or=20
bilaterally agreed upon alternatives.=20
=20
6. If the Replica is Fractional, the Fractional Entry Specification,=20
for the attributes to be included or excluded=20
=20
Permission to participate in replication sessions will be=20
controlled, at least in part, by the presence and content of replica=20
agreements.=20
=20
The Supplier must be subject to the access control policy enforced=20
by the Consumer. Since the access control policy information is=20
stored and replicated as directory content, the access control=20
imposed on the Supplier by the Consumer must be stored in the=20
Consumer's Replication Agreement.=20
=20
5.10.1 Replication Schedule=20
=20
There are two broad mechanisms for initiating replication sessions: =20
(1) scheduled event driven and (2) change event driven. The=20
mechanism used to schedule replication operations between two=20
servers is determined by the Schedule information that is part of=20
the Replication Agreement governing the Replicas on those two=20
servers. Because each Replication Agreement describes the policy=20
for one direction of the relationship, it is possible that events=20
propagate via scheduled events in one direction, and by change=20
events in the other.=20
=20
Change event driven replication sessions are, by their nature,=20
initiated by suppliers of change information. The server that the=20
change is made against schedules a replication session in response=20
to the change itself, so that notification of the change is passed=20
on to other Replicas.=20
=20
Either consumers or suppliers of change information can initiate=20
scheduled event driven replication sessions. The schedule defines a=20
calendar of time periods during which Replication Sessions should be=20
initiated.=20
=20
Schedule information may include both scheduled and change event=20
driven mechanisms. For instance, one such policy may be to begin=20
replication within 15 seconds of any change event, or every 30=20
minutes if no change events are received.=20
=20
LDAP Replication Architecture Model October 2003 =20
=20
6 Replication of Directory Administrative Policy Information=20
Administrative policy information governs the behavior of the=20
directory server. Schema, access control, and replication, all=20
involve administrative policy information. This policy information=20
(irrespective of how it is represented in the directory- as sub-
entries, attributes, or attribute values) should be consistently=20
known and enforced by servers managing any replica. Normally,=20
policy information present within a Replication Context is=20
replicated in the same manner as any other directory information. =20
But applicable policy information could reside outside a Replication=20
Context.=20
=20
Administrative policy information associated with directory=20
replication lies within the replication context to which it applies.=20
Hence, fortunately, any replica will also contain (include) all of=20
its applicable replication policy data. On the other hand, some=20
administrative boundaries (administrative areas) for other services=20
might extend to subordinate Replication Contexts. For instance, some=20
prescriptive access control policy applicable to entries in a=20
Replication Context could be represented by an entry that is an=20
ancestor of the root of the Replication Context. For access control=20
policies to be faithfully enforced by a server hosting a replica of=20
such a Replication Context, all applicable prescriptive policy=20
information must also be available within that server.=20
=20
But policy propagation is not an issue for replicated directories=20
only. These same issues are also relevant to distributed=20
directories. Many possible protocols could be conceived to ensure=20
that anywhere in the directory network, all applicable policies are=20
available so that these are enforced appropriately. To support=20
flexible and dependable deployments, DSAs supporting LDUP should=20
also implement IETF standard protocols for policy propagation. It=20
is expected that such an IETF standard protocol will be defined in a=20
way relevant for any LDAP directory deployment, be it distributed,=20
replicated or a combination of both. But defining such a protocol=20
is outside the scope of LDUP architecture.=20
=20
6.1 Schema Replication=20
=20
Given the strict ordering of replication events, schema=20
modifications will normally be replicated prior to entry operations=20
that use them, and subsequent to data deletions that eliminate=20
references to schema elements to be deleted. In a multi-master=20
environment with multiple suppliers, the order of arrival at a=20
consumer node of such changes cannot be guaranteed. The LDUP=20
standards for reconciliation should define procedures for handling=20
such scenarios.=20
=20
7 Change Representation and Update Resolution=20
=20
The state changes in a replica can be introduced via either LDAP=20
Update Operations or via Replication Updates. A CSN is included with=20
LDAP Replication Architecture Model October 2003 =20
all changes made to an entry, its attributes, and attribute values.=20
This state information must be recorded for the entry to enable a=20
total ordering of updates. =20
=20
When an update is performed, the CSN recorded is the CSN assigned at=20
the server where the change was first made. In other words, CSNs are=20
only assigned to changes performed by LDAP client updates and are=20
propagated with other change information. When Replication update=20
is performed at the target replica node the CSN associated with the=20
replicated change being processed is recorded.=20
=20
Each of the LDAP Update operations changes their target entry in=20
different ways, and records the CSN of the change differently. The=20
state information for the resultant state changes is recorded at=20
three levels: the entry level, attribute level, and attribute value=20
level.=20
=20
7.1 Entry Creation and Deletion=20
=20
When an entry is created the CSN of the change is added to the entry=20
as an operational attribute.=20
Deleted entries are marked as deleted through some means such as=20
addition of an object class denoting this sate. Deleted entries are=20
not visible to LDAP clients - they may not be read, they don't=20
appear in lists or search results, and they may not be changed once=20
deleted. Names of deleted entries are available for reuse by new=20
entries immediately after the deleted entry is so marked. It may be=20
desirable to allow deleted entries to be accessed and manipulated by=20
management and data recovery applications, but that is outside the=20
scope of this document.=20
=20
A CSN is recorded for both the RDN, and the Superior DN of the=20
entry.=20
=20
7.2 Attribute Creation and Deletion=20
=20
When all values of an attribute have been deleted, the attribute is=20
marked as deleted and the CSN of the deletion is recorded. The=20
deleted state and CSN are represented and stored by the server in an=20
implementation dependent way and hence may not be accessible by=20
search operations. This state information must be stored to enable=20
the Update Resolution Procedures to be performed. It may be=20
desirable to allow the deleted state and CSN information to be=20
accessed and manipulated by management and data recovery=20
applications, but that is outside the scope of this document.=20
=20
7.3 Attribute Value Changes=20
=20
The Modification CSN for each value is to be set by the server when=20
it accepts a modification request to the value, or when a new value=20
with a later Modification CSN is received via Replication. The=20
modified value and the Modification CSN changes are required to be=20
atomic, so that the value and its Modification CSN cannot be out of=20
LDAP Replication Architecture Model October 2003 =20
synch on a given server. The server stores the state information,=20
but it has no representation on the entry, and may not be the=20
subject of a search operation. It may be desirable to allow the=20
data recovery applications, but that is outside the scope of this=20
document.=20
=20
When the value of an attribute is deleted the state of its deletion=20
must be recorded, with the CSN of the modifying change. It must be=20
stored to enable the Update Resolution Procedures to be performed.=20
=20
7.4 Update Inconsistency=20
The server must reject LDAP client update operations with a CSN that=20
is older than the state information that would be replaced if the=20
operation were performed. This could occur in a replication topology=20
where the difference between the clocks of Master Replicas was too=20
large.=20
=20
8 LDUP Update Transfer Protocol Framework=20
=20
A Replication Session occurs between a Supplier server and Consumer=20
server over an LDAP connection. This section describes the process=20
by which a Replication Session is initiated, started and stopped.=20
=20
The session initiator, termed the Initiator, could be either the=20
Supplier or Consumer. The Initiator sends an LDAP extended operation=20
to the Responder identifying the replication agreement being acted=20
on. The Supplier then sends a sequence of updates to the Consumer.=20
=20
All transfers are in one direction only. A two-way exchange=20
requires two replication sessions - one session in each direction.=20
=20
8.1 Replication Session Initiation=20
=20
The Initiator starts the Replication Session by opening an LDAP=20
connection to its Responder. The Initiator binds using the=20
authentication credentials provided in the Replication Agreement. =20
The LDUP Update Transfer Protocol will define the LDAP extended=20
operation the Initiator should perform to initialize an LDUP=20
session. For the sake of convenience, this extended LDAP operation=20
for initializing a replication session is referred to as the _Start=20
Replication_ operation. Among other things, this operation will=20
identify the role each server will perform, and what type of=20
replication is to be performed. One server is to be the Consumer,=20
the other the Supplier, and the replication may be either Full or=20
Incremental. LDUP Update Transfer protocol could define additional=20
protocol primitives that allow the replicating nodes to reverse=20
their "supplier/consumer" role without having to reinitiate a new=20
replication cycle.=20
=20
8.1.1 Authentication=20
=20
LDAP Replication Architecture Model October 2003 =20
The initiation of a Replication Session is to be restricted to=20
privileged clients. The identity and the credentials for the client=20
eligible for initiating a replication session will be specified as=20
attributes within Replication Agreements.=20
=20
8.1.2 Consumer Initiated=20
=20
The Consumer binds to the Supplier using the authentication=20
credentials specified in the Replication Agreement. The Consumer=20
sends the Start Replication extended request to begin the=20
Replication Session. The Supplier returns a Start Replication=20
extended response containing a response code. The Consumer then=20
disconnects from the Supplier. If the Supplier has agreed to the=20
replication session initiation, it binds to the Consumer and behaves=20
just as if the Supplier initiated the replication.=20
=20
8.1.3 Supplier Initiated=20
=20
The Supplier binds to the Consumer using the authentication=20
credentials provided in the Replication Agreement. The Supplier=20
sends the _Start Replication_ extended request to begin the=20
Replication Session. The Consumer returns a _Start Replication_=20
extended response containing a response code, and possibly its=20
Update Vector. If the Consumer has agreed to the Replication Session=20
initiation, then the transfer protocol begins.=20
=20
8.2 Start Replication Session=20
=20
8.2.1 Start Replication Request=20
=20
The LDUP Update Transfer Protocol will define an LDAP Extended=20
Request, referred to in this document as _Start Replication Request,=20
which is sent from the Initiator to Responder. The parameters of the=20
_Start Replication Request_ would identify the Replication Agreement=20
associated with the session, the Update Transfer Protocol associated =20
with the replication session, and other state information necessary=20
to initiate a replication session between the two servers.=20
=20
8.2.2 Start Replication Response=20
=20
The LDUP Update Transfer Protocol will define an LDAP Extended=20
Response, _Start Replication Response_, sent in reply to a Start=20
Replication Request, from the Responder to the Initiator. The=20
parameters of the Start Replication Response include a response=20
code, and an optional Update Vector.=20
=20
8.3 Update Transfer=20
=20
Each Update Transfer Protocol is identified by an OID. An LDUP=20
conformant server implementation must support those update protocols=20
that are defined as mandatory in the Update Transfer Protocol=20
standard, and may support many others. A server will advertise its=20
protocols in the Root DSE multi- valued attribute=20
'supportedReplicationProtocols'.=20
LDAP Replication Architecture Model October 2003 =20
The Update Transfer Protocol would define the mechanisms for a=20
Consumer to receive a complete (full) update or incremental update=20
based on the current state of replication represented in the Update=20
Vector. A full update is necessary for initializing a consumer=20
replica upon establishment of replication agreements.=20
=20
8.4 End Replication Session=20
=20
The _End Replication Request_ initiated by the supplier terminates a=20
Replication Session. The purpose of this request and response is to=20
secure the state of the Update Vector associated with the two=20
replicas that participated in replication. This is necessary for=20
proper resumption of replication during subsequent LDUP sessions.=20
8.5 Major States of Replicas=20
The state of a Replica controls the activities of the DSA that holds=20
the replica as well as that of other replicas with which it has a=20
replication agreement. This state represents whether a DSA is=20
available for replication with another DSA or not.=20
The following states of replica are envisioned. =20
=20
1) A particular instance of a directory is NOT PARTICIPATING in=20
replication for a given area of replication and a given second=20
instance. In this state the instance need not record change=20
information for changes made in the context.=20
2) A particular instance of a directory is PARTICIPATING but NOT=20
ONLINE for a given area of replication and second instance. In=20
this case changes are recorded and will be sent when the instance=20
goes ONLINE.=20
3) A particular instance is PARTICIPATING and ONLINE for a given=20
area of replication and second instance. In this case changes are=20
being exchanged (subject to replication schedules, etc.). It is=20
possible for a given server to be ONLINE with some of the other=20
servers in the replica group and NOT ONLINE with others.=20
The fourth case (ONLINE and NOT PARTICIPATING) cannot occur.=20
=20
8.5.1 Replica State Changes=20
=20
Replica state changes are expected to trigger as a result of=20
administrative actions such as creation of a new replica instance,=20
removal of a replica, and creation of a replication-agreement=20
referring to a set of replicas. =20
=20
LDUP information model defines a Replica "subentry". The state of a=20
replica is represented within attributes in this Replica subentry.=20
Some of these attributes are of significance and specific to the=20
local DSA (attributes of type "dsaOperation") and hence are not=20
replicated to any other node. Others, however, may be useful to=20
LDAP Replication Architecture Model October 2003 =20
clients and other DSAs (for instance, whether the replica is=20
"ONLINE", it's update vector, or the result of the last replication=20
session for each replica agreement).=20
Each Replica would contain a Replica subentry, one representing=20
itself and one each for all other replicas (associated with the same=20
Replication Context) in the network. A DSA's actions w.r.t to=20
another replica (based on a binding replication agreement) would=20
depend on the replicas own state, as well as that of the state of=20
the latter. These states can be manually set to maintain control=20
over the DSA behavior. Hence, in addition to automatically=20
triggered state changes, it should be possible to manually set these=20
attributes as well.=20
=20
8.6 Integrity & Confidentiality=20
Data integrity (i.e., protection from unintended changes) and=20
confidentiality (i.e., protection from unintended disclosure to=20
eavesdroppers) SHOULD be provided by appropriate selection of=20
underlying transports, for instance TLS, or IPSEC. Replication MUST=20
be supported across TLS LDAP connections. Servers MAY be configured=20
to refuse replication connections over unprotected TCP connections.=20
=20
9 LDUP Update Protocols=20
=20
This Internet-Draft defines two transfer protocols for the supplier=20
to push changes to the consumer. Other protocols could be defined to=20
transfer changes, including those that pull changes from the=20
supplier to the consumer, but those are left for future work.=20
=20
9.1 Replication Updates and Update Primitives=20
=20
LDUP Update Protocol defines how Replication Updates are transferred=20
from the Supplier to the Consumer. Each Replication Update consists=20
of a set of Update Primitives that describe the state changes that=20
have been made to a single entry. Each Replication Update is=20
associated with a single entry identified by its UUID.=20
=20
The Update Transfer Protocol would define a set of Update Primitives=20
each of which codifies an assertion about the state change of an=20
entry that resulted from a directory update operation. The=20
primitives will include sufficient data to allow recreation of=20
corresponding state changes on the consumer's replica. An assertion-
based approach has been chosen in such a way that the Primitives are=20
idempotent, meaning that re-application of a Primitive to an Entry=20
will cause no change to the entry. This is desirable as it provides=20
some resilience against some kinds of system failures.=20
=20
Each Update Primitive contains a CSN that represents an ordering=20
among all such primitives generated anywhere in the network. The=20
consumer uses this ordering information to reconcile among those=20
primitives that lead to consistency violation.=20
=20
LDAP Replication Architecture Model October 2003 =20
9.2 Fractional Updates=20
When fully populating or incrementally bringing up to date a=20
Fractional Replica each of the Replication Updates must only contain=20
updates to the attributes in the Fractional Entry Specification.=20
=20
10 LDUP Full Update Transfer Protocol=20
=20
10.1 Full Update Transfer=20
=20
This Full Update Protocol provides a bulk transfer of the replica=20
contents for the initial population of new replicas, and the=20
refreshing of existing replicas. The LDUP Update Transfer protocol=20
standard will define the ways for this transfer is initiated. The =
Consumer must replace its entire replica contents with that sent from =
the Supplier. The Consumer MUST NOT service any requests for this Naming =
Context whilst the full update is being applied. The Consumer should =
return a referral to another replica, possibly the supplier. [REF]=20
=20
10.2 Replication Update Generation=20
=20
The entire state of a Replicated Area can be mapped onto a sequence=20
of Replication Updates, each of which contains a sequence of Update=20
Primitives that describe the entire state of a single entry.=20
The sequence of Replication Updates must be ordered such that no=20
entry is created before its parent.=20
=20
10.3 Replication Update Consumption=20
=20
A Consumer will receive the Replication Updates, extract the=20
sequence of Update Primitives, and must apply them to the DIB in the=20
order provided.=20
=20
10.4 Full Update, End Replication Session=20
=20
A Full Update should also result in the replication of all=20
appropriate LDUP meta-data (which are part of the Replication=20
Context), such as the sub-entry representing the Replica being=20
updated and the Update Vector associated with it. The Supplier could=20
be accepting updates whilst the update is in progress. Once the=20
Full Update has completed, an Incremental Update should be performed=20
to transfer these changes.=20
=20
10.5 Interrupted Transmission=20
=20
If the Replication Session terminates before the End Replication=20
Request is sent, then the Replica could be in an inconsistent state. =20
Until the replica is restored to a consistent state, the consumer=20
MUST NOT permit LDAP Clients to access the incomplete replica. The=20
Consumer could refer the Client to the Supplier Replica, or return=20
an error result code.=20
LDAP Replication Architecture Model October 2003 =20
=20
11 LDUP Incremental Update Transfer Protocol=20
=20
For efficiency, the Incremental Update Protocol transmits only those=20
changes that have been made to the Supplier replica that the=20
Consumer has not already received. In a replication topology with=20
transitive redundant replication agreements, changes may propagate=20
through the replica network via different routes.=20
=20
The Consumer must not support multiple concurrent replication=20
sessions with more than one Supplier for the same Replication=20
Context. A Supplier that attempts to initiate a Replication Session=20
with a Consumer already participating as a Consumer in another=20
Replication Session should receive an appropriate error.=20
=20
11.1 Update Vector=20
=20
The Supplier uses the Consumer's Update Vector to determine the=20
sequence of updates that should be sent to the Consumer.=20
=20
Each Replica entry includes an Update Vector to record the point to=20
which the replica has been updated. The vector is a set of CSN=20
values, one value for each known Master Replica. Each CSN value in=20
the vector corresponds to the most recent change known locally that=20
occurred in the Master Replica that this Update Vector value=20
represents.=20
=20
For example, consider two Master Replicas of a Replication Context,=20
one is assigned replica identifier `1', the other replica identifier=20
`2'. Each is responsible for maintaining its own update vector,=20
which will contain two CSNs, one for each replica. So, if both=20
replicas are identical they will have equivalent update vectors.=20
=20
Both Update Vectors =3D=20
=20
{1998081018:44:31z#0x000F#1#0x0000,=20
1998081018:51:20z#0x0001#2#0x0000}=20
=20
Subsequently, at 7pm, an update is applied to replica `2', so its=20
update vector is updated.=20
=20
Replica `1' Update Vector =3D=20
=20
{1998081018:44:31z#0x000F#1#0x0000,=20
1998081018:51:20z#0x0001#2#0x0000}=20
Replica `2' Update Vector =3D=20
=20
{1998081018:44:31z#0x000F#1#0x0000,=20
1998081019:00:00z#0x0000#2#0x0000}=20
=20
Since the Update Vector records the state to which the replica has=20
been updated, a supplier server, during Replication Session=20
initiation, can determine the sequence of updates that should be=20
LDAP Replication Architecture Model October 2003 =20
sent to the consumer. From the example above no updates need to be=20
sent from replica `1' to replica `2', but there is at least one=20
update pending from replica `2' to replica `1'.=20
Because the Update Vector embodies knowledge of updates made at all=20
known replicas it supports replication topologies that include=20
transitive and redundant connections between replicas. It ensures=20
that changes are not transferred to a consumer multiple times even=20
though redundant replication agreements may exist. It also ensures=20
that updates are passed across the replication network between=20
replicas that are not directly linked to each other.=20
=20
It may be the case that a CSN for a given replica is absent from the=20
update vector, for one of two reasons.=20
=20
1. CSNs for Read-Only replicas might be absent because no changes=20
will have ever been applied to that Replica, so there are no changes=20
to replicate.=20
=20
2. CSNs for newly created replicas may be absent because no changes=20
from that replica have yet been propagated.=20
=20
An Update Vector might also contain a CSN for a replica that no=20
longer exists. The replica may have been temporarily taken out of=20
service, or may have been removed from the replication topology=20
permanently. An implementation may choose to retire a CSN after some=20
configurable time period.=20
=20
11.2 Supplier Initiated, Incremental Update, Start Replication Session=20
=20
The Consumer Responder must return its Update Vector to the Supplier=20
Initiator. The Supplier uses this to determine the sequence of=20
Replication Updates that need to be sent to the Consumer.=20
11.3 Replication Update Generation=20
=20
The Supplier generates a sequence of Replication Updates to be sent=20
to the consumer. To enforce LDAP Constraint LDAP Constraints=20
Clauses.6, that the LDAP Modify must be applied atomically, each=20
Replication Update must contain the entire sequence of Update=20
Primitives for all the LDAP Operations for which the Replication=20
Update contains Update Primitives.=20
=20
Stated less formally, for each primitive the update contains, it=20
must also contain all the other primitives that came from the same=20
operation.=20
=20
A log-based implementation might take the approach of mapping LDAP=20
Operations onto an equivalent sequence of Update Primitives. A=20
systematic procedure for achieving this will be fully described in=20
the standard document defining Update Reconciliation Procedures.=20
The Consumer Update Vector is used to determine the sequence of LDAP=20
Operations in the operation log that the Consumer has not yet seen.=20
=20
LDAP Replication Architecture Model October 2003 =20
=20
11.4 Replication Update Consumption=20
=20
A Consumer will receive Replication Updates, extract the sequence of=20
Update Primitives, and must apply them to the DIB in the order=20
provided. LDAP Constraint LDAP Constraints Clauses.6 states that the=20
modifications within an LDAP Modify operation must be applied in the=20
sequence provided.=20
Those Update Primitives must be reconciled with the current replica=20
contents and any previously received updates. In short, updates are=20
compared to the state information associated with the item being=20
operated on. If the change has a more recent CSN, then it is applied=20
to the directory contents. If the change has an older CSN it is no=20
longer relevant and its change must not be effected.=20
=20
If the consumer acts as a supplier to other replicas then the=20
updates are retained for forwarding.=20
=20
11.5 Update Resolution Procedures=20
=20
The LDAP Update Operations must abide by the constraints imposed by=20
the LDAP Data Model and LDAP Operational Behavior, Appendix A. An=20
operation that would violate at least one of these constraints is=20
rejected with an error result code.=20
=20
The loose consistency model of this replication architecture and its=20
support for multiple Master Replicas of a Replication Context means=20
that LDAP Update Operations could be valid at one replica, but not=20
in another. At the time of acceptance, the accepting replica may not=20
have received other updates that would cause a constraint to be=20
violated, and the operation to be rejected.=20
=20
Replication Updates must never be rejected because of a violation of=20
an LDAP Constraint. If the result of applying the Replication Update=20
causes a constraint violation to occur, then some remedial action=20
must be taken to satisfy the constraint. These Update Resolution=20
Procedures are introduced here, and fully described in These Update=20
Resolution Procedures are introduced here will be fully defined=20
within LDUP Update Resolution Procedures.=20
=20
11.5.1 URP: Distinguished Names=20
=20
LDAP Constraints 20.1.1 and 20.1.10 ensure that each entry in the=20
replicated area has a unique DN. A Replication Update could violate=20
this constraint producing two entries, with different unique=20
identifiers, but with the same DN. The resolution procedure is to=20
rename the both entries so that its RDN includes its own unique=20
identifier. This ensures that the DN of both the entries shall be=20
unique.=20
=20
11.5.2 URP: Orphaned Entries=20
=20
=20
LDAP Replication Architecture Model October 2003 =20
LDAP Constraints 20.1.11 ensures that every entry must have a parent=20
entry. A Replication Update could violate this constraint producing=20
an entry with (as yet) no parent entry. The resolution procedure is=20
to create a Glue Entry to take the place of the absent parent. The=20
Glue Entry's superior will be the Lost and Found Entry. This well-
known place allows administrators and their tools (including=20
subsequent Replication Sessions) to find and repair orphaned=20
entries.=20
=20
11.5.3 URP: Schema - Single Valued Attributes=20
=20
LDAP Constraint 20.1.7 enforces the single-valued attribute schema=20
restriction. A Replication Update could violate this constraint=20
creating a multi-value single-valued attribute. The resolution=20
procedure is to replace the earlier value of a single-valued=20
attribute with the newer value. In this way the most recently added=20
value will be retained, and the older one discarded.=20
=20
11.5.4 URP: Schema - Required Attributes=20
=20
LDAP Constraint 20.1.7 enforces the schema objectclass definitions=20
on an entry. A Replication Update could violate this constraint=20
creating an entry that does not have attribute values for required=20
attributes. The resolution procedure is to ignore the schema=20
violation and mark the entry as a glue entry for administrative=20
repair or correction in a subsequent replication session.=20
=20
11.5.5 URP: Schema - Extra Attributes=20
=20
LDAP Constraint 20.1.3 and 20.1.7 enforces the schema objectclass=20
definitions on an entry. A Replication Update could violate this=20
constraint creating an entry that has attribute values not allowed=20
by the objectclass values of the entry. The resolution procedure is=20
to ignore the schema violation and mark the entry as a glue entry=20
for administrative repair or correction in a subsequent replication=20
session.=20
=20
11.5.6 URP: Duplicate Attribute Values=20
=20
LDAP Constraint 20.1.5 ensures that the values of an attribute=20
constitute a set of unique values. A Replication Update could=20
violate this constraint. The resolution procedure is to enforce this=20
constraint, recording the most recently assigned CSN with the value.=20
=20
11.5.7 URP: Ancestry Graph Cycle=20
=20
LDAP Constraint 20.4.2.1 prevents against a cycle in the DIT. A=20
Replication Update could violate this constraint causing an entry to=20
become it's own parent, or for it to appear even higher in it's=20
ancestry graph. The resolution procedure is to break the cycle by=20
=20
=0C LDAP Replication Architecture Model October 2003 =
=20
changing the parent of the entry closest to be the lost and found=20
entry.=20
=20
11.6 Incremental Update, End Replication Session=20
=20
If the Supplier sent none of its own updates to the Consumer, then=20
the Supplier's CSN within the Supplier's update vector should be=20
updated with the earliest possible CSN that it could generate, to=20
record the time of the last successful replication session. The=20
Consumer will have received the Supplier's Update Vector in the=20
replica sub- entry it holds for the Supplier replica.=20
=20
The Consumer's resultant Update Vector CSN values will be at least=20
as great as the Supplier's Update Vector.=20
=20
The Supplier may request that the Consumer return its resultant=20
Update Vector so that the Supplier can update its replica sub-entry=20
for the Consumer Replica. The Supplier requests this by setting a=20
flag in the End Replication Request. The default flag value is TRUE=20
meaning the Consumer Update Vector must be returned.=20
=20
11.7 Interrupted Transmission=20
=20
If the Replication Session terminates before the End Replication=20
Request is sent then the Consumer's Update Vector may or may not be=20
updated to reflect the updates received. The Start Replication=20
request includes a Replication Update Ordering flag that states=20
whether the updates were sent in CSN order per replica.=20
=20
Since updates are sent in CSN order per replica then it is possible=20
to update the Consumer Update Vector to reflect that some portion of=20
the updates to have been sent have been received and successfully=20
applied. The next Incremental Replication Session will pick up where=20
the failed session left off.=20
=20
12 Purging State Information=20
=20
The state information stored with each entry need not be stored=20
indefinitely. A server implementation may choose to periodically, or=20
continuously, remove state information that is no longer required.=20
The mechanism is implementation- dependent, but to ensure=20
interoperability between implementations, the state information must=20
not be purged until all known replicas have received and=20
acknowledged the change associated with a CSN. This is determined=20
from the Purge Vector [Purge Vector].=20
=20
All the CSNs stored that are lower than the Purge Vector may be=20
purged, because no changes with older CSNs can be replicated to this=20
replica.=20
=20
12.1 Purge Vector=20
=20
The Purge Vector is an Update Vector constructed from the Update=20
Vectors of all known replicas. Below the root of a Replication=20
=20
LDAP Replication Architecture Model October 2003 =20
Context is one sub-entry for each known replica of that Replication=20
Context. Each of those entries contains the last known update vector=20
for that replica. The lowest CSN for each replica are taken from=20
these update vectors to form the Purge Vector. The Purge Vector is=20
used to determine when state information and updates need no longer=20
be stored.=20
=20
12.2 Purging Deleted Entries, Attributes, and Attribute Values=20
=20
The following conditions must hold before an item can be deleted=20
from the Directory Information Base.=20
=20
1) The LDAP delete operation has been propagated to all replication=20
agreement partners.=20
=20
2) All the CSNs in other replica Update Vectors representing changes=20
to be sent to the server holding the deleted entry have advanced=20
beyond the CSN on the deletion (similarly for deleted attributes and=20
attribute values).=20
=20
3) The CSN generator of the other Replicas must have advanced beyond=20
the deletion CSN of the deleted entry. Otherwise, it is possible for=20
one of those Replicas to generate operations with CSNs earlier than=20
the deleted entry.=20
=20
=20
13 Replication Configuration and Management=20
=20
Replication management entries, such as replica or replication=20
agreement entries can be altered on any Master Replica. These=20
entries are implicitly included in the directory entries governed by=20
any agreement associated with this Replication Context. As a=20
result, all servers with a replica of a Replication Context will=20
have access to information about all other replicas and associated=20
agreements.=20
=20
The deployment and maintenance of a replicated directory network=20
involves the creation and management of all the replicas of a=20
Replication Context and replication agreements among these replicas. =20
This section outlines, through an example, the administrative=20
actions necessary to create a new replica and establish replication=20
agreements. Typically, administrative tools will guide the=20
administrator and facilitate these actions. The objective of this=20
example is to illustrate the architectural relationship among=20
various replication related operational information.=20
=20
A copy of an agreement should exist on both the supplier and=20
consumer side for the replication update transfer protocol to be=20
able to start. For this purpose, the root of the Replication=20
Context, replica objects and the replication agreement objects are=20
created first on one of the servers. A copy of these objects is then=20
manually created on the second server associated with the agreement.=20
=20
=20
LDAP Replication Architecture Model October 2003 =20
The scenario below starts with a server (named DSA1) that holds a=20
Master Replica of a Replication Context, RC1. Procedures to=20
establish a Master Replica of the Replication Context on a second=20
server (DSA2) are outlined.=20
=20
Note that when entries are created on two or more separate servers=20
in the operations described below, they need to be created with the=20
same entry UUIDs so that they don't collide with one another when=20
replication of their information actually occurs. This may be done=20
through some administrative control that allows the entry UUID to be=20
set by the create entry operation.=20
=20
1. On DSA1: Add RC1's context prefix to the value of Root DSE=20
attribute 'replicaRoot'.=20
=20
2. On DSA1: Alter the 'ObjectClass' attribute of the root entry of=20
RC1 to include the "replicationContext" auxiliary class.=20
=20
3. On DSA1: Create a replica object, RC1-R1, (as a child of the root=20
of RC1) to represent the replica on DSA1. The attributes include=20
replica type (updateable, read-only etc.) and DSA1 access point=20
information.=20
=20
4. On DSA2: Add RC1's context prefix to the value of Root DSE=20
attribute 'replicaRoot'.=20
=20
5. On DSA2: Create a copy of the root entry of RC1 as a copy of the=20
one in DSA1 (including the replicationContext auxiliary class)=20
=20
6. On DSA2: Create a copy of the replica object RC1-R1=20
=20
7. On DSA2: Create a second replica object, RC1-R2 (as a sibling of=20
RC1-R1) to represent the replica on DSA2.=20
=20
8. On DSA1: Create a copy of the replica object RC1-R2=20
=20
9. On DSA1: Create a replication agreement object, RC1-R1-R2 to=20
represent update transfer from RC1-R1 to RC1-R2. This object is a=20
child of RC1-R1.=20
=20
10. On DSA2: Create a copy of the replication agreement, RC1- R1-R2.=20
11. On DSA2: Create a replication agreement, RC1-R2-R1, to represent=20
update transfer from RC1-R2 to RC1-R1. This object is a child of=20
RC1-R2.=20
=20
12. ON-DSA1: Create a copy of the replication agreement, RC1- R2-R1.=20
=20
After these actions update transfer to satisfy either of the two=20
agreements can commence.=20
=20
If data already existed in one of the replicas, the update transfer=20
protocol should perform a complete update of the data associated=20
with the agreement before normal replication begins.=20
=20
LDAP Replication Architecture Model October 2003 =20
13. Time=20
=20
The server assigns a CSN for every LDAP update operation it=20
receives. Since the CSN is principally based on time, the CSN is=20
susceptible to the Replica clocks drifting in relation to each other=20
(either forwards or backwards).=20
=20
The server must never assign a CSN older than or equal to the last=20
CSN it assigned.=20
=20
The server must reject update operations, from any source, which=20
would result in setting a CSN on an entry or a value that is earlier=20
than possible. The error code serverClocksOutOfSync (72) should be=20
returned if it is clear that the update is not simply an old one=20
that should be silently ignored. In particular, additions or=20
modifications with CSNs prior to those on the servers Purge Vector=20
should be rejected.=20
=20
14 Availability Considerations=20
=20
LDAP directories hold crucial security information affecting=20
security information, including identities, their credentials and=20
associated authorizations. As a result, availability of directory=20
service is critical for the proper operation of almost all the=20
applications accessible over the network. Replicated directory can=20
be implemented to address the availability needs, by employing=20
explicit client failover mechanisms or implicitly through network=20
load balance devices.=20
=20
Since availability is a major objective of implementing replicated=20
directory service, it is important for LDUP implementations to=20
support various deployment procedures such as adding new nodes,=20
deleting nodes or software upgrade of the replicated network nodes,=20
without any service-wide downtime.=20
=20
15 Security Considerations=20
=20
The preceding architecture discussion covers the server=20
authentication, session confidentiality, and session integrity in=20
sections Authentication and Integrity & Confidentiality.=20
=20
The IETF draft "Authentication Methods" for LDAP, provides a=20
detailed LDAP security discussion. Its introductory passage is=20
paraphrased below. [AUTH]=20
=20
A Replication Session can be protected with the following security=20
mechanisms.=20
=20
1) Authentication by means of the SASL mechanism set, possibly=20
backed by the TLS credentials exchange mechanism,=20
=20
2) Authorization by means of access control based on the Initiators=20
authenticated identity,=20
=20
=20
LDAP Replication Architecture Model October 2003 =20
3) Data integrity protection by means of the TLS protocol or data-
integrity SASL mechanisms,=20
4) Protection against snooping by means of the TLS protocol or data-
encrypting SASL mechanisms,=20
=20
The configuration entries that represent Replication Agreements may=20
contain authentication information. This information must never be=20
replicated between replicas.=20
=20
Updates to a multi-mastered entry may collide causing the Update=20
Resolution Procedures [Update Resolution Procedures] to reject or=20
reverse one of the changes to the entry. The URP algorithms resolve=20
conflicts by using the total ordering of updates imposed by the=20
assignment of CSNs for every operation. As a consequence updates=20
originating from system administrators have no priority over updates=20
originating from regular system users.=20
=20
15.1 Audit Capabilities=20
=20
LDAP servers should enhance their audit capabilities to support=20
collection and management of audit logs about replication=20
activities. Much of replication management operations is sensitive=20
in nature and hence should be auditable. Also important is the=20
auditability of replication sessions by maintaining history log of=20
replication sessions, capturing the servers a node had engaged in=20
replication with in either direction.=20
=20
16 Acknowledgements=20
=20
This document is a product of the LDUP Working Group of the IETF.=20
The contribution of its members is greatly appreciated. =20
17 References=20
=20
[AUTH] _ M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,=20
"Authentication Methods for LDAP", Internet Draft, draft-ietf-
ldapext-authmeth-02.txt, June 1998.=20
[BCP-11] _ R. Hovey, S. Bradner, "The Organizations Involved in the=20
IETF Standards Process", BCP 11, RFC 2028, October 1996.=20
=20
[LDAPv3] _ M. Wahl, S. Kille, T. Howes, "Lightweight Directory=20
Access Protocol (v3)", RFC 2251, December1997.=20
=20
[LDUP Requirements] - R. Weiser, E. Stokes 'LDAP Replication=20
Requirements', Internet Draft, draft-weiser- replica-req-02.txt,=20
October, 1999.=20
=20
[NTP] _ D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305,=20
March, 1992.=20
=20
[RFC2119] _ S. Bradner, "Key words for use in RFCs to Indicate=20
Requirement Levels", RFC 2119.=20
=20
=20
LDAP Replication Architecture Model October 2003 =20
[RFC2252] _ M. Wahl, A. Coulbeck, T. Howes, S. Kille, _Lightweight=20
Directory Access Protocol (v3): Attribute Syntax Definitions_, RFC=20
2252, December 1997.=20
=20
[SNTP] _ D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4=20
for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October=20
1996.=20
=20
[TLS] _ J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight=20
Directory Access Protocol (v3): Extension for Transport Layer=20
Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt,=20
June 1998.=20
=20
[X501] _ ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594-
2:1993, Information Technology _ Open Systems Interconnection _ The=20
Directory: Models=20
=20
[X680] _ ITU-T Recommendation X.680 (1994) | ISO/IEC 8824- 1:1995,=20
Information technology _ Abstract Syntax Notation One (ASN.1):=20
Specification of Basic Notation=20
=20
[X525] _ ITU-T Recommendation X.525 (1997) | ISO/IEC 9594- 9:1997,=20
Information Technology _ Open Systems Interconnection _ The=20
Directory: Replication=20
=20
=20
LDAP Replication Architecture Model October 2003 =20
Intellectual Property Notice=20
=20
The IETF takes no position regarding the validity or scope of any=20
intellectual property or other rights that might be claimed to=20
pertain to the implementation or use of the technology described in=20
this document or the extent to which any license under such rights=20
might or might not be available; neither does it represent that it=20
has made any effort to identify any such rights. Information on the=20
IETF's procedures with respect to rights in standards-track and=20
standards-related documentation can be found in BCP-11. Copies of=20
claims of rights made available for publication and any assurances=20
of licenses to be made available, or the result of an attempt made=20
to obtain a general license or permission for the use of such=20
proprietary rights by implementers or users of this specification=20
can be obtained from the IETF Secretariat.=20
=20
The IETF invites any interested party to bring to its attention any=20
copyrights, patents or patent applications, or other proprietary=20
rights, which may cover technology that may be required to practice=20
this standard. Please address the information to the IETF Executive=20
Director.=20
=20
Copyright Notice=20
=20
Copyright (C) The Internet Society (1998-2003). All Rights Reserved.=20
=20
This document and translations of it may be copied and furnished to=20
others, and derivative works that comment on or otherwise explain it=20
or assist in its implementation may be prepared, copied, published and =
distributed, in whole or in part, without restriction of any kind, =
provided that the above copyright notice and this paragraph are included =
on all such copies and derivative works. However, this document itself =
may not be modified in any way, such as by removing the copyright notice =
or references to the Internet Society or other Internet organizations, =
except as needed for the purpose of developing Internet standards in =
which case the procedures for copyrights defined in the Internet =
Standards process must be followed, or as required to translate it into =
languages other than English.=20
=20
The limited permissions granted above are perpetual and will not be=20
revoked by the Internet Society or its successors or assigns.=20
=20
This document and the information contained herein is provided on an=20
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20
=20
LDAP Replication Architecture Model October 2003 =20
18 Authors' Address=20
=20
Uppili Srinivasan Oracle, Inc., Redwood Shores, CA=20
E-mail: [email protected]=20
=20
John Merrells Sleepy Cat Software, Inc., Lincoln, MA=20
E-mail: [email protected]=20
=20
Edwards E. Reed Novell, Inc., Provo, UT=20
E-mail: [email protected]=20
=20
LDUP Working Group Mailing List: [email protected]=20
=20
19 Appendix A _ LDAP Constraints=20
=20
19.1 LDAP Constraints Clauses=20
=20
This is an enumeration of the Data Model and Operation Behaviour=20
constraint clauses defined in RFC 2251. [LDAPv3]=20
=20
1) Data Model - Entries have names: one or more attribute values=20
from the entry form its relative distinguished name (RDN), which=20
MUST be unique among all its siblings. (p5)=20
=20
2) Data Model - Attributes of Entries - Each entry MUST have an=20
objectClass attribute. (p6)=20
=20
3) Data Model - Attributes of Entries - Servers MUST NOT permit=20
clients to add attributes to an entry unless those attributes are=20
permitted by the object class definitions. (p6)=20
=20
4) Relationship to X.500 - This document defines LDAP in terms of=20
X.500 as an X.500 access mechanism. An LDAP server MUST act in=20
accordance with the X.500 (1993) series of ITU recommendations when=20
providing the service. However, it is not required that an LDAP=20
server make use of any X.500 protocols in providing this service,=20
e.g. LDAP can be mapped onto any other directory system so long as=20
the X.500 data and service model as used in LDAP is not violated in=20
the LDAP interface. (p8)=20
=20
5) Elements of Protocol - Common Elements - Attribute - Each=20
attribute value is distinct in the set (no duplicates). (p14)=20
=20
6) Elements of Protocol - Modify Operation - The entire list of=20
entry modifications MUST be performed in the order they are listed,=20
as a single atomic operation. (p33)=20
=20
7) Elements of Protocol - Modify Operation - While individual=20
modifications may violate the directory schema, the resulting entry=20
after the entire list of modifications is performed MUST conform to=20
the requirements of the directory schema. (p33)=20
=20
=20
LDAP Replication Architecture Model October 2003 =20
8) Elements of Protocol - Modify Operation - The Modify Operation=20
cannot be used to remove from an entry any of its distinguished=20
values, those values which form the entry's relative distinguished=20
name. (p34)=20
=20
9) Elements of Protocol - Add Operation - Clients MUST include=20
distinguished values (those forming the entry's own RDN) in this=20
list, the objectClass attribute, and values of any mandatory=20
attributes of the listed object classes. (p35)=20
10) Elements of Protocol - Add Operation - The entry named in the=20
entry field of the AddRequest MUST NOT exist for the AddRequest to=20
succeed. (p35)=20
=20
11) Elements of Protocol - Add Operation - The parent of the entry=20
to be added MUST exist. (p35)=20
=20
12) Elements of Protocol - Delete Operation - ... only leaf entries=20
(those with no subordinate entries) can be deleted with this=20
operation. (p35)=20
=20
13) Elements of Protocol - Modify DN Operation - If there was=20
already an entry with that name [the new DN], the operation would=20
fail. (p36)=20
=20
14) Elements of Protocol - Modify DN Operation - The server may not=20
perform the operation and return an error code if the setting of the=20
deleteoldrdn parameter would cause a schema inconsistency in the=20
entry. (p36)=20
=20
19.2 LDAP Data Model Constraints=20
=20
The LDAP Data Model Constraint clauses as written in RFC 2251=20
[LDAPv3] may be summarised as follows.=20
=20
a) The parent of an entry must exist. (LDAP Constraint 11 & 12.)=20
=20
b) The RDN of an entry is unique among all its siblings. (LDAP=20
Constraint 1.)=20
=20
c) The components of the RDN must appear as attribute values of =20
the entry. (LDAP Constraint 8 & 9.)=20
=20
d) An entry must have an objectclass attribute. (LDAP Constraint 2 & =
=20
9.)=20
=20
e) An entry must conform to the schema constraints. (LDAP=20
Constraint 3 & 7.)=20
=20
f) Duplicate attribute values are not permitted.(LDAP Constraint 5.)=20
=20
=20
=20
=20
LDAP Replication Architecture Model October 2003 =20
19.3 LDAP Operation Behaviour Constraints=20
=20
The LDAP Operation Behaviour Constraint clauses as written in RFC=20
2251 [LDAPv3] may be summarized as follows.=20
=20
A) The Add Operation will fail if an entry with the target DN=20
already exists. (LDAP Constraint 10.)=20
=20
B) The Add Operation will fail if the entry violates data=20
constraints:=20
=20
a - The parent of the entry does not exist. (LDAP Constraint 11.)=20
=20
b - The entry already exists. (LDAP Constraint 10.)=20
=20
c - The entry RDN components do not appear as attribute values on=20
the entry. (LDAP Constraint 9.)=20
=20
d - The entry does not have an objectclass attribute. (LDAP=20
Constraint 9.)=20
=20
e - The entry does not conform to the schema constraints. (LDAP
Constraint 9.)=20
=20
f - The entry has no duplicated attribute values. (LDAP=20
Constraint 5.)=20
=20
C) The modifications of a Modify Operation are applied in the order=20
presented. (LDAP Constraint 6.)=20
=20
D) The full set of modifications of a Modify Operation are applied=20
as one atomic unit. (LDAP Constraint 6.)=20
=20
E) A Modify Operation will fail if it results in an entry that=20
violates data constraints:=20
=20
a - If it attempts to remove distinguished attribute values.=20
(LDAP Constraint 8.)=20
=20
b - If it removes the objectclass attribute. (LDAP Constraint=20
2.)=20
=20
c - If it violates the schema constraints. (LDAP Constraint 7.)=20
=20
d - If it creates duplicate attribute values. (LDAP Constraint 5.)=20
=20
F) The Delete Operation will fail if it would result in a DIT that=20
violates data constraints:=20
=20
a - The deleted entry must not have any children.=20
(LDAP Constraint 12.)=20
=20
=20
LDAP Replication Architecture Model October 2003 =20
G) The ModDN Operation will fail if it would result in a DIT or=20
entry that violates data constraints:=20
=20
a - The new Superior entry must exist. (Derived LDAP Data Model=20
Constraint A)=20
=20
b - An entry with the new DN must not already exist. (LDAP=20
Constraint 13.)=20
=20
c - The new RDN components do not appear as attribute values on=20
the entry. (LDAP Constraint 1.)=20
=20
d - If it removes the objectclass attribute. (LDAP Constraint=20
2.)=20
=20
e - It is permitted for the operation to result in an entry that=20
violates the schema constraints. (LDAP Constraint 14.)=20
=20
19.4 New LDAP Constraints=20
=20
The introduction of support for multi-mastered entries, by the=20
replication scheme presented in this document, necessitates the=20
imposition of new constraints upon the Data Model and LDAP Operation=20
Behaviour.=20
=20
19.4.1 New LDAP Data Model Constraints=20
=20
1) Each entry shall have a unique identifier generated by the UUID=20
algorithm available through the `entryUUID' operational attribute.=20
The entryUUID attribute is single valued.=20
=20
19.4.2 New LDAP Operation Behaviour Constraints=20
1) The LDAP Data Model Constraints do not prevent cycles in the ancestry =
graph. Existing constraints Data Model Constraint _ New LDAP Data Model =
Constraints _ (a) and Operation Constraint _ New LDAP Operation =
Behaviour Constraints _ (B) would prevent this in the single master =
case, but not in the presence of multiple masters.=20
2) The LDAP Data Model Constraints state that only the LDAP Modify =
Operation is atomic. All other LDAP operations, namely, ADD, DELETE and =
MODDN are also considered to be atomically applied to the DIB.=20
=20
=0C
------=_NextPart_000_002E_01C39670.A6BE51A0--