One document matched: draft-ietf-ldup-protocol-04.txt
Differences from draft-ietf-ldup-protocol-03.txt
LDUP Replication Update Protocol John McMeeking
Internet-Draft IBM Corporation
Intended Category: Standards Track
Expires: September 2003 March 2003
The LDUP Replication Update Protocol
<draft-ietf-ldup-protocol-04.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
2. Abstract
The protocol described in this document is designed to allow one
LDAP server to replicate its directory content to another LDAP
server. The protocol is designed to be used in a replication
configuration where multiple updateable servers are present.
Provisions are made in the protocol to carry information that allows
the server receiving updates to apply a total ordering to all
updates in the replicated system. This total ordering allows all
replicas to correctly resolve conflicts that arise when LDAP clients
submit changes to different servers that later replicate to one
another.
All protocol elements described here are LDAPv3 extended operations
and controls. LDAPv3 is described in RFC 2251 [LDAPv3]. Some LDAPv3
extended operations and controls described here are LDAPv3 extended
operations used to group related operations. The protocol elements
used for grouping are described in LDAPv3: Grouping of Related
Operations [GROUPING].
Certain terms used in this document are defined in the document
"LDAP Replication Architecture" [ARCHITECTURE].
McMeeking Expires September 2003 [Page 1]
Internet Draft LDUP Replication March 2003
Update Protocol
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document
are to be interpreted as described in RFC 2119 [KEYWORDS].
McMeeking Expires September 2003 [Page 2]
Internet Draft LDUP Replication March 2003
Update Protocol
3. Table of Contents
1. Status of this Memo...............................................1
2. Abstract..........................................................1
3. Table of Contents.................................................3
4. Overview of Protocol..............................................4
5. High-level Description of Protocol Flow...........................4
5.1. Supplier-initiated replication protocol........................4
5.2. Consumer-initiated replication protocol........................6
6. Replication protocol element definitions..........................6
6.1. createGroupingRequest Extended Operation.......................6
6.2. createGroupingResponse Extended Operation......................8
6.3. ReplicationUpdate Extended Operation...........................9
6.3.1. UniqueIdentifier.............................................10
6.3.2. ReplicationPrimitive.........................................10
6.3.2.1. AddEntryPrimitive..........................................11
6.3.2.2. MoveEntryPrimitive.........................................11
6.3.2.3. RenameEntryPrimitive.......................................11
6.3.2.4. RemoveEntryPrimitive.......................................12
6.3.2.5. AddAttributeValuePrimitive.................................12
6.3.2.6. RemoveAttributeValuePrimitive..............................12
6.3.2.7. RemoveAttributePrimitive...................................13
6.4. endGroupingRequest Extended Operation.........................13
6.5. endGroupingResponse Extended Operation........................14
6.6. ReplicationUpdateResponse Extended Operation..................14
7. Semantics of Full and Incremental Update protocols...............15
8. Semantics of the LDAP Replication Grouping Type..................16
9. Summary of response codes........................................16
10. Security Considerations........................................17
11. References.....................................................17
12. Author's Addresses.............................................18
13. Appendix A - Complete ASN.1 Definition.........................18
14. Copyright Information..........................................18
McMeeking Expires September 2003 [Page 3]
Internet Draft LDUP Replication March 2003
Update Protocol
4. Overview of Protocol
The LDAP Replication Architecture [ARCHITECTURE] describes the
overall approach used in ensuring consistency of multiple updateable
replicas of directory content. The protocol described in this
document implements the approach described in that document.
LDAP Version 3 extended operations are used to carry replicated
content from one server to another. The extended operations defined
in this document are used to initiate and end a replication session,
and to exchange updates. These updates carry with them information
that allows the receiving server to apply a total ordering to all of
the updates in a replicated system. All servers that receive
replication updates apply a consistent set of update resolution
policies, described in [URP]. You must understand URP to
process/send and receive/process the updates correctly. What you
send may depend on whether your implementation is state-based or
log-based; what you receive is independent of whether you are state-
based or log-based. Consistent application of the update resolution
policies ensures that all replicas eventually converge and contain
the same directory data. The protocol depends upon elements of the
information model set forth in [INFOMOD] and [LCUP]. In particular,
the notion of a universally unique identifier (UUID) to identify a
particular entry is used in elements of the protocol.
The protocol is intended to meet the requirements set forth in
[REQ].
5. High-level Description of Protocol Flow
The following section provides a high-level overview of the
replication protocol. Throughout this section, the supplier server
is indicated by the letter "S" and the consumer server by the letter
"C". The construct "S -> C" indicates that the supplier is sending
an LDAPv3 operation to the consumer, and "C -> S" indicates that the
consumer is sending an LDAPv3 operation to the supplier.
5.1. Supplier-initiated replication protocol
S -> C: LDAP bind operation (identity and credentials used are
implementation-defined)
C -> S: Bind response
S -> C: createGroupingRequest LDAPv3 extended operation. The
parameters are:
1) The LDUP Replication grouping type OID.
2) Root of replicated area (unambiguously identifies
the replicated area)
3) Supplier's replicaID
McMeeking Expires September 2003 [Page 4]
Internet Draft LDUP Replication March 2003
Update Protocol
4) OID of replication protocol to be used (this
document defines IETF-LDUP incremental and IETF-LDUP
total update protocols)
5) The protocol initiation type - Supplier-Initiated in
this case.
6) A table of UUID to replicaID mappings.
C -> S: createGroupingResponse LDAPv3 extended operation. The
parameters are:
1) A groupCookie that represents the LDUP Replication
group just created.
2) A response code (see section 9)
3) An optional update vector that is included if and
only if the response code is REPL_SUCCESS.
S -> C: The supplier may send zero or more ReplicationUpdate
LDAPv3 extended operations. The parameters are:
1) The UUID of the entry being updated
2) One or more Replication Primitives (The supplier may
send as many of these as required to bring the consumer
up to date)
3) A groupingControl containing the groupCookie for
this LDUP Replication group.
C -> S: At any time, the consumer may send an unsolicited
ReplicationUpdateResponse LDAPv3 extended operation. The
parameters are:
1) An optional update vector. If sent, this indicates
that the consumer has committed all updates whose CSNs
are covered by the transmitted update vector [see
glossary for a definition of "covered by"].
2) An optional AbortUpdate Boolean flag. If a supplier
receives a ReplicationUpdateResponse from a consumer
with the AbortUpdate flag set to true, the supplier
server MUST immediately cease sending updates and
terminate its connection to the consumer.
3) A groupingControl containing the groupCookie for
this LDUP Replication group.
S -> C: After all required updates have been sent to the
consumer, the supplier sends an endGroupingRequest LDAPv3
extended operation. The parameters are:
1) A groupCookie for this LDUP Replication group
C -> S: The consumer responds by sending an endGroupingResponse
LDAPv3 extended operation.
McMeeking Expires September 2003 [Page 5]
Internet Draft LDUP Replication March 2003
Update Protocol
S -> C: The supplier then sends an unbind operation and both
sides close the connection.
5.2. Consumer-initiated replication protocol
C -> S: LDAP bind operation (identity and credentials used are
implementation-defined)
S -> C: Bind response
C -> S: createGroupingRequest LDAPv3 extended operation. The
parameters are:
1) The LDUP replication grouping type OID
2) Root of replicated area (unambiguously identifies
the replicated area)
3) Consumer's replicaID
4) OID of replication protocol to be used (this
document defines IETF-LDUP incremental and IETF-LDUP
total update protocols)
5) The protocol initiation type - Consumer-Initiated in
this case
S -> C: createGroupingResponse LDAPv3 extended operation. The
parameters are:
1) A groupCookie that represents the LDUP replication
group just created.
2) A response code (see section 9)
C -> S: The consumer then sends an unbind operation and both
sides close the connection.
The supplier server then connects to the consumer, beginning a
Supplier- Initiated protocol session (see section 5.1).
6. Replication protocol element definitions
The following sub-sections define the individual protocol elements
that make up the update replication protocol. Portions of the ASN.1
use ASN.1 types defined in [LDAPv3].
6.1. createGroupingRequest Extended Operation
The creation of an LDAP Replication grouping type by a replication
initiator indicates that a replication session should commence. An
LDUP Replication grouping type is created by sending a
createGroupingRequest extended operation with a createGroupType OID
value specifying the LDAP Replication grouping type. For supplier-
initiated replication, the supplier sends this extended operation to
the replication consumer to indicate that a replication session
McMeeking Expires September 2003 [Page 6]
Internet Draft LDUP Replication March 2003
Update Protocol
should commence. For consumer-initiated replication, the consumer
sends this extended operation to the replication supplier to
indicate that the supplier should initiate a replication session to
the consumer as soon as possible.
The createGroupingRequest extended operation is defined in section
3.2.1 of [GROUPING].
The createGroupType of the createGroupingRequestValue must be [OID
to be assigned]. This OID represents the LDAP Replication grouping
type.
The createGroupValue of the createGroupingRequestValue must be set
to the BER-encoding of the following:
createGroupValue ::= createReplGroupReqValue
createReplGroupReqValue ::= SEQUENCE {
replicaRoot LDAPDN,
replicaID LDAPString,
replicationProtocolOID LDAPOID,
replicationInitiator ENUMERATED
{
supplier (0),
consumer (1)
}
replicaIDTable SEQUENCE OPTIONAL {
tableLength INTEGER
table SEQUENCE OF SEQUENCE {
replicaID LDAPString,
replicaUUID LDAPString
}
}
}
The parameters in the createGroupValue of the
createGroupingRequestValue are:
- replicaRoot: the distinguished name of the entry at the top of
the replicated area, and uniquely identifies the unit of
replication.
- replicaID: the replica identifier of the replication initiator.
Each replica of a given replicated area is identified by a
unique identifier, described in [ARCHITECTURE] and [LCUP]. To
be more efficient in data transfer of the replication update
protocol, each referenced replica is assigned an id that is
protocol session-specific. The replicaIDTable is used to map
McMeeking Expires September 2003 [Page 7]
Internet Draft LDUP Replication March 2003
Update Protocol
between the replicaID (used here and in
ldapChangeSequenceNumber values in the protocol) and the UUID
corresponding to the replicaSubEntry representing the replica.
- replicationProtocolOID: the type of replication protocol that
should be used to transfer the updates. This document
describes two protocols; ietf-ldup-full-update and ietf-ldup-
incremental-update. See section 7 for information on the
semantic behavior of these update protocols. Implementations
MUST support the two update protocols defined in this document.
- replicationInitiator: used to differentiate between a supplier-
initiated session and a consumer-initiated session. If the
replicationInitiator contains the enumerated value <supplier>,
then the initiator is the supplier, and the receiver of this
operation should prepare to receive a set of replication
updates (or should reject the operation is replication updates
are not permitted for some reason, perhaps due to access
control restrictions). If the replicationInitiator contains
the enumerated value <consumer>, then the receiver should
prepare to establish a supplier-initiated replication session
with the consumer as soon as possible, updating the replicated
are given by replicaRoot and using the update protocol given by
replicationProtocolOID.
- replicaIDTable: used to set up a mapping of shorter "ids" to
UUIDs of the replicaSubEntry entries that correspond to the
ids. These ids are used in the change sequence numbers sent
over the replication update protocol instead of the full change
sequence number (including the UUID). This greatly reduces the
data transfer requirements of the update replication protocol.
6.2. createGroupingResponse Extended Operation
The createGroupingResponse extended operation is sent in response to
a createGroupingRequest extended operation.
For a supplier-initiated session, the createGroupingResponse
extended operation indicates that the consumer is or is not prepared
to accept a set of updates. If the consumer is prepared to accept
updates, it sends a createGroupingResponse extended operation
containing a success code and the consumer's replica update vector.
If the consumer is unwilling or unable to accept updates, it sends a
createGroupingResponse extended operation containing an error code.
For a consumer-initiated session, the createGroupingResponse
extended operation indicates that the supplier is or is not prepared
to send a set of updates to the consumer. If the supplier is
McMeeking Expires September 2003 [Page 8]
Internet Draft LDUP Replication March 2003
Update Protocol
prepared to send updates to the consumer, it sends a
createGroupingResponse extended operation with a success code. If
the supplier is unwilling or unable to send updates to the consumer,
it sends a createGroupingResponse extended operation containing an
error code. In both cases, the consumer unbinds and disconnects from
the supplier. If the supplier sent a success code to the consumer,
the supplier opens a connection to the consumer as soon as possible
and initiates a supplier-initiated replication session.
The createGroupingResponse extended operation is defined in section
3.2.2 of [GROUPING].
The createGroupCookie of the createGroupingResponseValue will
contain a cookie uniquely identifying this instance of the LDAP
Replication grouping type created as a result of the
createGroupRequest corresponding to this response. This cookie will
be used in subsequent operations in this replication session.
The createGroupValue of the createGroupingResponseValue must be set
to the BER-encoding of the following:
createGroupValue ::= createReplGroupRespValue
createReplGroupRespValue ::= SEQUENCE {
responseCode LDUPResponseCode,
replicaUpdateVector Attribute OPTIONAL,
}
LDUPResponseCodes are defined in section 9.
The replicaUpdateVector contains a replica update vector, as defined
in [INFOMOD]. The update vector is encoded as a normal LDAP
attribute, defined in [LDAPv3].
6.3. ReplicationUpdate Extended Operation
The ReplicationUpdate extended operation carries a set of
replication primitives that represent the changes necessary to bring
a single entry to a desired final state.
The ReplicationUpdate extended operation is defined as follows:
An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
ReplicationUpdate ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING
}
McMeeking Expires September 2003 [Page 9]
Internet Draft LDUP Replication March 2003
Update Protocol
The requestName of the ReplicationUpdate must be [OID to be
assigned].
The requestValue of the ReplicationUpdate must be set to the BER-
encoding of the following:
requestValue ::= SEQUENCE {
uniqueID UniqueIdentifier,
updates SET OF ReplicationPrimitive
}
Each ReplicationUpdate extended operation MUST be accompanied by a
groupingControl control identifying the replication session to which
the ReplicationUpdate operation belongs. The groupingControl control
is defined in section 3.5 of [GROUPING]. The groupingCookie of the
groupingControlValue contains the group cookie returned in the
createGroupingResponse. The groupValue of the groupingControlValue
is not present.
6.3.1. UniqueIdentifier
The Distinguished Name of an entry may be changed (by renaming the
entry), or the entry may not have a distinguished name (if it was
deleted). The Unique Identifier provides an immutable name,
independent of the current name or deletion status, for an entry.
All replicated operations address entries by their Unique
Identifiers.
UniqueIdentifier ::= LDAPString
Unique identifiers are also known as UUIDs in this document. Values
for UUIDs are taken from an entry's 'entryUUID' operational
attribute [LCUP].
6.3.2. ReplicationPrimitive
A ReplicationPrimitive carries a single assertion about changes
necessary to bring about the final state of an entry, attribute, or
attribute value. There are seven types of primitives.
ReplicationPrimitive ::= CHOICE {
addEntryPrimitive AddEntryPrimitive,
moveEntryPrimitive MoveEntryPrimitive,
renameEntryPrimitive RenameEntryPrimitive,
removeEntryPrimitive RemoveEntryPrimitive,
addAttributeValuePrimitive AddAttributeValuePrimitive,
removeAttributeValuePrimitive
RemoveAttributeValuePrimitive,
removeAttributePrimitive RemoveAttributePrimitive
}
McMeeking Expires September 2003 [Page 10]
Internet Draft LDUP Replication March 2003
Update Protocol
Each primitive applies to the entry referred to by the
uniqueIdentifier in the enclosing ReplicationUpdate extended
operation.
Each primitive carries an ldapChangeSequenceNumber that is used by
the consumer server to correctly resolve update conflicts. [URP]
describes the update reconciliation procedures.
6.3.2.1. AddEntryPrimitive
The AddEntryPrimitive is used to add a new entry.
AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE {
csn ldapChangeSequenceNumber,
superior UniqueIdentifier,
rdn RelativeLDAPDN
}
Parameters of the AddEntryPrimitive are:
- csn: The change sequence number of the primitive.
- superior: The unique identifier of the superior (parent) entry.
- rdn: The relative distinguished name of the new entry.
6.3.2.2. MoveEntryPrimitive
The MoveEntryPrimitive is used to move an entry to a new location in
the DIT.
MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE {
csn ldapChangeSequenceNumber,
superior UniqueIdentifier
}
Parameters of the MoveEntryPrimitive are:
- csn: The change sequence number of the primitive.
- superior: The unique identifier of the new superior (parent)
entry.
6.3.2.3. RenameEntryPrimitive
The RenameEntryPrimitive is used to change the RDN of an entry.
RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE {
McMeeking Expires September 2003 [Page 11]
Internet Draft LDUP Replication March 2003
Update Protocol
csn ldapChangeSequenceNumber,
rdn RelativeLDAPDN
}
Parameters of the RenameEntryPrimitive are:
- csn: The change sequence number of the primitive.
- rdn: The new relative distinguished name of the entry.
6.3.2.4. RemoveEntryPrimitive
The RemoveEntryPrimitive is used to delete an entry from the DIT.
RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE {
csn ldapChangeSequenceNumber
}
Parameters of the RemoveEntryPrimitive are:
- csn: The change sequence number of the primitive.
6.3.2.5. AddAttributeValuePrimitive
The AddAttributeValuePrimitive is use to add a new attribute value
to an entry.
AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE {
csn ldapChangeSequenceNumber,
type AttributeDescription,
value AttributeValue
}
Parameters of the AddAttributeValuePrimitive are:
- csn: The change sequence number of the primitive.
- type: The type of the attribute being added.
- value: The value being added. Multiple values are not
permitted.
Multiple added values are represented multiple primitives.
6.3.2.6. RemoveAttributeValuePrimitive
The RemoveAttributeValuePrimitive is used to remove a particular
attribute value from an entry.
McMeeking Expires September 2003 [Page 12]
Internet Draft LDUP Replication March 2003
Update Protocol
RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE {
csn ldapChangeSequenceNumber,
type AttributeDescription,
value AttributeValue
}
Parameters of the RemoveAttributeValuePrimitive are:
- csn: The change sequence number of the primitive.
- type: The type of the attribute being removed.
- value: The value being removed. Multiple values are not
permitted.
Multiple removed values are represented using multiple primitives.
6.3.2.7. RemoveAttributePrimitive
The RemoveAttributePrimitive is used to remove an attribute and all
its values from an entry.
RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE {
csn ldapChangeSequenceNumber,
type AttributeDescription
}
Parameters of the RemoveAttributePrimitive are:
- csn: The change sequence number of the primitive.
- type: The type of the attribute being removed.
6.4. endGroupingRequest Extended Operation
The endGroupingRequest extended operation is sent from the
replication supplier to the replication consumer to indicate the end
of the sequence of replication updates. In the event that the
supplier is sending a total update, the endGroupingRequest extended
operation contains a replica update vector. The consumer server must
replace its replica update vector, if present, with the one provided
by the supplier. In the event that the supplier is sending an
incremental update, the replica update vector is absent.
The endGroupingRequest extended operation is defined in section
3.3.1 of [GROUPING].
The endGroupCookie of the endGroupingRequestValue must be the cookie
identifying this instance of the LDAP Replication grouping type.
McMeeking Expires September 2003 [Page 13]
Internet Draft LDUP Replication March 2003
Update Protocol
The endGroupValue of the endGroupingRequestValue must be set to the
BER-encoding of the following:
endGroupValue ::= endReplGroupReqValue
endReplGroupReqValue ::= SEQUENCE {
returnConsumerUpdateVector BOOLEAN,
replicaUpdateVector Attribute OPTIONAL
}
If returnConsumerUpdateVector is TRUE, the consumer server must
return its current update vector to the supplier in the
EndReplicationResponse extended operation. Typically, the supplier
will request the consumer's update vector for read-only replicas,
since the read-only replica will never initiate a replication
session, and will therefore never have the opportunity to provide
its update vector to other servers.
6.5. endGroupingResponse Extended Operation
The endGroupingResponse extended operation is sent by a consumer to
a supplier in response to an endGroupingRequest extended operation.
The endGroupingResponse extended operation is defined in section
3.3.2 of [GROUPING].
The endGroupValue of the endGroupingResponseValue must be set to the
BER-encoding of the following:
endGroupValue ::= endReplGroupRespValue
endReplGroupRespValue ::= SEQUENCE {
replicaUpdateVector Attribute OPTIONAL
}
The replicaUpdateVector contains the consumer's current replica
update vector, and is optional. The consumer server MUST send the
replicaUpdateVector if requested by the supplier server in the
EndReplicationRequest extended operation.
6.6. ReplicationUpdateResponse Extended Operation
The ReplicationUpdateResponse extended operation is sent,
unsolicited, by a consumer to a supplier when the consumer wishes to
inform the supplier of committed results or tell the supplier to
stop sending updates.
An LDAPv3 extended response is defined in [LDAPv3] as follows:
McMeeking Expires September 2003 [Page 14]
Internet Draft LDUP Replication March 2003
Update Protocol
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS of LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL
}
The responseName of the ReplicationUpdateResponse must be the OID
[OID to be assigned].
The response field of the ReplicationUpdateResponse must be set to
the BER-encoding of the following:
response ::= SEQUENCE {
replicaUpdateVector Attribute OPTIONAL
abortUpdate BOOLEAN OPTIONAL DEFAULT FALSE
}
The parameters of the ReplicationUpdateResponse are:
- replicaUpdateVector: an optional update vector. If sent, this
indicates that the consumer has committed all updates whose
CSNs are covered by the transmitted update vector [see glossary
for a definition of "covered by"].
- abortUpdate: an optional Boolean flag. If a supplier receives
a ReplicationUpdateResponse from a consumer with the
AbortUpdate flag set to true, the supplier server MUST
immediately cease sending updates and terminate its connection
to the consumer.
Each ReplicationUpdateResponse extended operation MUST be
accompanied by a groupingControl control identifying the replication
session to which the ReplicationUpdateResponse operation belongs.
The groupingControl control is defined in section 3.5 of [GROUPING].
The groupingCookie of the groupingControlValue contains the group
cookie returned in the createGroupingResponse. The groupValue of the
groupingControlValue is not present.
7. Semantics of Full and Incremental Update protocols
The full and incremental update protocols are very similar. In the
full update protocol, the replication session is initiated in the
same manner as prescribed above for either supplier-initiated or
consumer-initiated replication. In the full update protocol, the
consumer's update vector is assumed to be set to times "earlier
than" the oldest times known to the supplier server. The supplier
server then begins by sending addEntryPrimitive protocol elements
for each entry in the replication area, starting from the top of the
tree and moving deeper into the tree. If any entry's attributes
have been modified since the add operation,
addAttributeValuePrimitive and removeAttributeValuePrimitive
McMeeking Expires September 2003 [Page 15]
Internet Draft LDUP Replication March 2003
Update Protocol
operations are also sent to bring the consumer's view of an entry
(including change sequence number information) up to date with the
supplier's knowledge about each entry.
The order of entries sent SHOULD be:
- "highest" entries in the tree sent prior to "lower" entries
(ancestors sent before parents).
- replication topology "subentries" sent prior to any other
entries in the DIT, sent in a "breadth-first" order
- other entries in the DIT, sent in a "breadth-first" order
This order allows "ancestor" entries to be seen by the consumer
before child entries, thus reducing the chances that the
lostAndFound entry will need to be used during processing of a full
update protocol.
A incremental update replication session SHOULD be requested by the
consumer shortly after the completion of the full update replication
session to ensure a timely update of entries in the replica for
updates made while the full replication protocol was taking place.
In the incremental update protocol, note that it is desirable that
within an entry, update replication primitives are sent in change
sequence number order (per replica on which the change was made) to
reduce the processing on the consumer side. While this is not
required, it is recommended.
8. Semantics of the LDAP Replication Grouping Type
In addition to the operational semantics in section 5 of [GROUPING]
that are applicable to all grouping types, the following semantics
apply to the LDAP Replication grouping type:
- The LDAP Replication grouping type MUST NOT be nested.
- Operations that do not belong to the current instance of the
LDAP Replication grouping type SHALL NOT be sent between the
createGroupingRequest and the receipt of the
endGroupingResponse. In effect, this means that a replication
session (as framed by the createGroupingRequest and its
corresponding endGroupingRequest) has exclusive use of the LDAP
connection.
9. Summary of response codes
The following list describes the response codes that may be included
in the StartReplicationResponse, EndReplicationResponse, and
ReplicationUpdateResponse extended operations.
McMeeking Expires September 2003 [Page 16]
Internet Draft LDUP Replication March 2003
Update Protocol
LDUPResponseCode ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
insufficientAccessRights (50),
busy (51),
excessiveCSNSkew (200),
other (80)
},
errorMessage LDAPString
}
The meanings of the response codes are as follows:
success..................... As defined in [LDAPv3].
operationsError............. As defined in [LDAPv3].
protocolError............... As defined in [LDAPv3].
insufficientAccessRights.... Access denied. The identity that
the initiator provided in the bind
request does not have sufficient
privileges to perform the operation.
busy........................ The replica is temporarily unable to
accept updates.
excessiveCSNSkew............ The consumer server has detected that
the CSNs being generated by the
supplier are too small (perhaps
because the supplier's clock was set
back). Updates from the supplier
will not be applied.
other....................... Some other error occurred.
10. Security Considerations
Bind: We don't specify exactly what you should use, but some
authentication types may provide a non-secure connection, e.g.
noauth, no encrypt.
Error message returned is listed as 'permission denied' regardless
of why request couldn't be performed, e.g. so you can't discover
what replicas exist or identity that cannot perform replication.
11. References
[ARCHITECTURE]
J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication
Architecture", Internet-Draft, draft-ietf-ldup-model-06.txt, March
2000.
[GROUPING]
McMeeking Expires September 2003 [Page 17]
Internet Draft LDUP Replication March 2003
Update Protocol
K. Zeilenga, "LDAPv3: Grouping of Related Operations", Internet-
Draft, draft-zeilenga-ldap-grouping-02.txt, April 2001.
[INFOMOD]
E. Reed, T. Hahn, "LDAP Replication Information Model", Internet-
Draft, draft-ietf-ldup-infomod-04.txt, November 2001.
[KEYWORDS]
S. Bradner, "Key Words for use in RFCs to Indicate Requirement
Levels", Harvard University, RFC 2119, March 1997.
[LDAPv3]
M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[REQ]
R. Weiser, E. Stokes, "LDAP V3 Replication Requirements",
Internet-Draft, draft-ietf-ldup-replica-req-10.txt, July 2001.
[URP]
S. Legg, A. Payne, "LDUP Update Reconciliation Procedures",
Internet-Draft, draft-ietf-ldup-urp-05.txt, October 2001.
[LCUP]
R. Megginson, M. Smith, O. Natkovich, J. Parham, "LDAP Client
Update Protocol", Internet-Draft, draft-ietf-ldup-lcup-01.txt,
June 2001.
12. Author's Addresses
John McMeeking
IBM Corporation
Rochester, MN
USA
Email: jmcmeek@us.ibm.com
phone: +1 507 253 4596
13. Appendix A - Complete ASN.1 Definition
JAM: to be provided in last call version of document.
14. Copyright Information
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
McMeeking Expires September 2003 [Page 18]
Internet Draft LDUP Replication March 2003
Update Protocol
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
McMeeking Expires September 2003 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:41 |