RFC 1275 INFORMATIONAL DIRECTORY · X.500 · ARCHITECTURE

Replication Requirements to provide an Internet Directory using X.500

Making a global directory work by replicating data widely.

On rfc-editor.org ↗
PUBLISHED
November 1991
AUTHORS
S.E. Hardcastle-Kille
STREAM
IETF
RFC STATUS
Informational
PUBLICATION DATE
November 1991
PILOT SCALING TARGET
100,000 non-leaf entries
DOI
10.17487/RFC1275

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                            S.E. Hardcastle-Kille
Requests for Comments 1275                   University College London
                                                         November 1991








Replication Requirements to provide an Internet Directory using X.500










Status of this Memo
    This memo provides information for the Internet community.  It
    does not specify an Internet standard.  Distribution of this memo
    is unlimited.
Abstract

    This RFCconsiders certain deficiencies of the 1988 X.500
    standard, which need to be addressed before an effective open
    Internet Directory can be established using these protocols and
    services [CCI88].  The only areas considered are primary
    problems, to which solutions must be found before a pilot can be
    deployed.  This RFCconcerns itself with deficiencies which can
    only be addressed by use of additional protocol or procedures for
    distributed operation.

1  Distributed Operation Extensions

The Internet Directory will operate DSAs over TCP/IP using RFC 1006
[RC87], and DSAs over the an ISO Network Service.  Distributed
operation procedures should not require full connectivity.


2  Knowledge Replication

Knowledge information is critical to resolution of names, and
performing searches.  Knowledge information high up the tree needs to
be widely available.  Consider resolving a name below ``Country=US''.
To do this, a DSA needs to have full knowledge at this point.  Many
DSAs need to be able to do this, in order to give reasonable response
and availability.  It would be an unacceptable bottleneck to force
such resolution to a single or small number of DSAs.  To replicate
this knowledge widely, a systematic approach to replication is needed.


3  Data Replication

Searches are often made at the root and country level, and this is a
vital service (e.g., an approximate match of an organisation name).
Data needs to be collected in such a way that this sort of searching
is reasonably efficient.  The usual X.500 approach of subordinate
references militates against this.  At a node in the DIT, subordinate
references to the entries below are held.  These entries will be in
many DSAs, each of which needs to be accessed in order to perform the
single level search.  It is suggested that replication of data is
necessary to achieve this.

The major requirement for this replication is high up the DIT, where
information must be replicated between different implementations.  At
lower levels of the DIT, it is reasonable for DSAs to be of the same
implementation and to use implementation specific techniques in order
to achieve performance and availability.


4  Alternate DSAs

When a DSA Referral is returned, only the master DSA is indicated.
This will lead to a single point of failure.  It seems important to
allow for additional references to slave copies, in order to get


Hardcastle-Kille                                                Page 1

better availability.  This needs to be solved in conjunction with the
problem described in the previous section.


5  Guidelines for use of Replication

To be effective, the replication specification needs to provide
guidelines for deployment in the pilot, in order to meet the desired
service criteria.


6  Some scaling targets

Most techniques for replication have scaling limits.  It is important
that mechanisms used do not stress the limits of the mechanism.  The
order of magnitude envisioned in the pilot is 100 000 non-leaf entries
and several million leaf entries.


References

[CCI88] The Directory --- overview of concepts, models and services,
        December 1988. CCITT X.500 Series Recommendations.

[RC87]  Marshall T. Rose and Dwight E. Cass. ISO Transport Services
        on top of the TCP. Request for Comments 1006, Northrop
        Corporation Technology Center, May 1987.


7  Security Considerations

Security considerations are not discussed in this memo.


8  Author's Address

    Steve Hardcastle-Kille
    Department of Computer Science
    University College London
    Gower Street
    WC1E 6BT
    England



Hardcastle-Kille                                                Page 2

    Phone:  +44-71-380-7294

    EMail:  S.Kille@CS.UCL.AC.UK










































Hardcastle-Kille                                                Page 3

AI ELI5

On this page
PROBLEMThe 1988 X.500 directory standard lacks replication, making it unsuitable for a scalable Internet directory.
MECHANISMReplication of directory knowledge and data across multiple servers enables both responsiveness and availability.
WHAT NEEDS TO HAPPENThe RFC identifies five critical replication requirements that any Internet directory must address before deployment.

§1Introduction to X.500 and the Internet Directory

RFC 1275 examines deficiencies in the 1988 X.500 standard that must be solved before it can serve as an Internet directory. X.500 defines a distributed directory system using Directory Service Agents (DSAs) that answer directory queries. The RFC focuses on replication, the practice of maintaining copies of directory data on multiple servers. Without replication, a single server becomes a bottleneck and a single point of failure.

When many people need to look up a phone number at the same time, one person answering the phone can only handle so many calls. You need more people answering phones in different places.

§2Knowledge Replication

Directory servers must know how to route queries to the right place. This routing information is called knowledge. Knowledge about the top of the directory tree must be replicated widely. Consider resolving a name under Country=US; a DSA needs complete knowledge of that subtree. Many DSAs must have this knowledge to provide fast, reliable response. Requiring all queries to go through one server would be an unacceptable bottleneck.

Imagine a post office where letters need to be routed to the right town. The main post office needs to know where every town is, and so do many other post offices.

§3Data Replication for Search

Many searches happen at the root and country level, such as approximate matching of organization names. X.500's standard approach of subordinate references (pointers to entries held in other DSAs) makes such searches inefficient. Instead, data must be replicated where people search for it most. Replication is particularly important high in the directory tree and between different implementations. At lower levels, DSAs from the same vendor can use implementation-specific techniques.

If you look up "United States" in a phone book, the book should have that information right there, not just a note saying "ask this other book."

§4Availability and Scaling

When a DSA returns a referral, it indicates only one master server. This creates a single point of failure. Additional references to slave copies must be allowed to improve availability. The RFC calls for deployment guidelines and defines scaling targets: the pilot was envisioned to handle approximately 100,000 non-leaf entries and several million leaf entries. Replication mechanisms must not exceed the scaling limits of the technique used.

If the main server is broken, a request can go to a backup copy. And the system needs to keep working even with a million names.

§5References