INTERNET-DRAFT

draft-ietf-ldup-model-00.txt

John Merrells
Netscape Communications Corp.
Ed Reed
Novell, Inc.
Uppili Srinivasan
Oracle, Inc.
April 22, 1998

LDAP Replication Architecture

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This draft, file name draft-ietf-ldup-model-00.txt, is intended to be
become a Proposed Standard RFC, to be published by the IETF Working
Group LDUP. Distribution of this document is unlimited. Comments
should be sent to the LDUP Replication mailing list <ldup@imc.org> or
to the authors.

This Internet-Draft expires on 22 September 1999.

Merrells, Reed, Srinivasan [Page 1]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

1. Abstract

This architectural document outlines a suite of schema and protocol
extensions to LDAPv3 that enables the robust, reliable, server-to-
server exchange of directory content and changes.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. The
sections below reiterate these definitions and include some additional
ones.

Merrells, Reed, Srinivasan [Page 2]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

2. Table of Contents

1. Abstract 2
2. Table of Contents 3
3. Introduction 5
3.1 Scope 5
3.2 Document Objectives 6
3.3 Document Non-Objectives 6
3.4 Terms and Definitions 7
4. Overview 8
4.1 Directory Model 8
4.2 Information Model 9
4.3 Policy Information 9
4.4 Update Transfer Protocol 9
4.5 Conflict Detection and Resolution 10
4.6 Replication Configuration and Management 10
4.7 Update Vector 10
4.8 Time 10
5. Directory Model 11
5.1 Replica Type 11
5.1.1 Primary Replica 11
5.1.2 Updatable Replica 11
5.1.3 Read-Only Replica 11
5.1.4 Sparse Replica 11
5.1.5 Fractional Replicas 12
5.1.6 Partial Replica 12
5.2 Sub-Entries 12
5.3 Unique Identifiers 12
5.4 LDAP Change Sequence Numbers 12
5.5 State Storage and Representation 13
5.5.1 Entry Change State Storage and Representation 14
5.5.2 Attribute Change State Storage and Representation 14
5.5.3 Attribute Value Change State Storage and Representation14
5.6 LDAP Update Operations 15
5.7 Purging State Information 15
5.7.1 Purging Deleted Entries, Attributes, and Attribute Values15
6. Information Model 16
6.1 Entries, Semantics & Relationships 16
6.1.1 Root DSE Attributes 16
6.1.2 Naming Context Auxiliary Object Class and Entries 16
6.1.3 Replica Object Class and Entries 17
6.1.4 Lost and Found Entry 17
6.1.5 Replication Agreement Object Class and Entries 17
6.1.5.1 Replication Schedule 18
6.1.6 Update Vector 19
7. Policy Information 20

Merrells, Reed, Srinivasan [Page 3]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

7.1 Access Control 20
7.2 Schema Knowledge 21
8. Update Transfer Protocol 21
8.1 Replication Session Initiation 22
8.1.1 Authentication 22
8.1.2 Consumer Initiated 22
8.1.3 Supplier Initiated 22
8.2 Start Replication Session 23
8.2.1 Consumer Initiated, Start Replication Session 23
8.2.2 Supplier Initiated, Full Update, Start Replication Session23
8.2.3 Supplier Initiated, Incremental Update, Start Replication
Session 23
8.2.4 Start Replication Request 23
8.2.5 Start Replication Response 24
8.3 Update Transfer 25
8.3.1 Full Update Transfer 25
8.3.2 Incremental Update Transfer 26
8.3.2.1 Conflict Detection and Resolution 26
8.3.2.2 Update Conflict Detection and Resolution 27
8.3.2.3 Naming Conflict Detection and Resolution 27
8.3.2.4 Orphaned Entry Detection and Resolution 27
8.4 End Replication Session 28
8.4.1 Full Update, End Replication Session 28
8.4.2 Incremental Update, End Replication Session 28
8.4.3 End Replication Request 28
8.4.4 End Replication Response 29
8.5 Integrity & Confidentiality 30
9. Replication Configuration and Management 30
10. Time 32
11. Security Considerations 32
12. Acknowledgements 33
13. References 33
14. Intellectual Property Notice 34
15. Copyright Notice 35
16. Authors' Address 35
17. Appendix A - Open Issues 36
17.1 Configuration Entries 36
17.2 Management 36
17.3 Purging36
17.4 Update Transfer: Errors, Recovery, Diagnostics and Repair 36

Merrells, Reed, Srinivasan [Page 4]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

3. Introduction

3.1 Scope

This architectural document provides an outline of an LDAP based
replication scheme. Further detailed design documents will draw
guidance from here.

The design proceeds from prior work in the industry, including
concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory
Information Shadowing Protocol (DISP) [X525], experience with widely
deployed distributed directories in network operating systems,
electronic mail address books, and other database technologies. The
emphasis of the design is on:

1. Simplicity of operation.

2. Flexibility of configuration.

3. Manageability of replica operations among mixed heterogeneous
vendor LDAP servers under common administration.

4. Security of content and configuration information when LDAP servers
from more than one administrative authority are interconnected.

A range of deployment scenarios are supported, including multi-master
and single-master topologies. Replication networks may include
transitive and redundant relationships between LDAP servers.

The controlling framework used to define the relationships, types, and
state of replicas of the directory content is defined. In this way the
directory content can itself be used to monitor and control the
replication network. The directory schema is extended to define object
classes, auxiliary classes, and attributes that describe areas of the
namespace which are replicated, LDAP servers which hold replicas of
various types for the various partitions of the namespace, LDAP Access
Points (network addresses) where such LDAP servers may be contacted,
which namespaces are held on given LDAP servers, and the progress of
replication operations. Among other things, this knowledge of where
directory content is located will provide the basis for dynamic
generation of LDAP referrals. [REF]

An update transfer protocol, which actually brings a replica up to
date with respect to changes in directory content at another replica,
is defined using LDAPv3 protocol extensions. The representation of
directory content and changes will be defined by the LDAP Replication
Update Transfer Protocol sub-team. Incremental and full update

Merrells, Reed, Srinivasan [Page 5]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

transfer mechanisms are described. Replication protocols are required
to include initial population, change updates, and removal of
directory content.

Security information, including access control policy will be treated
as directory content by the replication protocols. Confidentiality
and integrity of replication information is required to be provided by
lower-level transport/session protocols such as IPSEC and/or TLS.

3.2 Document Objectives

The following list enumerates the objectives of this document.

a) To define the architectural foundations for LDAP Replication, so
that further detailed design documents may be written. For
instance, the Information Model, Update Transfer Protocol, and
Conflict Detection and Resolution documents.

b) Provide an architectural solution for each clause of the
requirements document [LDUP Requirements].

c) To preserve the atomicity of LDAP operations. Updates to an entry,
from multiple sources, will be combined such that the resultant
entry is equivalent to a serial execution of the operations.

d) To avoid tying the LDUP working group to the schedule of any other
working group.

e) Not to infringe known registered intellectual property.

3.3 Document Non-Objectives

This document does not address the following issues, as they are
considered beyond the scope of the Working Group.

a) How LDAP becomes a distributed directory. There are many issues
beyond replication that should be considered. Such as, support for
external references, algorithms for computing referrals from the
distributed directory knowledge, etc.

b) Specifying management protocols to create naming contexts or new
replicas. LDAP may be sufficient for this. The document describes
how new replicas and naming contexts are represented, in the
directory, as entries, attributes, and attribute values.

Merrells, Reed, Srinivasan [Page 6]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

c) How transactions will be replicated. However, the architecture
should not knowingly prevent or impede them, given the Working
Group's incomplete understanding of the issues at this time.

d) The mapping or merging of disparate Schema definitions.

e) Support of overlapping replicated regions.

f) The case where separate attributes of an entry may be mastered by
different LDAP servers. This might be termed a 'Split Primary'.
Replica roles are defined in section 5.1.

3.4 Terms and Definitions

The definitions from the Replication Requirements document have been
copied here and extended.

For brevity, an LDAP server implementation is referred to throughout
as 'the server'.

The Naming Context is a subtree of entries in the Directory
Information Tree (DIT). There may be multiple Naming Contexts stored
on a single server. Naming contexts are defined in section 17 of
[X501].

A Replica is an instance of a replicated Naming Context.

A Replication Relationship is established between two or more Replicas
that are hosted on servers that cooperate to service a common area of
the DIT.

A Replication Agreement is defined between two parties of a
Replication Relationship. The properties of the agreement codify the
Unit of Replication, the Update Transfer Protocol to be used, and the
Replication Schedule of a Replication Session.

A Replication Session is an LDAP session between the two servers
identified by a replication agreement. Interactions occur between the
two servers, resulting in the transfer of updates from the supplier
replica to the consumer replica.

The Initiator of a Replication Session is the initiating server.

A Responder server responds to the replication initiation request from
the Initiator server.

A Supplier server is the source of the updates to be transferred.

Merrells, Reed, Srinivasan [Page 7]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

A Consumer server is the recipient of the update sequence.

The Update Transfer Protocol is the means by which the Replication
Session proceeds. It defines the order of events, and update exchange
mechanism between the Replication Relationship partners.

An Entry Filter is an LDAP filter expression that describes the
entries to be replicated.

A Sparse Replica contains a subset of the naming context entries,
being modified by the Entry Filter criteria associated with the
replica.

A Fractional Entry Specification is a list of entry attributes to be
included, or a list of attributes to be excluded in a replica. An
empty specification implies that all entry attributes are included.

A Fractional Entry is an entry that contains only a subset of its
original attributes. It has been modified by a Fractional Entry
Specification.

A Fractional Replica is a replica that holds Fractional Entries of its
naming context. Note that a Fractional Replica can also be a sparse
replica.

A Partial Replica is a Sparse and/or Fractional Replica.

4. Overview

This section provides an overview of the LDAP Replication
architecture. It is broken down into Directory Model, Information
Model, Policy Information, Update Transfer Protocol, Replication
Configuration and Management, Update Vector, and Time. The remainder
of the document discusses each in greater detail.

4.1 Directory Model

The basic directory model must be extended in a number of ways.

a) The Replication Management entries require a sub-entry object class
to hide them from end-user clients.

b) A form of timestamp, a Change Sequence Number (CSN), must be
recorded with every change to every entry. The change may be the

Merrells, Reed, Srinivasan [Page 8]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

creation of a new entry, the modification of an existing entry, or
the deletion of an existing entry.

c) Server implementations may need to include a CSN purging feature to
control Directory Information Base (DIB) storage space.

4.2 Information Model

A hierarchy of entries is defined that describe a Naming Context, its
Replicas, and its Replication Agreements.

The Naming Context Auxiliary Class is added to container entries that
may have separately defined replication policy. [LDUP Info]

Immediately subordinate to a Naming Context entry are the Replica
Subentry container entries that identify its LDAP Access Point, its
Replica Type, if it is a Sparse Replica, the LDAP search filter
defining which entries it holds, and if it is a Fractional Replica,
the attributes it does or does not hold. The attribute value of the
entry's Relative Distinguished Name (RDN) is termed the Replica ID and
is used as a component of each CSN.

Immediately subordinate in the namespace to a Replica Subentry are
Replication Agreement leaf entries which each identify another
Replica, the scheduling policy for replication operations, including
times when replication is to be performed, when it is not to be
performed, or the policies governing event-driven replication
initiation.

4.3 Policy Information

Administrative policy information needs to be consistently known and
applied by all replicas of a Naming Context. As such, the Naming
Context Auxiliary Class provides a convenient way to define attributes
which can communicate those policies among all replicas and users of
the directory.

4.4 Update Transfer Protocol

A Replication Session occurs between a Supplier server and Consumer
server over an LDAP connection. The session initiator, termed the
Initiator, could be either the Supplier or Consumer. The Initiator
sends an LDAP extended operation to the Responder identifying the
replication agreement being acted on. The Supplier then sends a
sequence of updates to the Consumer.

Merrells, Reed, Srinivasan [Page 9]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

All transfers are in one direction only. A two way exchange requires
two replication sessions; one session in each direction.

4.5 Conflict Detection and Resolution

As the Consumer receives updates from the Supplier it must check for
conflicts and correct them. There are three problem cases that must be
detected and resolved. Update conflicts, naming conflicts, and
orphaned entries. Change Sequence Numbers are used to totally order
the sequence of updates, thereby resolving any conflicting updates.

4.6 Replication Configuration and Management

The management entries described in the Information Model may be
created, modified, and deleted by administrative clients to configure
and manage the replication network. The administrative operations
performed over LDAP are discussed further in section 9.

4.7 Update Vector

Each Replica holds an Update Vector that records the most recent
change it has received for each of the other Replicas of this Naming
Context. The vector is used at the initiation of a replication session
to determine the sequence of updates that should be transferred.

4.8 Time

Because Change Sequence Numbers are primarily based on timestamps,
clock differences between servers can cause unexpected change
ordering. The synchronization of server clocks is not required, though
it is preferable that clocks are accurate. If timestamps are not
accurate, and a server consistently produces timestamps which are
significantly older than those of other servers, its updates will not
have effect and the real world time ordering of updates will not be
maintained.

However, an implementation may choose to require clock
synchronisation. The Network Time Protocol [NTP] [SNTP] offers a
protocol means by which heterogeneous server hosts may be time
synchronised.

Merrells, Reed, Srinivasan [Page 10]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

5. Directory Model

The following sections describe changes to the basic directory model
that are required by the replication architecture.

5.1 Replica Type

Each Replica is characterized with a replica type. This may be
Primary, Updatable, or Read-Only. The latter two types may be further
defined as being Sparse, Fractional, or Partial.

5.1.1 Primary Replica

The Primary Replica is a full copy of the Replica, to which all
applications that require strong consistency should direct their LDAP
operations. There can be only one Primary Replica within the set of
Replicas of a given Naming Context. It is also permissible for none
of the Replicas to be designated the Primary. The Primary Replica must
not be a Partial Replica.

5.1.2 Updatable Replica

An Updatable Replica is a Replica that accepts all LDAP operations,
but is not the Primary Replica. There could be none, one, or many
Updatable Replicas within the set of Replicas of a given Naming
Context. An Updatable Replica must not be a Fractional Replica.

5.1.3 Read-Only Replica

A Read-Only Replica will accept only non-modifying LDAP operations.
All modification operations shall be referred to an updateable
Replica, usually to its supplier. A Read-Only Replica may be a
Partial Replica.

5.1.4 Sparse Replica

Sparse Replicas can be Read-Only or Updatable. Update operations
targeted at entries outside of the Entry Filter scope must be referred
to another Updatable Replica. The server referred to would usually be
a Supplier of this Sparse Replica.

Merrells, Reed, Srinivasan [Page 11]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

5.1.5 Fractional Replicas

Fractional Replicas must always be Read-Only. All updates operations
must be referred to an Updatable Replica. The server referred to would
usually be a Supplier of this Fractional Replica.

5.1.6 Partial Replica

A Partial Replica is a Sparse and/or Fractional Replica, so the
constraints that apply to Sparse and Fractional Replicas apply.
Partial Replicas that are Fractional must always be Read-Only.

5.2 Sub-Entries

Replication management entries are to be stored at the base of the
replicated naming context. They will be of a subentry objectclass to
exclude them from regular searches. Entries with the objectclass
subentry are not returned as the result of a search unless the filter
component "(objectclass=subentry)" is included.

5.3 Unique Identifiers

Distinguished names can change, so are therefore unreliable as
identifiers. A Unique Identifier must therefore be assigned to each
entry as it is created. This identifier will be stored as an
operational attribute of the entry. The unique identifier could be
generated by a number of algorithms, so we propose that the first
octet be a prefix to identify its type. The prefix zero is reserved to
signify the UUID (Universally Unique IDentifier) format, also known as
GUID (Globally Unique IDentifier) [UUID]. An example UUID would be,
58DA8D8F-9D6A-101B-AFC0-4210102A8DA7.

Support for alternative algorithms is provided so that future better
unique identifier generation algorithms may be easily adopted.
Implementations may also wish to impose some structure to their unique
identifiers to ease implementation of Conflict Detection & Resolution.

5.4 LDAP Change Sequence Numbers

Every change, caused by an LDAP update operation, is assigned a
sequence number. The Change Sequence Number (CSN) is formed of four
components. In order of significance they are; the time, a change
count, a Replica ID, and a modification number.

Merrells, Reed, Srinivasan [Page 12]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

The time component is a year-2000-safe representation of the real
world time, with a granularity of one second. Should LDAP update
operations occur at different replicas, to the same data, within the
same single second, then the change count is used to further order the
changes.

Because LDAP update operations at a single replica may also occur to
the same data in a single second, the change count component of the
CSN is provided to further order the changes. Each replica maintains
a count of changes made against it, which is reset to zero at the
start of each second, and is monotonically increasing within the
second, incremented for each LDAP update operation applied to the
replica. Should LDAP update operations occur at different replicas, to
the same data, within the same single second, and happen to be
assigned the same change count, then the Replica ID is used to further
order the changes.

The Replica ID is the value of the RDN attribute on the Replica
Subentry. The Replica ID could be assigned programmatically or
administratively, in either case short values are advised to minimise
resource usage. The IA5CaseIgnoreString syntax is used to compare and
order Replica ID values.

The fourth and final CSN component, the modification number, is used
for ordering the modifications within an LDAP Modify operation

The preferred time syntax is: yyyy mm dd hh:mi:ssz # 0xSSSS # replica
id # 0xssss

The 'z' in the time stipulates that the time is expressed in GMT
without any daylight savings time offsets permitted, and the 0xssss
represents the hexidecimal representation of an unsigned integer.
Implementations must support 16 bit change counts and should support
longer ones (32, 64, 128).

An example CSN would be " 1998081018:44:31z#0x000F#1#0x0000 ". The
update assigned this CSN would have been applied at time
1998081018:44:31z happened to be the 16th update which occurred in
that second, and was made against the replica with id '1'.

5.5 State Storage and Representation

All changes made to an entry, and its attributes, include the CSN
assigned at the server where the change was first made. Each of the
LDAP update operations Add, Modify, Modify RDN (LDAP v2), Modify DN
(LDAP v3), and Delete change their target entry in different ways, and

Merrells, Reed, Srinivasan [Page 13]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

record the CSN of the change differently. This state information must
be stored for each entry to enable Conflict Detection and Resolution.

State information is recorded at three levels within each entry. At
the entry level, attribute level, and attribute value level. Each is
briefly described below.

5.5.1 Entry Change State Storage and Representation

When an entry is created, with the LDAP Add operation, the CSN of the
change is added to the entry as the value of an operational attribute
named 'createdEntryCSN', of syntax type LDAPChangeSequenceNumber.

createdEntryCSN ::= csn

Deleted entries are marked as deleted by the addition of the object
class 'deletedEntry'. The attribute 'deletedEntryCSN', of syntax type
LDAP Change Sequence Number, is added to record where and when the
entry was deleted. Deleted entries are not visible to LDAP clients -
they may not be read, they don't appear in lists or search results,
and they may not be changed once deleted. Names of deleted entries
are available for reuse by new entries immediately after the deleted
entry is so marked. It may be desirable to allow deleted entries to be
accessed and manipulated by management and data recovery applications,
but that is outside the scope of this document.

deletedEntryCSN ::= csn

5.5.2 Attribute Change State Storage and Representation

When all values of an attribute have been deleted, the attribute is
marked as deleted and the CSN of the deletion is recorded. The deleted
state and CSN are stored by the server, but have no representation on
the entry, and may not be the subject of a search operation. This
state information must be stored to enable Conflict Detection and
Resolution to be performed.

5.5.3 Attribute Value Change State Storage and Representation

The Modification CSN for each value is to be set by the server when it
accepts a modification request to the value, or when a new value with
a later Modification CSN is received via Replication. The modified
value and the Modification CSN changes are required to be atomic, so
that the value and its Modification CSN cannot be out of synch on a
given server. The state information is stored by the server, but it

Merrells, Reed, Srinivasan [Page 14]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

has no representation on the entry, and may not be the subject of a
search operation.

When the value of an attribute is deleted the state of its deletion
must recorded, with the CSN of the modifying change. It must be stored
to enable Conflict Detection and Resolution to be performed.

5.6 LDAP Update Operations

The server must reject LDAP client update operations with a CSN that
is older than the state information that would be replaced if the
operation were performed. This could occur in a replication topology
where the difference between the clocks of updateable replicas was too
large. Result code 72, serverClocksOutOfSync, is returned to the
client.

5.7 Purging State Information

The state information stored with each entry need not be stored
indefinitely. A server implementation may choose to periodically, or
continuously, remove state information that is no longer required. The
mechanism is implementation-dependent, but to ensure interoperability
between implementations, the state information must not be purged
until all known replicas have received and acknowledged the change
associated with a CSN. This can be determined by constructing a Purge
Vector.

The Purge Vector is an Update Vector constructed from the Update
Vectors of all known replicas. Each replica has a sub-entry for each
known replica stored below its naming context. Each of those entries
contains the last known update vector for that replica. The lowest CSN
for each replica are taken from these update vectors to form the Purge
Vector.

All the CSNs stored that are lower than the Purge Vector may be
purged, because no changes with older CSNs can be replicated to this
replica.

5.7.1 Purging Deleted Entries, Attributes, and Attribute Values

The following conditions must hold before an item can be deleted from
the Directory Information Base.

1) The LDAP delete operation has been propagated to all replication
agreement partners.

Merrells, Reed, Srinivasan [Page 15]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

2) All the updates from all the other replicas with timestamps less
than the timestamp on the deletion have been propagated to the server
holding the deleted object (similarly for deleted attributes and
attribute values).

3) The clocks of the other Replicas must have advanced beyond the
deletion CSN of the deleted entry. Otherwise, it is possible for one
of those Replicas to generate operations with CSNs earlier than the
deleted object.

6. Information Model

This section describes the object classes of the entries that
represent the replication topology. The where, when and how of Naming
Context replication is administered through these entries. The LDUP
Working Group will publish an Internet Draft to fully detail all these
schema elements. [LDUP Info]

6.1 Entries, Semantics & Relationships

6.1.1 Root DSE Attributes

The Root DSE attribute 'replicaRoot', publishes the names of the
Replicas that are held on that server. Each value of the attribute is
the Distinguished Name of the root entry of the Replicated Area.

6.1.2 Naming Context Auxiliary Object Class and Entries

Each Naming Context contains attributes which hold common
configuration and policy information for all replicas of the Naming
Context.

A Naming Context Creation attribute records when and where the Naming
Context was created.

The Access Control Policy OID attribute defines the syntax and
semantics of Access Control Information for entries within the Naming
Context.

The Naming Context is based at the entry given the auxiliary class,
and continues down the tree until another Naming Context is
encountered.

Merrells, Reed, Srinivasan [Page 16]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

6.1.3 Replica Object Class and Entries

Each Replica is characterized by a replica type. This may be Primary,
Updatable, or Read-Only. The latter two types may be further defined
as being Sparse, Fractional, or Partial. The Replica entry will
include an Entry Filter for a Sparse Replica, a Fractional Entry
Specification for a Fractional Replica, and both an Entry Filter and
Fractional Entry Specification for a Partial Replica

There is a need to represent network addresses of servers holding
replicas and participating in Replication Agreements. The X.501
Access Point syntax is not sufficient, in that it is tied specifically
to OSI transports. Therefore, a new syntax will be defined for LDAP
which serves the same purpose, but uses IETF-style address
information. [LDUP Info]

An Update Vector (detailed below) describes the point to which the
Replica has been updated, in respect to all the other Replicas of the
Naming Context.

The intent is to enable distributed operations in LDAP with the
replica information stored there, but not to complete the process of
turning LDAP into a fully distributed service.

6.1.4 Lost and Found Entry

When replicating operations between servers, conflicts may arise that
cause a parent entry to be removed causing its child entries to become
orphaned. In this case the conflict resolution algorithm will make the
Lost and Found Entry the child's new superior.

Each Replica Entry names it's Lost and Found Entry, which would
usually be an entry below the Replica Entry itself. This well known
place allows administrators, and their tools, to find and repair
abandoned entries.

6.1.5 Replication Agreement Object Class and Entries

The Replication Agreement defines:

1. The schedule for Replication Sessions initiation.

2. The server that initiates the Replication Session, either the
Consumer or the Supplier.

3. The authentication credentials that will be presented between
servers.

Merrells, Reed, Srinivasan [Page 17]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

4. The network/transport security scheme that will be employed in
order to ensure data confidentiality.

5. The replication protocols and relevant protocol parameters to be
used for Full and Incremental updates. An OID is used to identify
the update transfer protocol, thus allowing for future extensions
or bilaterally agreed upon alternatives.

6. If the Replica is Sparse, the Entry Filter.

7. If the Replica is Fractional, the Fractional Entry Specification.

8. If the Replica is Partial, the Entry Filter and Fractional Entry
Specification.

Permission to participate in replication sessions will be controlled,
at least in part, by the presence and content of replica agreements.

The Supplier must be subject to the access control policy enforced by
the Consumer. Since the access control policy information is stored
and replicated as directory content, the access control imposed on the
Supplier by the Consumer must be stored in the Consumer's Replication
Agreement.

6.1.5.1 Replication Schedule

There are two broad mechanisms for initiating replication sessions:
(1) scheduled event driven and (2) change event driven. The mechanism
used to schedule replication operations between two servers is
determined by the Schedule information that is part of the Replication
Agreement governing the Replicas on those two servers. Because each
Replication Agreement describes the policy for one direction of the
relationship, it is possible that events propagate via scheduled
events in one direction, and by change events in the other.

Change event driven replication sessions are, by their nature,
initiated by suppliers of change information. The server, which the
change is made against, schedules a replication session in response to
the change itself, so that notification of the change is passed on to
other Replicas.

Scheduled event driven replication sessions can be initiated by either
consumers or suppliers of change information. The schedule defines a
calendar of time periods during which Replication Sessions should be
initiated.

Schedule information may include both scheduled and change event
driven mechanisms. For instance, one such policy may be to begin

Merrells, Reed, Srinivasan [Page 18]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

replication within 15 seconds of any change event, or every 30 minutes
if no change events are received.

6.1.6 Update Vector

Each Replica entry includes an Update Vector to record the point to
which the replica has been updated. The vector is a set of CSN values,
one value for each known updateable Replica. Each CSN is the most
recent change, made at that Replica, that has been replicated to this
Replica.

For example, consider two updatable replicas of a naming context, one
is assigned replica id '1', the other replica id '2'. Each is
responsible for maintaining its own update vector, which will contain
two CSNs, one for each replica. So, if both replicas are identical
they will have equivalent update vectors.

Both Update Vectors =

{ 1998081018:44:31z#0x000F#1, 1998081018:51:20z#0x0001#2 }

Subsequently, at 7pm, an update is applied to replica '2', so its
update vector is updated.

Replica '1' Update Vector =

{ 1998081018:44:31z#0x000F#1, 1998081018:51:20z#0x0001#2 }

Replica '2' Update Vector =

{ 1998081018:44:31z#0x000F#1, 1998081019:00:00z#0x0000#2 }

Since the Update Vector records the state to which the replica has
been updated, a supplier server, during Replication Session
initiation, can determine the sequence of updates that should be sent
to the consumer. From the example above no updates need to be sent
from replica '1' to replica '2', but there is an update pending from
replica '2' to replica '1'.

Because the Update Vector embodies knowledge of updates made at all
known replicas it supports replication topologies that include
transitive and redundant connections between replicas. It ensures that
changes are not transferred to a consumer multiple times even though
redundant replication agreements may exist. It also ensures that
updates are passed across the replication network between replicas
that are not directly linked to each other.

Merrells, Reed, Srinivasan [Page 19]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

It may be the case that a CSN for a given replica is absent, for one
of two reasons.

1. CSNs for Read-Only replicas might be absent because no changes will
have ever been applied to that Replica, so there are no changes to
replicate.

2. CSNs for newly created replicas may be absent because no changes to
that replica have yet been propagated.

An Update Vector might also contain a CSN for a replica that no longer
exists. The replica may have been temporarily taken out of service,
or may have been removed from the replication topology permanently. An
implementation may choose to retire a CSN after some configurable time
period.

7. Policy Information

Policy information governs the behavior of the server. It may be
represented in the DIT as sub-entries, attributes, and attribute
values.

When replicating a naming context that is itself a subtree of another
naming context, there may be policy information stored in its
antecedent entries. The most common examples are prescriptive access
control information and inherited schema definition. Implementations
may also define other policy attributes, or sub-entries, that apply to
a whole subtree. For a naming context to be faithfully reproduced,
this generational information must also be replicated. In all cases
the policy information is transmitted as if it were an element of the
Replica root entry.

Policy information is always replicated in the same manner as any
other entries, attributes, and attribute values.

7.1 Access Control

The Access Control Models supported by a server are identified by the
'accessControlScheme' multi-valued attribute of the Root DSE entry.
Each model is assigned an OID so that Consumers and Suppliers can
determine if their access control policy will be faithfully imposed
when replicated.

An access control policy must be consistently applied by all servers
holding replicas of the same Naming Context. Therefore, the Access

Merrells, Reed, Srinivasan [Page 20]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

Control Policy attribute is to be an operational attribute of the
Naming Context Auxiliary Class. Thus, any consumer of the directory,
and any server which would replicate a Naming Context, will know that
an Access Control Policy is defined for the Naming Context, and by
reference to the OID value of this attribute, know what policy
mechanism to invoke to enforce that policy. Administrators are
strongly cautioned against placing replicas of naming contexts on
servers that cannot enforce the policy required by the Access Control
Policy OID. Servers should refuse to accept replicas with policies
they are unable to properly interpret.

7.2 Schema Knowledge

Schema subentries should be subordinate to the naming contexts to
which they apply. Given our model, a single server may hold replicas
of several naming contexts. It is therefore essential that schema
should not be considered to be a server-wide policy, but rather to be
scoped by the namespace to which it applies.

Schema modifications replicate in the same manner as other directory
data. Given the strict ordering of replication events, schema
modifications will naturally be replicated prior to entry creations
which use them, and subsequent to data deletions which eliminate
references to schema elements to be deleted. Servers should not
replicate information about entries which are not defined in the
schema. Servers should not replicate modifications to existing schema
definitions for which there are existing entries and/or attributes
which rely on the schema element.

Should a schema change cause an entry to be in violation of the new
schema, it is recommended that the server preserve the entry for
administrative repair. The server could add a known object class to
make the entry valid and to mark the entry for maintenance.

8. Update Transfer Protocol

This section describes the process by which a Replication Session is
established, how updates are transferred, and how a session is
terminated.

Subject to Replication Agreements, either the supplier or the consumer
server can initiate the replication session. This document only
defines a transfer protocol for the supplier to push changes to the
consumer. Other protocols could be defined to transfer changes,

Merrells, Reed, Srinivasan [Page 21]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

including those which pull changes from the supplier to the consumer,
but those are left for future work.

8.1 Replication Session Initiation

The Initiator starts the Replication Session by opening an LDAP
connection to its Responder. The Initiator binds using the
authentication credentials provided in the Replication Agreement. The
extended LDAP operation Start Replication is then sent by the
Initiator to the Responder. This operation identifies which role each
server will perform, and what type of replication is to be performed.
One server is to be the Consumer, the other the Supplier, and the
replication may be either Full or Incremental. If the Responder does
not support the requested type of replication then an error is
returned.

8.1.1 Authentication

The initiation of a Replication Session is to be restricted to only
permitted clients. The identity and credentials of a connected server
are determined via the bind operation. Access control on the
Replication Agreement determines if the Replication Session may
proceed. Otherwise, the insufficientAccessRights error is returned.

8.1.2 Consumer Initiated

The Consumer binds to the Supplier using the authentication
credentials provided in the Replication Agreement. The Consumer sends
the Start Replication extended request to begin the Replication
Session. The Supplier returns a Start Replication extended response
containing a response code. The Consumer then disconnects from the
Supplier. If the Supplier has agreed to the replication session
initiation, it binds to the Consumer and behaves just as if the
Supplier initiated the replication.

8.1.3 Supplier Initiated

The Supplier binds to the Consumer using the authentication
credentials provided in the Replication Agreement. The Supplier sends
the Start Replication Request extended request to begin the
Replication Session. The Consumer returns a Start Replication extended
response containing a response code, and possibly its Update Vector.
If the Consumer has agreed to the Replication Session initiation, then
the transfer protocol begins.

Merrells, Reed, Srinivasan [Page 22]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

8.2 Start Replication Session

8.2.1 Consumer Initiated, Start Replication Session

The Supplier should not return its Update Vector when the Consumer
initiates a replication session.

8.2.2 Supplier Initiated, Full Update, Start Replication Session

The Consumer should not return its Update Vector when it is about to
be initialised or reinitialised.

8.2.3 Supplier Initiated, Incremental Update, Start Replication
Session

The Supplier uses the Consumer's Update Vector to determine the
sequence of changes that should be sent to the Consumer.

8.2.4 Start Replication Request

A client may request this operation by transmitting an LDAP PDU
containing an LDAP ExtendedRequest, defined as follows. [LDAPv3]

ExtendedRequest ::= [APPLICATION 23] SEQUENCE {

requestName [0] LDAPOID,

requestValue [1] OCTET STRING }

The requestName field must be set to the string
"2.16.840.1.113730.3.5.3".

The requestValue field will contain as a value the DER-encoding of the
following ASN.1 data type:

SEQUENCE {

namingContextDN LDAPDN,

replicaID OCTET STRING,

protocolOID LDAPOID

}

The parameters of the Start Replication Request are:

Merrells, Reed, Srinivasan [Page 23]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

- The Distinguished Name of the entry at the root of the Naming
Context.

- The Replica Identifier of the Initiator.

- The OID identifying the Update Transfer Protocol to be used.

From the DN and Replica ID the Responder can determine which
Replication Agreement is being acted on. The Protocol OID identifies
the Update Transfer Protocol that the Initiator wishes to use, this
indicates whether the it is to be a Full or Incremental update.

8.2.5 Start Replication Response

If a server implements this extension, then when the request is made
it will return an LDAP PDU containing an ExtendedResponse, defined as
follows. [LDAPv3]

ExtendedResponse ::= [APPLICATION 24] SEQUENCE {

COMPONENTS OF LDAPResult,

responseName [10] LDAPOID OPTIONAL,

responseValue [11] OCTET STRING OPTIONAL }

The responseName field must be set to the string
"2.16.840.1.113730.3.5.4". The responseValue field, when present, will
contain as a value the DER-encoding of the following ASN.1 data type:

SEQUENCE {

startReplicationResult [0] startReplicationStatus,

updateVector [1] SET OF OCTET STRING OPTIONAL,

}

startReplicationStatus ::= ENUMERATED {

success (0), -- operation succeeded

operationsError (1), -- server internal failure

protocolError (2), -- protocol error

insufficientAccessRights (50), -- refused operation

Merrells, Reed, Srinivasan [Page 24]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

busy (51), -- already being updated.

other (80)

}

The startReplicationResult field indicates any error condition
encountered in the processing of the operation.

In Supplier Initiated Replication the Consumer Responder responds with
its Update Vector.

8.3 Update Transfer

Each Update Transfer Protocol is identified by an OID. A conformant
server implementation must support the two update protocols defined
here, and may support many others. A server will advertise its
protocols in the Root DSE multi-valued attribute
'supportedReplicationProtocols'.

The two mandatory to implement protocols will be defined by the LDUP
Working Group in another Internet Draft. One is to provide a Full
Update for initialisation and re-initialisation of a replica, the
other is to maintain that replica via an Incremental Update.

Each entry to be transferred is passed through the Entry Filter and
Fractional Entry Specification.

Necessary extended operations will be defined to support efficient
transfer of change information from supplier to consumer servers.

8.3.1 Full Update Transfer

This Full Update Protocol will provide a bulk transfer of the replica
contents for the initial population of new replicas, and the
refreshing of existing replicas.

Upon receiving a full update request the Consumer must replace any
existing information in its replica with that sent from the Supplier.

The Consumer need not service any requests for this Naming Context
whilst the full update is in progress. The Consumer could return a
referral to another replica, possibly the supplier. [REF]

Merrells, Reed, Srinivasan [Page 25]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

8.3.2 Incremental Update Transfer

For efficiency, the Incremental Update Protocol transmits only those
changes that have been made to the Naming Context since updates were
last transmitted, that the Consumer has not already received. In a
replication topology with transitive redundant replication agreements,
changes may propagate through the replica network via different
routes. The Supplier uses the Consumer's Update Vector to determine
the sequence of updates that should be sent to the Consumer.

As the transmission of updates proceeds the Consumer may return the
last CSN received as a form of committed acknowledgement. This
provides an implicit restart value for the Supplier, should the
connection be interrupted.

Each individual change may contain a sequence of entry modifications
that must be preserved when transferred. The atomicity of the LDAP
operation must be preserved when it is applied to the Consumer
Replica.

Changes need not be transmitted in ascending change sequence number.

Each change transmitted includes the Unique Identifier of the subject
entry and the CSN of the originating operation. This allows the
Consumer to keep track of which changes it has received.

The Consumer must not support multiple concurrent replication sessions
with more than one Supplier for the same Naming Context. A Supplier
that attempts to initiate a Replication Session with a Consumer
already participating as a Consumer in another Replication Session
will receive the busy error code.

8.3.2.1 Conflict Detection and Resolution

A consequence of permitting multiple updateable replicas within a
replication topology is that conflicting update changes may occur.
Updates are conflicting if they are concurrently accepted by different
replicas, meaning that, at the time of acceptance, the accepting
replica had not yet seen the other update.

This section briefly describes the types of change collisions that can
occur. The LDUP Working Group will publish an Internet Draft fully
defining the Conflict Detection and Resolution mechanism.

Merrells, Reed, Srinivasan [Page 26]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

8.3.2.2 Update Conflict Detection and Resolution

A Consumer will receive replication changes from its various agreement
partners. Those changes must be reconciled with the current replica
contents and any previously received changes. In broad outline,
received replication changes are compared to the state information
associated with the item being operated on. If the change has a more
recent CSN, then it is applied to the directory contents. If the
replica has replication agreements where it acts as a supplier then
the change is retained for forwarding at the appropriate time. If the
change has an older CSN it is no longer relevant and is simply
discarded.

8.3.2.3 Naming Conflict Detection and Resolution

Naming collisions may occur when updates are received by a server for
a given named entry whose Unique Identifier is different from that of
an already existing entry with the same distinguished name. This may
occur because events from various replicas cannot be guaranteed to
arrive in sequence, or because of conflicting data changes being
entered at two or more different replicas.

Consider the following scenario:

The entry named "A" has a Unique Identifier of "3", and it exists on
each of three replicas, X, Y, and Z. At replica X, entry "A" is
deleted, and then another entry "A" is created with the same name, but
with the Unique Identifier of "4". If at replica Y a modification to
entry "A" is entered before the deletion and creation events from X
are received, Y will attempt to replicate the modification to "A" to
X. When received, X will note that the Unique Identifier of the entry
"A" which is being modified is "3". Because the entry "A" with Unique
Identifier "3" is marked as "deleted" on X, server X will simply
ignore the modification, since it applies to a deleted object, and not
to the entry currently defined with name "A", whose Unique Identifier
is "4". Thus, the confusion over which entry was modified is
resolved.

8.3.2.4 Orphaned Entry Detection and Resolution

An entry may also become an orphan, if its parent entry is removed. In
this case the conflict may be resolved by making the orphan a child of
the Lost and Found Entry. This well known place allows administrators
and their tools to find and repair abandoned entries.

Merrells, Reed, Srinivasan [Page 27]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

8.4 End Replication Session

A Replication Session is terminated by the Supplier by sending an End
Replication LDAP extended request, see section 8.4.3. The purpose of
the request and response operations is to carry the Update Vector from
the Supplier to the Consumer in the Full Update case, and to convey
the Update Vector from the Consumer to the Supplier in the Incremental
Update case.

8.4.1 Full Update, End Replication Session

Since the Full Update also replicates the sub-entry that represents
the Supplier Replica the Consumer will have received the Update Vector
that represents the update state of the Consumer.

After a Full Update transfer the Supplier sends the Update Vector that
reflects the update state of the full replica information sent. The
Consumer records this as its Update Vector.

The Supplier could be accepting updates whilst the update is in
progress. Once the Full Update has completed, an Incremental Update
should be performed to transfer these changes.

8.4.2 Incremental Update, End Replication Session

If the Supplier sent none of its own updates to the Consumer, then the
Supplier's CSN within the Supplier's update vector should be updated
with the earliest possible CSN that it could generate, to record the
time of the last successful replication session. The Consumer will
have received the Supplier's Update Vector in the replica sub-entry it
holds for the Supplier replica.

The Consumer's resultant Update Vector CSN values will be at least as
great as the Supplier's Update Vector.

The Supplier may request that the Consumer return its resultant Update
Vector so that the Supplier can update its replica sub-entry for the
Consumer Replica. The Supplier requests this by setting a flag in the
End Replication Request. The default flag value is TRUE meaning the
Consumer Update Vector must be returned.

8.4.3 End Replication Request

A client may request this operation by transmitting an LDAP PDU
containing an LDAP ExtendedRequest, defined as follows. [LDAPv3]

Merrells, Reed, Srinivasan [Page 28]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

ExtendedRequest ::= [APPLICATION 23] SEQUENCE {

requestName [0] LDAPOID,

requestValue [1] OCTET STRING }

The requestName field must be set to the string
"2.16.840.1.113730.3.5.5".

The requestValue field will contain as a value the DER-encoding of the
following ASN.1 data type:

SEQUENCE {

returnUpdateVector BOOLEAN

}

When the update has completed the Supplier sends this extended request
to inform the Consumer that all updates have been sent, and to advise
the Consumer if its Update Vector should be returned.

8.4.4 End Replication Response

If a server implements this extension, then when the request is made
it will return an LDAP PDU containing an ExtendedResponse, defined as
follows. [LDAPv3]

ExtendedResponse ::= [APPLICATION 24] SEQUENCE {

COMPONENTS OF LDAPResult,

responseName [10] LDAPOID OPTIONAL,

responseValue [11] OCTET STRING OPTIONAL }

The responseName field must be set to the string
"2.16.840.1.113730.3.5.6". The responseValue field, when present, will
contain as a value the DER-encoding of the following ASN.1 data type:

SEQUENCE {

endReplicationResult [0] endReplicationStatus,

updateVector [1] SET OF OCTET STRING OPTIONAL

}

Merrells, Reed, Srinivasan [Page 29]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

endReplicationStatus ::= ENUMERATED {

success (0), -- operation succeeded

operationsError (1), -- server internal failure

protocolError (2), -- protocol error

other (80)

}

The endReplicationResult field indicates any error condition
encountered in the processing of the operation. If the
returnUpdateVector flag in the request was set then the Consumer
returns its Update Vector to the Supplier.

8.5 Integrity & Confidentiality

Data integrity (ie, protection from unintended changes) and
confidentiality (ie, protection from unintended disclosure to
eavesdroppers) SHOULD be provided by appropriate selection of
underlying transports, for instance TLS, or IPSEC. Replication MUST
be supported across TLS LDAP connections. Servers MAY be configured
to refuse replication connections over unprotected TCP connections.

9. Replication Configuration and Management

Replication management entries, such as replica or replication
agreement entries, can be altered on any updateable replica. These
entries are implicitly included in the directory entries governed by
any agreement associated with this naming context. As a result, all
servers with a replica of a naming context will have access to
information about all other replicas and associated agreements.

The deployment and maintenance of a replicated directory network
involves the creation and management of all the replicas of a naming
context and replication agreements among these replicas. This section
outlines, through an example, the administrative actions necessary to
create a new replica and establish replication agreements. Typically,
administrative tools will guide the administrator and facilitate these
actions. The objective of this example is to illustrate the
architectural relationship among various replication related
operational information.

Merrells, Reed, Srinivasan [Page 30]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

A copy of an agreement should exist on both the supplier and consumer
side for the replication update transfer protocol to be able to start.
For this purpose, the root of the naming context, replica objects and
the replication agreement objects are created first on one of the
servers. A copy of these objects are then manually created on the
second server associated with the agreement.

The scenario below starts with a server (named DSA1) that holds an
updateable replica of a naming context NC1. Procedures to establish
an updateable replica of the naming context on a second server (DSA2)
are outlined.

On DSA1:

1) Add the context prefix for NC1 to the Root DSE attribute
'replicaRoot' if it does not already exist.

2) Alter the 'ObjectClass' attribute of the root entry of NC1 to
include the "namingContext" auxiliary class.

3) Create a replica object, NC1R1, (as a child of the root of NC1) to
represent the replica on DSA1. The attributes include replica type
(updateable, read-only etc.) and DSA1 access point information.

4) Create a copy of the replica object NC1R2 (after it is created on
DSA2)

5) Create a replication agreement, NC1R1-R2 to represent update
transfer from NC1R1 to NC1R2. This object is a child of NC1R1.

On DSA2:

1) Add NC1's context prefix to the Root DSE attribute 'replicaRoot'.

2) Create a copy of the root entry of NC1 as a copy of the one in DSA1
(including the namingContext auxiliary class)

3) Create a copy of the replica object NC1R1

4) Create a second replica object, NC1R2 (as a sibling of NC1R1) to
represent the replica on DSA2.

5) Create a copy of the replication agreement, NC1R1-R2

6) Create a replication agreement, NC1R2-R1, to represent update
transfer from NC1R2 to NC1R1. This object is a sibling of NC1R1-
R2.

Merrells, Reed, Srinivasan [Page 31]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

After these actions update transfer to satisfy either of the two
agreements can commence.

If data already existed in one of the replicas, the update transfer
protocol should perform a complete update of the data associated with
the agreement before normal replication begins.

10. Time

The server assigns a CSN for every LDAP update operation it receives.
Since the CSN is principally based on time, the CSN is susceptible to
the Replica clocks drifting in relation to each other (either forwards
or backwards).

The server must never assign a CSN older than or equal to the last CSN
it assigned.

The server must reject update operations, from any source, which would
result in setting a CSN on an entry or a value which is earlier than
the one that is there. The error code serverClocksOutOfSync (72)
should be returned.

11. Security Considerations

The preceding architecture discussion covers the server
authentication, session confidentiality, and session integrity in
sections 8.1.1 and 8.5

The internet draft "Authentication Methods" for LDAP, provides a
detailed LDAP security discussion. Its introductory passage is
paraphrased below. [AUTH]

A Replication Session can be protected with the following security
mechanisms.

1) Authentication by means of the SASL mechanism set, possibly backed
by the TLS credentials exchange mechanism,

2) Authorization by means of access control based on the Initiators
authenticated identity,

3) Data integrity protection by means of the TLS protocol or data-
integrity SASL mechanisms,

Merrells, Reed, Srinivasan [Page 32]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

4) Protection against snooping by means of the TLS protocol or data-
encrypting SASL mechanisms,

The configuration entries that represent Replication Agreements may
contain authentication information. This information must never be
replicated between replicas.

12. Acknowledgements

This document is a product of the LDUP Working Group of the IETF. The
contributions of its members is greatly appreciated.

13. References

[AUTH] - M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
"Authentication Methods for LDAP", Internet Draft, draft-ietf-ldapext-
authmeth-02.txt, July 1998.

[BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.

[LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December1997.

[LDUP Requirements] - R. Weiser, E. Stokes ôLDAP Replication
Requirementsö, Internet Draft, draft-weiser-replica-req-02.txt, April
1998.

[LDUP Info.] - E. Reed, "LDUP Replication Information Model", Internet
Draft, draft-reed-ldup-infomod-00-1.txt, August 1998.

[NTP] - D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305,
March, 1992.

[REF] - T. Howes, Mark Wahl, "Referrals and Knowledge References in
LDAP Directories", Internet draft, draft-ietf-ldapext-referral-00.txt,
March 1998.

[RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.

[RFC2252] - M. Wahl, A. Coulbeck, T. Howes, S. Kille, ôLightweight
Directory Access Protocol (v3): Attribute Syntax Definitionsö, RFC
2252, December 1997.

Merrells, Reed, Srinivasan [Page 33]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

[SNTP] - D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October
1996.

[TLS] - J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt,
July 1998.

[UUID] - P. Leach, R. Salz, "UUIDs and GUIDs", Internet draft, draft-
leach-uuids-guids-01.txt, February 1998.

[X501] - ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594-2:1993,
Information Technology - Open Systems Interconnection - The Directory:
Models

[X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995,
Information technology - Abstract Syntax Notation One (ASN.1):
Specification of Basic Notation

[X525] - ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997,
Information Technology - Open Systems Interconnection - The Directory:
Replication

14. Intellectual Property Notice

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it has
made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. [BCP-11]
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

Merrells, Reed, Srinivasan [Page 34]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

15. Copyright Notice

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

16. Authors' Address

John Merrells
Netscape Communications, Inc.
501 East Middlefield Road
Mountain View
CA 94043

E-mail: merrells@netscape.com
Phone: +1 650-937-5739

Edwards E. Reed
Novell, Inc.
122 E 1700 S
Provo, UT 84606

E-mail: ed_reed@novell.com
Phone: +1 801-861-3320
Fax: +1 801-861-2220

Merrells, Reed, Srinivasan [Page 35]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

Uppili Srinivasan
Oracle, Inc.
Redwood Shores

E-mail: usriniva@us.oracle.com
Phone: +1 650 506 3039

LDUP Engineering Mailing List: l dup-repl@external.cisco.co m

17. Appendix A - Open Issues

17.1 Configuration Entries

There have been a number of proposals to keep the replication
configuration entries out of the replicated area. The Replica and
Replication Agreement entries would appear in some configuration area
of the DIT that would not be replicated.

17.2 Management

Topics that need coverage.

1. Creation, Destruction, and Modification of Naming Contexts,
Replicas, and Replication Agreements.

2. Promotion and Demotion of Replicas from Read-Only to Updateable to
Primary.

3. Patching up of partitioned replication networks.

4. Discuss redundant replication agreements.

5. Triggering a Full Update for a Replication Agreement.

17.3 Purging

The constraints that must hold to prevent premature purging of change
and state information have been under discussion.

17.4 Update Transfer: Errors, Recovery, Diagnostics and Repair

1. How should the protocol react to connection loss?

Merrells, Reed, Srinivasan [Page 36]
Expires 22 September 1999

INTERNET-DRAFT LDAP Replication Architecture April 22, 1998

2. Should the Replication Agreement protocol parameters define the
acknowledgement frequency?
3. Should keep-alive and progress feedback be provided for long
operations. For instance replica preparation during Full Update
for reinitialisation?

Merrells, Reed, Srinivasan [Page 37]
Expires 22 September 1999