Internet DRAFT - draft-weiser-replica-req

draft-weiser-replica-req








 

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-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 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. Applicability Statement  . . . . . . . . . . . . . . . . . . . . .  5

5. Replication Model  . . . . . . . . . . . . . . . . . . . . . . . .  5

6. Replication Protocol . . . . . . . . . . . . . . . . . . . . . . .  7

7. Replication Predetermined Agreements . . . . . . . . . . . . . . .  8

8. Administration and Management Considerations . . . . . . . . . . .  8

9. Other for furhter discussion or the garbage heap . . . . . . . . .  9

10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . .  9

11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9

12. 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. that which is done between either
     homogeneous implementations across heterogeneous platforms
     (operating systems) or heterogeneous implementations supporting
     identical replication across heterogeneous platforms (operating
     systems).  No mapping mechanisms are required here.

     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.
     that which happens between heterogeneous directory servers
     onheterogeneous platforms (operating systems).  The different
     directory server implementations do not have to provide an LDAP
     interface.  One could certainly define a wire protocol.  The
     mapping of data means mapping of attributes.  For example, in one
     system, the attribute is full name, in the other it is common name 



     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.

Weiser & Stokes             13 October 1998                    [Page 3]



INTERNET-DRAFT      LDAP V3 Replication Requirements      13 April 1998



     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. 

     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. Applicability Statement
 
     TBD


5. Replication Model 

     5.1  LDAP Replication MUST  be allowed to span different vendors
          directory services in order to provide interoperability.

     5.2  All replicas MUST eventually be updated with the changed
          information, specified by the replication policy.

     5.3  Replication schedules MUST be dynamic to allow for periodic
          replication, with the replication period determined by
          administrator of the replicated system.

     5.4  Replication Model SHALL enable replication cycle to initiated
          based in the number of pending changes.

     5.5  The replication model SHOULD allow for initiation of
          replication cycle for any replica that may have just come back
          online or was unavailable previously.
 
     5.6  The replication model MUST support the both master-slave and
          multi-master replication topologies. 



Weiser & Stokes             13 October 1998                    [Page 4]



INTERNET-DRAFT      LDAP V3 Replication Requirements      13 April 1998


     5.7  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. 

     5.8  Distributed multi-vendor environment, LDAP replication SHALL
          NOT ensure all copies of the replicated information be
          complete copies of the replicated object.

     5.9  Replication MUST allow Definition content of replicated
          information. 

     5.10 LDAP replication SHALL encompass common schema objects and
          attributes, access control and name spaces.

     5.11 Sub tree Replication SHALL be defined to allow for greater
          flexibility replication topologies of the DIT as discussed in
          X.525 section 7.2 [X.525].

     5.12 A propagation schedule SHALL be defined and SHOULD be tunable
          within Predetermined replication agreement.

     5.13 Replication of critical values SHALL be synchronized with
          priority  over non critical values, an example of a critical
          value might be a  password and or certificate value which
          maybe considered critical.

     5.14 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. The use of predetermined
          replication agreements between the directory replicas MUST be
          addressed to provide proper knowledge of access requirements
          and credentials between the synchronizing directories.

     5.15 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
          provide scalability for both enterprise and internet
          environments. 

     5.16 The replication model MUST define deterministic policy such
          that replication cycle startup time conflicts between two or
          more competing master replicas may be resolved
          programmatically. An Example might be automatic submission and
          rescheduling by one of the masters.  In such a case, these
          replication "conflicts" SHALL be resolved by the replication
          policy.



Weiser & Stokes             13 October 1998                    [Page 5]



INTERNET-DRAFT      LDAP V3 Replication Requirements      13 April 1998


     5.17 Replication SHALL be allowed to any LDAP server available on
          the network; provided appropriate security authorization is
          granted. 


6. Replication Protocol

     6.1  The act of replication MUST have minimal impact on both the
          system and network performance. 

     6.2  The replica synchronization MUST be handled in such a manner
          as to not saturate network with repetitive entry replication
          from multiple synchronization providers points.
 
     6.3  Replication SHALL only be allowed after the authentication and
          verification of authorization of both the replica and the
          source directory.

     6.4  The transport for LDAP synchronization MUST allow for the
          integrity and confidentiality of each replicated server.

     6.5  Replicated data MUST be transferred in a secure manner.

     6.6  Replication protocol MUST provide for recovery and
          rescheduling of a replication cycle due to update conflict and
          or loss of conncetion 

     6.7  LDAP replication MUST allow for full update to facilitate
          replica initialization and reset loading utilizing a
          standardized LDIF [LDIF] format.

     6.8  The normal means of synchronizing replicas SHALL be performed
          through incremental synchronization and in accordance with the
          scheduling policies.

     6.9  The replication Standard SHOULD NOT limit the size of a
          replica. The unit of replication is defined to be the naming
          context. Incremental replication SHOULD be allowed to attempt
          to keep the amount of data replicated to a minimum.

     6.10 Must allow updates to  multiple replicas

     6.11 The replication protocol MUST allow either a master or replica
          to initiate the replication process.

     6.12 Additionally the initiator MUST be allowed to determine
          whether it will become a consumer or supplier during the
          synchronization startup process. This would allow a replica to
          be periodically connected and synchronized from remote sites
          at the local administrator's discretion.



Weiser & Stokes             13 October 1998                    [Page 6]



INTERNET-DRAFT      LDAP V3 Replication Requirements      13 April 1998


     6.13 Multiple LDAP changes, to a single server, SHOULD be allowed
          to be treated as single atomic unit of work propagated during
          replication. 

     6.14 An LDAP Replication Standard SHOULD NOT limit the transaction
          rate of a replication session.

     6.15 Entry change information SHALL be purged upon completion of a
          synchronization cycle where all replica members have been
          synchronized with the master(s).

7. Replication Predetermined Agreements

     7.1  The Replication Protocol documents MUST define a standard
          schema for representing replication agreements, and MUST
          define the semantics associated with modifying the attributes
          of replication agreements. The documents MUST also define a
          standard method for determining the location of these
          agreements.

     7.2  The Replication Protocol documents MUST define a standard
          schema for publishing state information about a given replica,
          and MUST define a standard method for determining the location
          of this information. This state information MUST include the
          ID of the last update propagated to the replica. The format of
          this ID is to be determined. 

     7.3  Location independent management point SHALL be defined to
          provide authorized administrators with well known access to
          the replication policies, regardless of network location.

     7.4  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 and propagated during replication.

     7.5  Replication agreements SHALL be accessible, via LDAP, to all
          servers containing replicated information.


8. Administration and Management Considerations

     8.1  Replication policies SHALL allow replication of changed
          information to be postponed to a more convenient period ,

     8.2  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. 

     8.3  Each copy of a replica MUST maintain audit history of who it
          has replicated with and who has replicated with it.


Weiser & Stokes             13 October 1998                    [Page 7]



INTERNET-DRAFT      LDAP V3 Replication Requirements      13 April 1998


     8.4  A replica MAY store the conflicted versions of the replicated
          object to allow optional human review and intervention.

     8.5  Access to replication predetermined agreements, topologies,
          and policies attributes MUST be provided through LDAP access.

     8.6  The capability to check the differences between two replicas
          be of the same information SHOULD be provided for.
  
     8.7  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.
 
     8.8  The ability to view replication conflicts, and override the
          resolution derived by the replication policy SHALL be
          provided.

9. Other for furhter discussion or the garbage heap

     9.1  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. and MAY define
          a model whereby divergent schemas can replicate non-common or
          extended attributes for common LDAP objects.

     9.2  Propagation behavior defines the general behavior of the
          actual synchronization process between a consumer and a
          provider of replication information.

     9.3 Entry Identifiers SHALL be defined Ref Christopher Apple.

     9.4  Replica convergence and resurections of attributes and
          objects; since( tombestones, Obituaries, deathwarrants,
          graveyards) are used Iíll add one more ZOMMBIES. RFW


10. Acknowledgement 

This document is based on input from IETF members interested in LDAP
replication 

11. 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.


Weiser & Stokes             13 October 1998                    [Page 8]



INTERNET-DRAFT      LDAP V3 Replication Requirements      13 April 1998


[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.

12. 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-2292


     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]