[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

IETF-ASID                                                  Russel Weiser
Informational Draft                                        Novell Inc.
                                                           Ellen Stokes
                                                           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).


   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

   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

   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

   1. Replication SHALL only be allowed after the proper  authentication
   and  verification of authorization of both the replica and the source

   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

   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

   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-

   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

5.  Bibliography

   [LDAPv3] - M. Wahl, T. Howes, S. Kille "Lightweight Directory  Access
   Protocol  (v3),  Internet Draft, draft-ietf-asid-ldapv3-04.txt  March

   [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

     E-mail: Rweiser@novell.com
     Telephone: +1-801-861-7808
     Fax +1-801-861-7808

     Ellen J. Stokes
     11400 Burnet Rd.
     Austin, Texas  78758

     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

     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]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/