One document matched: draft-weiser-replica-req-00.txt
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-00.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. General Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Replication policy . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Propagation behavior . . . . . . . . . . . . . . . . . . 7
4.1.2 Scheduling policies . . . . . . . . . . . . . . . . . . . 7
4.2 Predetermined Replication Agreements . . . . . . . . . . . . . 8
4.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 LDAP Access . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 Administration Utility Requirements . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. 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.
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.
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.
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.
Weiser & Stokes 13 October 1998 [Page 3]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
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. General Requirements
The following requirements are in no priority order.
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
convenient period, or done at user request. It is not required to
have all replica copies on the network available at replication
time. In a distributed enterprise environment, it is unrealistic to
assume that all copies of a replica will be available for update at
all times. Under this circumstance, when a previously unavailable
replica copy comes on line, it SHOULD initiate replication with
another replicated copy such that its local replicated information
is brought up to date.
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.
Weiser & Stokes 13 October 1998 [Page 4]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
Location independent 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.
Multi-master and Master-Slave - Support for both multi-master and
master-slave environments should be a driving requirement. Since
master-slave is considered a proper subset of multi-master, both
these models MUST be supported.
Flexibility - LDAP replication MUST allow for both total and
incremental update of objects. In addition, updates MUST be allowed
to multiple replicas to enhance distributed performance and
reliability.
Synchronization of LDAP replicas MUST allow either master 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.
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.
Distributed multi-vendor environment, LDAP replication 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.
Weiser & Stokes 13 October 1998 [Page 5]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
SubTree Replication - 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].
4.1 Replication policy
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
discussed in section 4.2 to be propagated during replication.
4.1.1 Propagation behavior
Propagation behavior defines the general behavior of the actual
synchronization process between a consumer and a provider of
replication information.
1. Replication SHALL only be allowed after the 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 4.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
synchronization cycle where all replica members have been synchronized
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.
4.1.2 Scheduling policies
Weiser & Stokes 13 October 1998 [Page 6]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
The scheduling policies allow administration and tuning of the
convergence 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
replication cycle.
2. Immediate replication of critical values in secs/mins such as user
password changed SHALL be supported.
3. 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.
4.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.
4.3 Scalability
In order to support both enterprise and Internet environments,
replication 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 of which may be replicated. The replication
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 numbers transactions per second.
Weiser & Stokes 13 October 1998 [Page 7]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
4. Scale to global Internet, or not. 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 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
replicas, where simultaneous is defined to be a period between
replications. In such a case, these replication "conflicts" SHALL be
resolved by the replication policy. A replica MAY store the conflicted
versions of the replicated object to allow optional human review and
intervention.
6. Arbitrary replication topology. Replication SHALL be allowed to any
LDAP server available on the network.
7. Arbitrary Management topologies
4.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 context MUST provide replication policies via LDAP.
4.5 Administration Utility Requirements
Administration of replicated servers SHALL be defined in such a manner
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. The ability to view replication conflicts, and override the
resolution derived by the replication policy.
5. Acknowledgements
This document is based on input from IETF members interested in LDAP
replication
Weiser & Stokes 13 October 1998 [Page 8]
INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998
6. 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.
[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.
7. 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-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
Weiser & Stokes 13 October 1998 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 05:42:09 |