INTERNET-DRAFT Russel Weiser Informational Draft Novell, Inc. Expires 13 October 1998 Ellen Stokes IBM 13 April 1998 LDAP Replication Requirements 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]