rfc2969.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/3 页

Network Working Group                                          T. Eklof
Request for Comments: 2969                                    L. Daigle
Category: Informational                                    October 2000


        Wide Area Directory Deployment - Experiences from TISDAG

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   The TISDAG (Technical Infrastructure for Swedish Directory Access
   Gateway) project provided valuable insight into the current reality
   of deploying a wide-scale directory service.  This document
   catalogues some of the experiences gained in developing the necessary
   infrastructure for a national (i.e., multi-organizational) directory
   service and pilot deployment of the service in an environment with
   off-the-shelf directory service products.  A perspective on the
   project's relationship to other directory deployment projects is
   provided, along with some proposals for future extensions of the work
   (larger scale deployment, other application areas).

   These are our own observations, based on work done and general
   project discussions.  No doubt, other project participants have their
   own list of project experiences; we don't claim this document is
   exhaustive!

















Eklof & Daigle               Informational                      [Page 1]

RFC 2969             Wide Area Directory Deployment         October 2000


Table of Contents

   1.0 Introduction ................................................  2
   1.1 Overview of the TISDAG project ..............................  2
   1.2 Organization of this document ...............................  3
   2.0 The TISDAG project itself ...................................  3
   2.1  TISDAG overview ............................................  3
   2.2 Some successes ..............................................  4
   2.3 Some surprises ..............................................  5
   2.3.1 LDAP objectclasses and the "o" attribute ..................  6
   2.3.1 The Tagged Index Object ...................................  6
   2.3.3  Handling Status Messages .................................  7
   2.3.4  Deployment with Commercial Software ......................  7
   2.4 Some observations ...........................................  7
   2.4.1 Participation of the WDSPs ................................  7
   2.4.2 Index Objects and Referral Index size .....................  8
   2.4.3 Index Object and Query Performance ........................  8
   2.5 Some evolutions .............................................  9
   3.0 Related Projects ............................................ 11
   3.1 The Norwegian Directory of Directories (NDD) ................ 11
   3.2 DESIRE Directory Services ................................... 11
   4.0 Some Directions for TISDAG Next Steps ....................... 12
   4.1 Security support ............................................ 12
   4.2 WDSPs attributes and schemas  ............................... 12
   5.0 Some conclusions ............................................ 13
   6.0 Security Considerations ..................................... 13
   7.0 Acknowledgements ............................................ 13
   8.0 Authors' Addresses .......................................... 13
   9.0 References .................................................. 14
   Appendix -- Specific Software Issues and Deployment Experiences.. 15
   Full Copyright Statement ........................................ 18

1.0 Introduction

1.1 Overview of the TISDAG project

   As described in more detail in [TISDAG], the original intention of
   the TISDAG project was to provide the infrastructure for a national
   whitepages directory service.  To be effective, such an
   infrastructure needed to address the concrete realities of end-users'
   existing client software, as well as the needs of information
   providers ("Whitepages Directory Service Providers" -- WDSPs).  These
   realities include the existence of multiple protocols (so-called
   directory service access protocols, as well as more general Internet
   application protocols such as HTTP and SMTP).  The project was also
   sensitive to the fact that WDSPs have many good reasons for being
   reluctant to relinquish copies of their subscribers' personal data.




Eklof & Daigle               Informational                      [Page 2]

RFC 2969             Wide Area Directory Deployment         October 2000


1.2 Organization of this document

   In an effort to communicate the experiences with this project, from
   conception through implementation and pilot deployment, this document
   is divided into 3 major sections.  The first section reviews specific
   lessons learned by the authors through the TISDAG project and
   implementation of one conformant system.  Next, some perspectives are
   offered on the relationship of the TISDAG work to other large-scale
   directory projects that are currently on-going, to give a sense of
   how these efforts might possibly interact.  Finally, some preliminary
   thoughts on applying the DAG system to other applications and
   deployment environments are outlined.  Further suggestions for
   deploying networked DAG servers (meshes) can be found in [DAG-Mesh].
   More discussion of useful development of architectural principles is
   provided in a separate document ([DAG++]).

2.0 The TISDAG project itself

2.1  TISDAG overview

   Briefly, the technical infrastructure proposed for the TISDAG project
   (see [TISDAG] for the complete overview and technical specification)
   provides end-user client software with connection points to perform
   basic whitepages queries.  Different connection points are provided
   for the various protocols end-users are likely to wish to use to
   access the information -- WWW (http), e-mail (SMTP), Whois++, LDAPv2
   and LDAPv3.  For each client, a transaction will be carried out
   within the bounds of the protocol's syntax and semantics.  However,
   since the TISDAG system does not maintain a replicated copy of all
   whitepages information, but rather an index over the data that allows
   redirection (referrals) to services that are likely to contain
   responses that match the client's query, a fair bit of background
   work must be done by the DAG system in order to fulfill the client's
   query.

   The first, and most important step, is for the system to make a query
   against the DAG Referral Index -- a server containing index
   information (obtained by the Common Indexing Protocol (see [CIP1,
   CIP2, CIP3]) in the Tagged Index Object format (see [TIO]).  This
   index contains sufficient information to indicate which of the many
   participating WDSPs should be contacted to complete the query.
   Wherever possible, these referrals are passed back to the querying
   client so that it can contact relevant WDSPs directly.  This
   minimizes the amount of work done by the DAG system itself, and
   allows WDSPs greater visibility (which is an incentive for
   participating in the system).  Protocols which support referrals
   natively include Whois++ and LDAPv3 -- although these may only be
   referred to servers of the same protocol.



Eklof & Daigle               Informational                      [Page 3]

RFC 2969             Wide Area Directory Deployment         October 2000


   Since many protocols do not support referrals (e.g., LDAPv2), and in
   order to address referrals to servers using a protocol other than the
   calling client's own, a secondary step of "query chaining" is
   provided to pursue these extra referrals within the DAG system
   itself.  For example, if an LDAPv2 client connects to the system, a
   query is made against the Referral Index to determine which WDSPs may
   have answers for the query, and then resources within the DAG system
   are used to pursue the query at the designated WDSPs' servers.  The
   results from these different services are packaged into a single
   response set for the client that made the query.

   The architecture that was developed in order to support the required
   functionality separated the system into distinct components to handle
   incoming queries from client software ("Client Access Points", or
   CAPs), a referral index (RI) to maintain an index over the collected
   whitepages information and provide referrals, based on actual data
   queries, to WDSPs that might have relevant information, and finally
   components that mediate access to WDSP whitepages servers to perform
   queries and retrieve results for the client's query ("Service Access
   Points", or SAPs).  Several CAPs and SAPs exist within the system --
   at least one for every protocol supported for incoming queries and
   WDSP servers, respectively.

   Designed to be implementable as separate programs, these components
   interact with each other through the use of an internal protocol --
   the DAG/IP.  Pragmatically, the use of the protocol means that
   different components can reside on different machines, for reasons of
   load-balancing and performance enhancement.  It also acts as a
   "common language" for the CAPs, SAPs and RI to express queries and
   receive results.

   This outlines the planned or ideal behaviour of the system; once
   designed, a pilot phase was started for the project to compare
   reality against expectations.  Two independent implementations of the
   software were created, and a test deployment was set up within the
   Swedish University Network (SUNET).  More detail on the project and
   its current status can be found at http://tisdag.sunet.se/.

   The rest of this section outlines some conclusions drawn from making
   a reality of the proposed architecture -- both successes and
   surprises.

2.2 Some successes

   Implementation and pilot deployment of software meeting the TISDAG
   technical specification did demonstrate some important successes of
   the approach.




Eklof & Daigle               Informational                      [Page 4]

RFC 2969             Wide Area Directory Deployment         October 2000


   Most notably, the system works pretty much as expected (see
   exceptions below) to provide transparent middleware for whitepages
   directory services.  That is, client software and WDSP servers were
   minimally affected -- from the point of view of behaviour and
   configuration, the DAG system looked like a server to clients, and a
   client to servers.

   The goal of the TISDAG project, operationally, was to be able to
   provide responses to end-user queries in reasonable response times
   (although not "an addressbook replacement").  The prototype systems
   demonstrated some success in achieving responses within 10 seconds,
   at least with the limited testbed of a configuration with 10 WDSP's
   providing directory service information.  More observations on system
   performance are provided below.

   The DAG system does demonstrate that it is possible to build
   referral-level services at a national level (although the deployment
   has yet to prove conclusively that it can, in its current
   formulation, operate as a transparent query-fulfillment proxy
   service).

   The success of the implementation demonstrated that it is possible,
   in some sense, to do (semantic) protocol mapping with N+M complexity
   instead of NxM mappings.  That is, protocol translations had to be
   defined for "N" allowable end-user query access protocols to/from the
   DAG/IP, and "M" supported WDSP server protocols, instead of requiring
   each of the N input components to individually map to the M output
   protocols.

   As a correlated issue, the prototype system demonstrated some
   successes with mapping between schema representations in the
   different protocol paradigms -- in a large part because system's
   schemas were kept simple and focused on the minimal needs to support
   the base service requirements.

2.3 Some surprises

   Over the span of a dozen months from the first "final" document of
   the specification through the implementation and first deployment of
   the software system, a few surprises did surface.  These fell into
   two categories:  those that surfaced when the theoretical
   specification was put into practice, and others that became apparent
   when the resulting system was put into operation with commercial
   software clients and servers.

   More detail is provided in the Appendix concerning specific software
   issues encountered, but some of the larger issues that surfaced
   during the implementation phase are describe below.



Eklof & Daigle               Informational                      [Page 5]

RFC 2969             Wide Area Directory Deployment         October 2000


2.3.1 LDAP objectclasses and the "o" attribute

   It came as a considerable surprise, some months into the project,
   that none of the "standard" LDAP person objectclasses   included
   organization ("o") as an attribute. The basic assumption seems to be
   that "o" will be part of the distinguished name for an entry, and
   therefore there is little (if any) cause to list it out separately.
   This does make it trickier to store information for people across
   multiple organizations (e.g., at an ISP's directory server) and use
   the organization name in query refinement. (Roland Hedberg caught
   this issue, and has flagged it to the authors of the "inetorgperson"
   objectclass document).

2.3.1 The Tagged Index Object

   The Tagged Index Object ("TIO"), used to carry indexes of WDSP
   information to the RI, is designed to have record (entry) tags to
   reduce the number of false positive referrals generated when doing a
   search in the RI.  One of the features of the first index object
   type, Whois++'s centroid (see [centroid]) was the fact that the index
   object size did not grow linearly with the size of data indexed --
   i.e., at some point the growth of the index object slowed as compared
   to that of the underlying data set.  At first glance, this also seems
   to be the case for the TIO.  However, as the index grows in size the
   compression factor of the TIO may not achieve the same efficiency as
   the centroids.  One reason for this is that the tagged lists can get
   quite long, depending on the ordering of the assignment of tags to
   the underlying data.  That is, the tagging as defined allows for a
   compressed expression of tag "ranges" -- e.g., "1-500" instead of
   "1,2,3,[...]500".  Thus, it might be interesting to explore an
   optimal "sorting" of underlying data, before applying tags, in order
   to arrange the most common tokens have consecutive tags (maximal
   compression of the tag lists).  It's not clear if this can be done
   efficiently over the entire set of records, attributes, and tokens,
   but it would bear some investigation, to produce the most compressed
   TIO for transmission.

   Additionally, in order to make (time) efficient use of the tags in
   the RI in practice, it is almost necessary to "reinflate" the index
   object to be able to do joins on tag lists associated with tokens
   that match.  Alternatively, the compressed tag list can be stored,
   and there is an additional cost associated with comparing the tag
   lists for matching tokens -- i.e., list comparison operations done
   outside the scope of a base database management system.  There was an
   unexpected tradeoff to be made.






Eklof & Daigle               Informational                      [Page 6]

RFC 2969             Wide Area Directory Deployment         October 2000


2.3.3  Handling Status Messages

   Mapping of status messages from multiple sub-transactions into a
   single status communication for the end-user client software became
   something of a challenge.  When chaining a query to multiple WDSPs
   (though the SAPs), it is not uncommon for at least one of the WDSP
   servers to return an error code or be unavailable.  If one WDSP
   cannot be reached, out of several referrals, should the client
   software be given the impression that the query was completed
   successfully, or not?  Most client protocol error handling models are
   not sophisticated enough to make this level of distinction clear.

2.3.4  Deployment with Commercial Software