IETF-ASID Russel Weiser Informational Draft Novell Inc. Ellen Stokes IBM Bob Huston Iris Assoc. 17 Nov 1997 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 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]