A3: Distributed Systems

A Scalable, Deployable, Directory Service Framework for the Internet

Howes, Timothy A. ( tim@umich.edu)

Smith, Mark C. ( mcs@umich.edu)

Abstract

Namespace

A namespace plays a key role in a directory service, allowing collections of related information to be referred to and retrieved. Some services like X.500 make the namespace explicit, requiring complex management and registration processes. Other services like WHOIS++ and SOLO explicitly eschew a hierarchical namespace in favor of a more loosely organized mesh in which information is referred to by its content.

We make the simple observation that the Internet already has a namespace (the DNS) which is scalable, familiar, and has well-established registration procedures. Just as RFC 822 piggybacks on the DNS to define an e-mail namespace, we use the same namespace for directory service.

The advantage is that it's familiar to users and administrators, compact and efficient, yet mnemonic. The registration of names is free, having already been provided by an established authority.

Navigation

Navigation is the process of determining which server holds a particular piece of information. Given the efficiency with which the DNS translates names to hosts (for email, etc.), we propose using the same mechanism for directory service. We define a DX or Directory eXchange DNS record which is similar to an MX record, except that it points to a host performing directory service for a domain instead of email service.

The advantage is that the DNS is familiar, scalable, proven technology, well-understood by system administrators who already need to know how to deal with the DNS to use and provide other Internet services.

Installed Base

To incorporate the installed base of directory services, we extend the DX record to return Uniform Resource Locators (URL). Clients looking up DX records for a directory name are returned one or more URLs, pointing to the directory service(s) for the domain. They then choose the access method they prefer.

The advantage is the use of proven URL technology as a way of allowing even sites running old protocols to participate with little effort.

Local Searching

Local searching is done using the protocol of a site's own choosing, allowing us to co-opt existing sites in much the same way the Web has co-opted existing information service protocols. At the same time, sites can migrate to newer, more functional protocols at their leisure.

In addition, we define a local directory service protocol to which sites can migrate. It is based on a stand-alone version of LDAP, the Lightweight Directory Access Protocol, one not dependent on X.500. With the addition of referrals and the incorporation of DNS-style directory names, LDAP fits well into this framework.

Non-Local Searching

The problem of searching wide areas that cover multiple directory services is handled in two ways. First, high-level directory servers are deployed which can return URL-based referrals to local directory services.

Second, these servers employ centroid technology to help prune the help prune the search space. Participating sites send centroid data to these servers, allowing global searches to be done efficiently.

Implementability and Deployability

These are perhaps the most important yet overlooked characteristics a directory service need to succeed on the Internet. Our scheme has been designed to remove the barriers to implementation and deployent encountered by other directory services. The registration problem is sidestepped by using the existing DNS namespace. The likelihood of user acceptability is also increased through the use of this familiar namespace. System administrators already have the knowledge necessary to hook their site into the global system. The migration of sites from their existing services is not needed immediately and can take place at the site's leisure.