Directory Services

The CCITT and now ISO X.500 Directory Service provides something rather more complex than a simple name/location service. We shall see how the directory may be used for storing network management information in chapter 9. For the moment, we describe the operation of the directory. These are services which assist in locating services and routing by maintaining databases (often distributed) of name-name and name-address mappings. They may map user-friendly names onto network names. These are in use in Wide Area Networks such as the Internet and thus contrast with many simpler nameservers in use on LANs. standards for directory and name services. The Name Registration Scheme (NRS) and Domain Name scheme (DoD) allow the user to specify destination services by user friendly names. Services located in this way are hosts, mailboxes and other services. These services are built as distributed data bases on the network. Usually the user does not interact directly with such services. A user supplies the name of a service, and some quality of service that is required (``Get me Jones, and ;SPM_lt;quickly;SPM_gt;'', or ``Send this to Boston, ;SPM_lt;Second Class;SPM_gt;''). The user program dealing with the request asks a ``resolver'' to find the service. The resolver (may) try various places, until a satisfactory answer is found, and carries out the original request directly. CCITT X.500 series of standards came into effect in 1988 - defining a standard for global naming. A Directory contains entries which describe Communications Entities. A Communication Entity may be virtually anything about which there is information that can be stored (e.g. Humans, computer processes, services). There is considered to be one global directory service. This is much in the style of the Xerox Grapevine Global model, but much has been learned from the scaling problems that Grapevine had. A user accesses the directory service by the use of a Directory User Agent (DUA). A Directory Service Agent access the Directory, and communicates with other DSAs and DUAs. The Directory Service Functional Model is illustrated in #fndirmod#453>. A User interacts with the DUA to formulate a query. The DUA then interacts with the Directory System, by communicating with one or more DSAs. The DSAs may then communicate with each other to resolve the query. An example of an entry in a directory service for an individual might be as illustrated in the table #tbdirent#454>.

Table: Directory Entry Example

The protocols being considered for DUA - DSA and DSA - DSA interactions are based on Remote Operations Service (ROS). They are known as the Directory access Protocol (DAP) and the Directory Service Protocol (DSP). The data held in the Directory is in the form of Attribute/Value pairs, and thus can be arbitrarily complex. The set of operations allowed on the directory include searching on keys as well as the usual resolver type interaction.

Figure: The Distributed Directory Model

Recursion versus Iterative, ;SPM_quot;Chaining and Referral;SPM_quot; Information in the Directory is arranged to form a tree, as are the directory servers themselves. Each server holds some part of the directory tree, most of which is information relevant to the local operations of the system the directory server resides in. It is possible for servers to hold information on behalf of other parts of the Directory Information Tree, and is reasonable in some circumstances (e.g. a small site without the capacity to run a directory service - i.e. cost reasons, or to provide mutual backup between two sites - i.e. reliability). When a Directory User accesses a server and makes a query, it is possible that the query is for information held in other directories. There are two different approaches for how to proceed:

  1. Recursive. The Directory chooses another directory and calls it ;SPM_quot;on behalf;SPM_quot; of the user. This next directory may choose to do the same if it cannot resolve the query. This is known as <#467#> chaining<#467#> (#fnchain#468>).
  2. Iterative. The Directory returns a ;SPM_quot;pointer;SPM_quot; to another chosen directory. This is known as <#469#> referral<#469#> (#fnrefer#470>).
These two mechanism permit location transparency, although the second requires more intelligence in the Directory User Agent. In both cases, the results may be cached by the user or indeed all along a chain. This achieves some performance transparency as well as location transparency. The mechanism by which the directory servers choose other servers to chain or refer too is self consistent. The mapping of the structure of the directory information tree onto the tree of directory servers must be held in the Directory itself.

Figure: Chaining

Figure: Referral

There are two important engineering design decisions here. One is the choice of cache timeouts. The other is when to chain and when to refer. A Model implementation [ref QUIPU] relies on the slow changing nature of Directory Information and uses large cache timeouts. QUIPU uses chaining for the first interaction (e.g. DUA to DSA) and thereafter uses referrals. This is justified on the grounds that the DUA is simplified and that only the ;SPM_quot;first;SPM_quot; DSA need ;SPM_quot;switch;SPM_quot; connections - i.e. hold complex state about complex operations non-local parts of the tree. <#558#>#tex2html_wrap3838#<#558#> The Directory has not had the success that it should have had so far. In practice, other less well designed systems are in common use in the world wide Internet. The existence of the Domain Name System (largely a read-only, non-searchable hierarchical database of networked object name/address pairs), has meant that there is less infra-structural requirement for X.500 systems. This has been a pity. <#559#>#tex2html_wrap3840#<#559#>