X.500 Standard status
(Implementors' Guide)

X.509 Related activities

How to be involved

More Information

Tutorial section 1
X.500 General

Tutorial section 2
X.509 specific

Other PKI organizations

edit SideBar

Search

X.500 Navigation

Navigation logo

Entries may be spread across several interconnected DSAs. Therefore, procedures are required for navigating to specific entries independent on the point of access. We will first consider how to get around and next how to know where to go.

Page content:

Distributed operations

A DSA may receive a DAP request froma DUA where the DSA contains non or only part of the information to be accessed. However, it has some knowledge as to where the DAP request my be satified. It can then operate in either of two modes:

  • It can forward the request to one or more other DSAs supposedly more capable of handling the request, and relay the received reply back to the DUA. This mode of operation is called chaining mode.
  • The DSA can return to the DUA the name and the presentation-address of the DSA or DSAs recommended to access subsequently. This mode is called referral mode.

Chaining of operations

Uni-chaining
Figure 1 - Uni-chaining

When chaining, the DSA forwards on behalf of the DUA the request to one or more other DSAs. The example shown in figure 1 illustrates that DSA-A has none or only part of the information requested by the DUA, but it knows that DSA-B has more information and/or better knows where to find it. The request is passed in this way from DSA to DSA until the requested information is collected. The result is passed back following the same chain and each DSA will merge its own result (if any) into the result received before passing it back to the previous DSA the chain.

Multi-chaining
Figure 2 - Multi-chaining

The example shown in figure 2 illustrates the case where DSA-A knows that both DSA-B and DSA-D may have information to satisfy the request, so it chains the request to both. As results are returned, DSA-A merges its own result with the results from DSA-B and DSA-D, and returns a single result to the requesting DUA.

Referrals

Referrals
Figure 3 - Referrals

The example shown in figure 3 illustrates that DSA-A believes DSA-D has better knowledge about where the information is located, but instead of passing the request to DSA-D, it 'refers' the DUA to DSA-D, which is more likely to satisfy the request.

Referrals pursued by DSA
Figure 4 - Referrals pursued by DSA

The example shown in figure 4 illustrates the case where DSA-A chains the request to DSA-B, which then refers DSA-A to DSA-D. Instead of passing the referral back to the DUA, DSA-A resolves the referral itself by chaining the request to DSA-D, which is more likely to satisfy the request.

Any combination of chaining and referrals are allowed by the X.500 standard. Which method is used to satisfy which requests depends on a variety of criteria, such as what network connections are defined between DSAs, operating policies, security policies, and user preferences.

Knowledge references

All DAP request types (except Bind and Abandon) include a distinguished name of the entry to be accessed or used as base for Search requests and List request. This distinguished name is used for navigating a request to the proper destination.

DSA hierarchy
Figure 5 - DSA hierarchy

Figure 5 is used to explain the basic principles of navigation. An X.500 directory may consists of several DSA that each hold a part of the DIT held by the directory. This DSAs may have a hierarchical relationship. This is illustrated by the example in figure 5.

DSAs A and B both have an entry just below the Root. Such a DSA is called a first level DSA.

Let us assume that a DUA is bound to DSA C and the entry to be accessed is in DSA H. The request now has to be chained through A, B and D to H. The following subsection explian what kind of knowledge in the individual DSAs that is necessary to accomplish that.

Superior references

Superior reference
Figure 6 - Superior reference

A DSA that is not a first level DSA must hold at least one superior reference to a DSA which is 'closer' to a first level DSA. By following a chain of superior references one will eventually get to a first level DSA.

When a DSA receives a directory operation for a part of the DIT which is connected to its own portion of the DIT by entries closer to the root, the DSA uses the superior reference to identify the DSA to which all such requests could be sent. That DSA may forward them in turn using its own knowledge references.

Subordinate references

Subordinate references
Figure 7 - Subordinate references

When a DSA receives a directory operation for a part of the DIT which is connected below an entry in its own DIT (that is an entry in its own DIT has a DN which fully matches the leading portion of the DN(s) to be accessed), it uses subordinate references to decide which DSA(s) should receive the request.

A specific subordinate reference points to a specific entry at a DSA. A non-specific subordinate reference points to a DSA which may contain lower level entries, but what they are is not known by the higher level DSA.

Cross references

Cross reference
Figure 8 - Cross reference

Cross references are used to short-cut the paths which might occur following superior and subordinate references through various DSAs. For example a London DSA might have a superior reference to a UK DSA which in turn has references to a US DSA. Requests for entries in US would be passed first to the UK DSA which would forward them to the US DSA. A cross reference in the London DSA to the US DSA would allow the request to be passed directly to the US DSA. Any number of cross references may be maintained optimising both superior and subordinate reference paths.

Root naming context

We have now seen how we can get from C to A in figure 5, and we have seen how we get from B to H. Now we shall see how we get from A to B.

More to be provided

Maintenance of knowledge

The next page is

Page Actions

Recent Changes

Group & Page

Back Links