INTERNET-DRAFT Russel Weiser
Informational Draft Novell, Inc.
Expires 13 October 1998 Ellen Stokes
IBM
13 April 1998
LDAP Replication Requirements
<draft-weiser-replica-req-01.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract
This document discusses the fundamental requirements for replication
of data accessible via the LDAPv3 [RFC2251] protocol. It is intended
to be a gathering place for general replication requirements needed to
provide interoperability between informational directories.
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 [RFC2119].
Weiser & Stokes 13 October 1998 [Page 1]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicability Statement . . . . . . . . . . . . . . . . . . . . . 5
5. Replication Model . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Replication Protocol . . . . . . . . . . . . . . . . . . . . . . . 7
7. Replication Predetermined Agreements . . . . . . . . . . . . . . . 8
8. Administration and Management Considerations . . . . . . . . . . . 8
9. Other for furhter discussion or the garbage heap . . . . . . . . . 9
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
Weiser & Stokes 13 October 1998 [Page 2]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
1. Introduction
The ability to distribute directory information throughout the network
provides a two fold benefit to the network: (1) increasing the
reliabililty of the directory through fault tolerance, and (2) brings
the directory content closer to the clients using the data. LDAPs
acceptance as a access protocol for directory information is driving
the need to distribute LDAP directory content among servers within
enterprise and Internet. Currently LDAP does not define a replication
mechanism and only generally mentions LDAP shadow servers (see
[RFC2251] and [Changelog]) in passing. The requirements for
replication are critical to the successful deployment and acceptance
of LDAP in the market place.
2. Terminology
For the purposes of this document, the following definitions are used:
Replication - The process of copying portions of naming context
information and content, between multiple LDAP servers, such that
certain, predefined portions of the information are available from
many geographic locations. that which is done between either
homogeneous implementations across heterogeneous platforms
(operating systems) or heterogeneous implementations supporting
identical replication across heterogeneous platforms (operating
systems). No mapping mechanisms are required here.
Synchronization - The process whereby LDAP servers participating in
the replication, are brought into a state where copies of the
information they make accessible are consistent with the other.
that which happens between heterogeneous directory servers
onheterogeneous platforms (operating systems). The different
directory server implementations do not have to provide an LDAP
interface. One could certainly define a wire protocol. The
mapping of data means mapping of attributes. For example, in one
system, the attribute is full name, in the other it is common name
Incremental Update - The process of updating a replica, or copy, of
a naming context, by updating only those fields or objects which
have changed.
Master Replica - A writeable copy of the replicated information.
Slave Replica - A read-only copy of the replicated information.
Multi-Master Replication - A replication model where entries can
be written and updated on any of several replica copies, without
requiring communication with other masters before the write or
update is performed.
Weiser & Stokes 13 October 1998 [Page 3]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
Master Slave, or Single Master Replication - Replication model that
assumes only one server, the master, allows write access to the
replicated data. Note that Master-Slave replication can be
considered a proper subset of multi-master replication.
One-way Directory Synchronization - The process of synchronization
in a single direction where the authoritative source information is
provided to a replica.
Two-way Directory Synchronization - The process of synchronization
where change information may flow bidirectionally between two
replicas.
3. Objective
The major objective is to provide an interoperable LDAP V3
directory synchronization protocol which is simple, highly
efficient and flexible enough to support both Multi-master and
Master-slave replication operations to meet the needs of both the
Internet and enterprise environments.
4. Applicability Statement
TBD
5. Replication Model
5.1 LDAP Replication MUST be allowed to span different vendors
directory services in order to provide interoperability.
5.2 All replicas MUST eventually be updated with the changed
information, specified by the replication policy.
5.3 Replication schedules MUST be dynamic to allow for periodic
replication, with the replication period determined by
administrator of the replicated system.
5.4 Replication Model SHALL enable replication cycle to initiated
based in the number of pending changes.
5.5 The replication model SHOULD allow for initiation of
replication cycle for any replica that may have just come back
online or was unavailable previously.
5.6 The replication model MUST support the both master-slave and
multi-master replication topologies.
Weiser & Stokes 13 October 1998 [Page 4]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
5.7 All replicated information between the master database and its
replica databases SHALL be identical including all no user
modify operational attributes such as time stamps. Note this
does not imply that the entire database is identical from
replica to replica, but that the subset of data, chosen to
replicate is identical from replica to replica.
5.8 Distributed multi-vendor environment, LDAP replication SHALL
NOT ensure all copies of the replicated information be
complete copies of the replicated object.
5.9 Replication MUST allow Definition content of replicated
information.
5.10 LDAP replication SHALL encompass common schema objects and
attributes, access control and name spaces.
5.11 Sub tree Replication SHALL be defined to allow for greater
flexibility replication topologies of the DIT as discussed in
X.525 section 7.2 [X.525].
5.12 A propagation schedule SHALL be defined and SHOULD be tunable
within Predetermined replication agreement.
5.13 Replication of critical values SHALL be synchronized with
priority over non critical values, an example of a critical
value might be a password and or certificate value which
maybe considered critical.
5.14 Currently X.525 DISP [X.525] discusses this as a shadowing
agreement including such information as unit of replication,
update mode, and access point defining many of the policies
between the master and a replica. The use of predetermined
replication agreements between the directory replicas MUST be
addressed to provide proper knowledge of access requirements
and credentials between the synchronizing directories.
5.15 Due to the acceptance and usage of the Internet, and the
requirement that LDAP replication be available across
disparate vendors directory services, LDAP replication MUST
provide scalability for both enterprise and internet
environments.
5.16 The replication model MUST define deterministic policy such
that replication cycle startup time conflicts between two or
more competing master replicas may be resolved
programmatically. An Example might be automatic submission and
rescheduling by one of the masters. In such a case, these
replication "conflicts" SHALL be resolved by the replication
policy.
Weiser & Stokes 13 October 1998 [Page 5]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
5.17 Replication SHALL be allowed to any LDAP server available on
the network; provided appropriate security authorization is
granted.
6. Replication Protocol
6.1 The act of replication MUST have minimal impact on both the
system and network performance.
6.2 The replica synchronization MUST be handled in such a manner
as to not saturate network with repetitive entry replication
from multiple synchronization providers points.
6.3 Replication SHALL only be allowed after the authentication and
verification of authorization of both the replica and the
source directory.
6.4 The transport for LDAP synchronization MUST allow for the
integrity and confidentiality of each replicated server.
6.5 Replicated data MUST be transferred in a secure manner.
6.6 Replication protocol MUST provide for recovery and
rescheduling of a replication cycle due to update conflict and
or loss of conncetion
6.7 LDAP replication MUST allow for full update to facilitate
replica initialization and reset loading utilizing a
standardized LDIF [LDIF] format.
6.8 The normal means of synchronizing replicas SHALL be performed
through incremental synchronization and in accordance with the
scheduling policies.
6.9 The replication Standard SHOULD NOT limit the size of a
replica. The unit of replication is defined to be the naming
context. Incremental replication SHOULD be allowed to attempt
to keep the amount of data replicated to a minimum.
6.10 Must allow updates to multiple replicas
6.11 The replication protocol MUST allow either a master or replica
to initiate the replication process.
6.12 Additionally the initiator MUST be allowed to determine
whether it will become a consumer or supplier during the
synchronization startup process. This would allow a replica to
be periodically connected and synchronized from remote sites
at the local administrator's discretion.
Weiser & Stokes 13 October 1998 [Page 6]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
6.13 Multiple LDAP changes, to a single server, SHOULD be allowed
to be treated as single atomic unit of work propagated during
replication.
6.14 An LDAP Replication Standard SHOULD NOT limit the transaction
rate of a replication session.
6.15 Entry change information SHALL be purged upon completion of a
synchronization cycle where all replica members have been
synchronized with the master(s).
7. Replication Predetermined Agreements
7.1 The Replication Protocol documents MUST define a standard
schema for representing replication agreements, and MUST
define the semantics associated with modifying the attributes
of replication agreements. The documents MUST also define a
standard method for determining the location of these
agreements.
7.2 The Replication Protocol documents MUST define a standard
schema for publishing state information about a given replica,
and MUST define a standard method for determining the location
of this information. This state information MUST include the
ID of the last update propagated to the replica. The format of
this ID is to be determined.
7.3 Location independent management point SHALL be defined to
provide authorized administrators with well known access to
the replication policies, regardless of network location.
7.4 Policies for the LDAP replication shall be defined in such a
manner as to allow programmatic representation; these policies
SHALL be kept as replica attributes or as entries of the
predetermined agreement and propagated during replication.
7.5 Replication agreements SHALL be accessible, via LDAP, to all
servers containing replicated information.
8. Administration and Management Considerations
8.1 Replication policies SHALL allow replication of changed
information to be postponed to a more convenient period ,
8.2 Allowance for non scheduled replication of a replica SHALL be
provided upon request such that the replica server has been
down or unconnected for a period of time.
8.3 Each copy of a replica MUST maintain audit history of who it
has replicated with and who has replicated with it.
Weiser & Stokes 13 October 1998 [Page 7]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
8.4 A replica MAY store the conflicted versions of the replicated
object to allow optional human review and intervention.
8.5 Access to replication predetermined agreements, topologies,
and policies attributes MUST be provided through LDAP access.
8.6 The capability to check the differences between two replicas
be of the same information SHOULD be provided for.
8.7 The capability to view the current state and replication
history of each replicated copy in the replication topology,
from a single server in the topology.
8.8 The ability to view replication conflicts, and override the
resolution derived by the replication policy SHALL be
provided.
9. Other for furhter discussion or the garbage heap
9.1 It is not realistic to assume that all vendors have
cooperating schemas, but it is required that different vendors
schemas allow replication from diverse schemas. and MAY define
a model whereby divergent schemas can replicate non-common or
extended attributes for common LDAP objects.
9.2 Propagation behavior defines the general behavior of the
actual synchronization process between a consumer and a
provider of replication information.
9.3 Entry Identifiers SHALL be defined Ref Christopher Apple.
9.4 Replica convergence and resurections of attributes and
objects; since( tombestones, Obituaries, deathwarrants,
graveyards) are used Ill add one more ZOMMBIES. RFW
10. Acknowledgement
This document is based on input from IETF members interested in LDAP
replication
11. References
[RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access
Protocol (v3), Standards Track , December 1997 . Availiable as RFC2251
[RFC2119] S.Bradner, " Key words for use in RFCs to indicate
Requirement Levels", RFC 2119.
[LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)", Internet
draft, draft-ietf-asid-ldif-00.txt, November 1996.
Weiser & Stokes 13 October 1998 [Page 8]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
[Changelog] Gordon Good, "Definitions of an Object Class to Hold LDAP
Change records", Internet Draft, draft-ietf-asid-changelog-00.txt,
November 1996.
[X.525] "Information Technology - Open Systems Interconnection- The
Directory: Replication", ITU-T Recommendation X.525 and ISO/IEC
International Standard 9594-9, November 1993.
12. Author's Address
Russel F. Weiser
Novell Inc.
122 East 1700 South
Provo, Utah 84606
USA
E-mail: Rweiser@novell.com
Telephone: +1-801-861-7808
Fax +1-801-861-2292
Ellen J. Stokes
IBM
11400 Burnet Rd.
Austin, Texas 78758
USA
E-mail: stokes@austin.ibm.com
Telephone: +1-512-838-3725
Fax: +1-512-838-0156
Weiser & Stokes 13 October 1998 [Page 9]