IETF-ASID Russel Weiser
Informational Draft Novell Inc.
Ellen Stokes
IBM
Bob Huston
Iris Assoc.
17 Nov 1997
LDAP Replication Requirements
<draft-ietf-asid-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 cite them other than as " work in progress." To learn
the current status of any Internet-Draft, please check the "lid-
abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document discusses the fundamental requirements for replication
of the LDAPv3 [LDAPv3] protocol. It is intended to be a gathering
place for general replication requirements needed to provide
interoperability between informational directories.
1. Introduction
The ability to distribute directory information throughout the net-
work 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
Weiser, Stokes, Huston [Page 1]
INTERNET-DRAFT LDAP Replication Requirements
enterprise and Internet. Currently LDAP does not define a replica-
tion mechanism and only generally mentions LDAP shadow servers (see
[LDAPv3] and [Changelog]) in passing. The requirements for replica-
tion are critical to the successful deployment and acceptance of LDAP
in the market place.
2. Objectives
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.
Synchronization - The harmonization of dissimilar directories and
namespaces, whereby it is guarenteed that at all times, all copies of
the information will be identicle.
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.
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.
The major objectives are to provide a simple, highly efficient and
high performing replication method for LDAP while also providing the
appropriate flexibility to meet the needs of both the Internet and
enterprise environments.
Simple - Replication MUST be simple to configure and maintain.
Efficient - The act of replication MUST have minimal impact on
both the system and network performance and throughput. In order
to achieve this efficiency, replication policies SHALL allow
replication of changed information to be postponed to a more
Weiser, Stokes, Huston [Page 2]
INTERNET-DRAFT LDAP Replication Requirements
conveniant period, or done at user request.
Reliable - All replicated copies MUST eventually be updated with
the changed information, specified by the replication policy.
Provides Interoperability between vendors - Replicas MUST be
allowed to span different vendors directory services. Without such
vendor interoperability, internet based directory services will
not be feasible.
Security of data, connections and replication process - Replicated
data MUST be transferred in a secure manner, where both endpoints
in the communication have identified and authenticated themselves
to the other server.
Robustness - The ability to deal with differences in directory
services schemas in a cross vendor enterprise. The ability to
recover when a replica server is unavailable during replication.
Location independant manageability - A replica administrator MUST
be allowed access to the replication policies, regardless of
network location.
Auditability - Each copy of a replica MUST maintain a history of
who it has replicated with and who has replicated with it.
Ability to Set Change Metrics - Replication schedules MUST be
dynamic to allow for periodic replication, with the replication
period determined by administrator of the replicated system. In
addition, replication policy must be globally available to any
authorized administrator from anyplace on the network.
Replication Policy Mechanisms - Policies to allow both schedule
and content of replicated information MUST be allowed. Policies
SHALL allow replication to be schedule both on a periodic basis,
as well as on a number of changes basis.
3. General Requirements
The following requirements are in no priority order.
Simple - Replication MUST be simple to configure and maintain.
Due to the nature of the Internet and enterprise environments, the
flexibility of a LDAP replication should be of the upmost importance
Replication must allow for both total and incremental update of
objects. In addition, updates MUST be allowed to multiple replicas to
Weiser, Stokes, Huston [Page 3]
INTERNET-DRAFT LDAP Replication Requirements
enhance distributed performance.
Support for both multi-master and master/slave environments should be
a driving requirement. Since master/slave is considered a proper sub-
set of multi-master, both these models SHALL be supported.
Additionally synchronization of LDAP replicas should allow either a
master and or replica to initiate the replication process and allow
the initiator to determine whether it will become a consumer and or
supplier during the synchronization process. This would allow a
replica to be periodically connected and synchronized from remote
sites at the local administrator's discretion.
Another driving force or general requirement should be that all
replicated information between the master database and its replica
databases SHALL be identical including all no user modify operational
attributes such as timestamps.
It is not required to have all replica copies on the network avail-
able at replication time. In a distributed enterprise environment, it
is unrealistic to assume that all copies of a replica will be avail-
able for update at all times. Under this circumstance, when a previ-
ously unavailable replica copy comes on line, it SHOULD initiate
replication with another replicated copy such that its local repli-
cated information is brought up to date.
In addition, in a distributed multi-vendor environment, LDAP replica-
tion SHALL NOT ensure all copies of the replicated information be
complete copies of the replicated object. 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. LDAP replication SHALL encompass common schema objects and
attributes, and MAY define a model whereby divergent schemas can
replicate non-common or extended attributes for common LDAP objects.
Support for SubTree Replication SHALL be defined to allow for greater
flexibility replication toplologies of the DIT as discussed in X.525
section 7.2 [X.525].
Along with the above is the need for replication policies that govern
the behavior of the replicas and the synchronization process and are
briefly discussed below in sections 3.1.
3.1. Replication policy definitions
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 predeter- mined agreement
discussed in section 3.2 to be propagated during replication.
Weiser, Stokes, Huston [Page 4]
INTERNET-DRAFT LDAP Replication Requirements
3.1.1. Propagation behavior
Propagation behavior defines the general behavior of the actual syn-
chronization process between a consumer and a provider of replication
information.
1. Replication SHALL only be allowed after the proper authentication
and verification of authorization of both the replica and the source
directory.
2. The transport for LDAP synchronization MUST allow for the
integrity and confidentiality of each replicated server.
3. The replica synchronization MUST be handled in such a manner as to
not saturate network with repetitive entry replication from multiple
synchronization providers points.
4. Full copy replication SHOULD be supported for reset and initial
loading of a replica using the LDIF [LDIF].
5. The normal means of synchronizing replicas SHALL be performed
through incremental synchronization and in accordance with the
scheduling policies of section 3.1.2.
6. Multiple LDAP changes, to a single server, SHOULD be allowed to be
treated as single atomic unit of work propagated during replication.
7. Entry change information shall be purged upon completion of a syn-
chronization cycle where all replica members have been syn- chronized
with the master(s).
8. Replication policies SHOULD contain clauses to account for the
instance of a replica being unavailable at the scheduled update time.
3.1.2. Scheduling policies
The scheduling policies allow administration and tuning of the con-
vergence of replicas. These administrator controlled policies give
replication the flexibility to be adapted to the local environment.
1. A propagation schedule SHALL be defined and SHOULD be tunable such
that every X hours and or N changes will automatically begin a repli-
cation cycle.
2. Immediate replication of critical values in secs/mins such as user
password changed SHALL be supported.
Weiser, Stokes, Huston [Page 5]
INTERNET-DRAFT LDAP Replication Requirements
3. Allowance for non scheduled replication of replica upon request
such that the replica server has been down or unconnected for a
period of time.
3.2. Predetermined Replication Agreements
The use of predetermined replication agreements between the master
directories and replica directories MUST be addressed to provide
proper knowledge of access requirements and credentials between the
synchronizing directories.
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.
Replication agreements SHOULD be accessible, via LDAP, to all servers
containing replicated information.
3.3. Scalability
In order to support both enterprise and internet environments, repli-
cation must be scalable. Scalability is comprised of the following
factors.
1. Real time Vs. non-real-time operations.
2. Large amounts of replicated data. The unit of replication is
defined to be the naming context. This naming context may consist of
large amounts of data, all or which may be replicated. The replica-
tion mechanism must account for any amount of data to be replicated.
Incremental replication must be allowed to attempt to keep the amount
of data replicated to a minimum.
3. Large amounts transactions per second.
4. Scale to global internet, or not. Due to the acceptance and usage
of the internet, and the requirement that LDAP replication be avail-
able across disparate vendors directory services, LDAP replication
must scale to the internet level, but also must function at the
enterprise level.
5. Large numbers of replicas, ie distributivity. A policy must be
defined to account for simultaneous updates to multiple master
Weiser, Stokes, Huston [Page 6]
INTERNET-DRAFT LDAP Replication Requirements
replicas, where simultaneous is defined to be a period between repli-
cations.
6. Arbitrary replication topology
7. Arbitrary Management topologies
3.4. LDAP Access
Access to replication topologies and policies, via LDAP is a must. In
order to replicate across different vendors directory services, each
naming contexts replication policies must be available via LDAP.
3.5. Administration Utility Requirements
Administration of replicated servers shall be defined in such a man-
ner to include:
1. The capability to check the differences between two replicas of
the same information.
2. The capability to view the replication topology from a single
server in the topology.
3. 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.
4. Acknowledgements
This document is based on input from IETF members interested in LDAP
replication
5. Bibliography
[LDAPv3] - M. Wahl, T. Howes, S. Kille "Lightweight Directory Access
Protocol (v3), Internet Draft, draft-ietf-asid-ldapv3-04.txt March
1997.
[LDIF] -_ Gordon Good, "The LDAP Data Interchange Format (LDIF)",
Internet draft, draft-ietf-asid-ldif-00.txt, November 1996.
[Changelog] - Gordon Good, "Definitions of an Object Class to Hold
LDAP Change records", Internet Draft, draft-ietf-asid-
changelog-00.txt, November 1996.
Weiser, Stokes, Huston [Page 7]
INTERNET-DRAFT LDAP Replication Requirements
[X.525] - "Information Technology - Open Systems Interconnection- The
Directory: Replication", ITU-T Recommendation X.525 and ISO/IEC
International Standard 9594-9, November 1993.
6. Author(s) Addres
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-7808
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
Bob Huston
Iris Associates
5 Technology Park.
Westford, MA 01886
USA
E-mail: bhuston@iris.com
Telephone: +1-978-392-5203
Fax: +1-978-692-7365
Weiser, Stokes, Huston [Page 8]
INTERNET-DRAFT LDAP Replication Requirements
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. General Requirements . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Replication policy . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Propagation behavior . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Scheduling policies . . . . . . . . . . . . . . . . . . . . 5
3.2. Predetermined Replication Agreements . . . . . . . . . . . . 6
3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. LDAP access . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Administration Utility Requirements . . . . . . . . . . . . . 7
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Author(s) Address . . . . . . . . . . . . . . . . . . . . . . . 8
Weiser, Stokes, Huston [Page 1]
