X.500 Standard status
X.509 Related activities
How to be involved
Tutorial section 1
Tutorial section 2
X.509 at work
The X.525 part of the X.500 series specifies protocols and procedures for replicating directory information. Replication is the act of copying information from one DSA to another DSA.
There is also a whitepaper on X.500 replication, which presents information supplementary to this page.
X.525 recognises two modes of replication:
There are several good reasons for shadowing data:
One of the copies is the master copy. All maintenance of data is done toward the DSA holding this master copy. The other copies, also called shadows, can only be used for retrieving data (read-only).
Figure 1 shows a simplified shadowing model. DSA-A holds the master data. This data is shadowed to both DSA-B and DSA-C. In this configuration, DSA-A is called the shadow supplier, while DSA-B and DSA-C are shadow consumers. A shadow consumer may in turn copy the received data on to one or more other DSAs. This is also illustrated in Figure 1. DSA-C acts a shadow consumer toward DSA-A and as shadow supplier toward DSA-D for (part of) the same data. This is called secondary shadowing, while the shadowing from the master to a consumer is called primary shadowing.
Figure 2 gives more details on the shadowing process. Not all data held by a shadow supplier needs to be shadowed to a consumer. The shadowed information constitutes one or more units of replication. A unit of replication is in principle a subtree within the supplier DSA as indicated in the left side of figure 2. However, not all the information within the indicated subtree may necessarily be shadowed. Some selected entries may be excluded. Likewise, some attributes in some of the entries being copied may also be excluded. The absence of some entries in the unit of replication is illustrated in the right side of figure 2.
Figure 2 also illustrates that a consumer may also hold master information of its own.
The terms supplier and consumer only apply to a particular unit of replication. A DSA may be supplier for one or more units of replication and at the same time being consumer for other units of replication.
A shadowing agreement has to be established between the supplier and the consumer before transferring shadowing information. Such an agreement is primarily established using off-line procedures. An agreement consists of such things as:
A directory implementation needs to be initialised with some of the shadowing agreement parameters, such as the unit of replication, update mode, etc. This may happen in one of two ways:
Shadowing is supported by several X.500 Vendors. Implementations will typically not support all possible aspects of shadowing. A shadowing agreement therefore has to reflect the intersection of the feature supported by the two involved DSA implementations.
When a shadowing agreement is explicitly activated, an activation protocol exchange is required as illustrated in figure 3. It may also be seen as a confirmation of the agreement previously established. It provides a higher level of assurance that the two partners have a common view of the shadowing agreement. A special protocol called Directory Operational Binding Management Protocol (DOP) is used for this protocol exchange. As indicated in figure 3, either side may initiate such an exchange. The request contains such information as:
When a shadowing agreement has been activated, either implicitly or explicitly, updates may be performed using the Directory Information Shadowing Protocol (DISP).
Figure 4 illustrates the push mode, where the shadow supplier takes the initiative to the update. The transfer is notified by a coordinateShadowUpdate request. This request contains the following information:
If the parameters are acceptable, a result is returned. The result depends on whether it is to be signed or not. If no signing, it is just a simple confirmation (returning the ASN.1 UNIVERSAL type NULL). If signing is to be done, some information is included in the result. In addition to what is shown in figure 4, some security parameters are also included.
If the parameters of the coordinateShadowUpdate request are not acceptable, it is rejected by an Error instead of a result (not shown in figure 4). There can be several reasons for this rejection, such as an invalid agreement id, an inactive shadowing agreement, etc.
If the supplier receives a coordinateShadowUpdate result, it will then transfer the actual shadow update in an updateShadow request. The updateInfo within that request is a rather complex ASN.1 construct that contains the update information (or an indication that there is no information to transmit). In addition, the agreement id and the update time is transferred. There may also be other parameters not shown in figure 4. The supplier may indicate a time interval for the next update, and if the updateShadow request is to be signed, it must also include some security parameters.
If the parameters of the updateShadow request are acceptable, a result is returned similar to the one for the coordinateShadowUpdate.
Figure 5 illustrates the pull mode, where the shadow consumer takes the initiative to the update. The transfer is requested by a requestShadowUpdate request. This request contains the following information:
A requestShadowUpdate may be rejected in much the same way as the coordinateShadowUpdate.
If the supplier sends a requestShadowUpdate result, it will then transfer the actual shadow update in an updateShadow request as discussed above.