[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01                                                            
Application Working Group                                    Tim Howes
INTERNET-DRAFT                           Netscape Communications Corp.
Expires in six months                                      Luke Howard
Intended Category: Standard                     Independent Consultant
                                                          October 1997


         A Simple Caching Scheme for LDAP and X.500 Directories
                  <draft-ietf-asid-ldap-cache-01.txt>



1.  Status of this Memo

This document is an Internet-Draft. Internet-Drafts  are  working  docu-
ments  of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working docu-
ments as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum  of  six  months
and  may  be  updated,  replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference  material
or to cite them other than as ``work in progress.''

To learn the current status of  any  Internet-Draft,  please  check  the
``1id-abstracts.txt''  listing  contained in the Internet- Drafts Shadow
Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe),
munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or
ftp.isi.edu (US West Coast).

2.  Abstract

This memo defines an object class and attribute type  in  support  of  a
simple  caching  mechanism  for  use in LDAP and X.500 directories.  The
object class allows a simple 'time-to-live' attribute to be included  in
entries,  enabling  clients  retrieving  the  attribute to tell when the
other information they have retrieved from the entry  should  be  thrown
away.  The  use of this scheme does not preclude the subsequent or addi-
tional use of other more complicated schemes, for example, allowing dif-
ferent TTLs on individual attributes.

3.  Need for Caching and Overview

LDAP [ldapv3-1, ldapv3-2] and X.500 [x500] define  a  distributed  data-
base.   To achieve greater performance and availability, it is desirable
to replicate information close to  the  entities  accessing  it.  Formal
replication  schemes  have been devised for this purpose.  Caching is an
informal  method  of  replication  designed  to  make  repeated  use  of



Howes & Howard                                                  [Page 1]


Expires March 1998                                        INTERNET DRAFT


information  by  the same or co-located clients more efficient.  Systems
relying on fast performance that can  tolerate  temporarily  out-of-date
data,  such as the Domain Name System [rfc1034], often make heavy use of
caching to achieve the desired level  of  performance.  LDAP  and  X.500
comprise another system that could similarly benefit from caching.

Until now, there has been no agreed scheme for  providing  a  consistent
caching  mechanism  for  LDAP and X.500. Caching occurs, but it is up to
the caching agent to determine the appropriate length of time a piece of
information can safely be cached. There is support in X.500 for ignoring
all cached or replicated information copies in favor of the master copy,
at  the  client's discretion (the dontUseCopy service control). There is
no guidance on the length of time that information (master or  not)  can
safely be cached.

This draft defines a simple caching model similar to that  used  by  the
DNS. A new operational attribute, ttl, is defined to specify the maximum
time for which a cached copy of any attributes in the  entry  should  be
considered  valid.   The  ttl attribute SHOULD be allowed in every entry
that may be cached.

A new object class, cacheObject is defined, which  allows  an  entry  to
have  the  new ttl attribute, even if the server implementation does not
support operational attributes (e.g., an LDAPv2 server).

Note that use of this scheme means that all attributes in an  entry  are
subject  to  the  same TTL. This is satisfactory in many cases, but more
complicated situations where different attributes (or even values of the
same  attribute)  may  have different TTL requirements can easily arise.
The scheme described here is not intended to address  these  situations,
nor is it intended to hinder the development of other schemes that do.

4.  The ttl Attribute

The definition of the ttl attribute is as follows:

   ( 1.3.6.1.4.1.250.1.60 NAME 'ttl' EQUALITY integerMatch
     SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' SINGLE-VALUE )

The ttl attribute contains the time, in seconds,  that  any  information
from  the  entry  should  be  kept  by  a client before it is considered
"stale" and a new copy fetched. A value of 0  implies  that  the  object
must not be cached.

The behaviour of caching clients with respect to entries lacking the ttl
is  not  prescribed.  Caching  agents may use any appropriate method for
determining  whether  an  entry  without  a  ttl  attribute  should   be
refetched.   For   example,  clients  may  compare  the  modifyTimestamp



Howes & Howard                                                  [Page 2]


Expires March 1998                                        INTERNET DRAFT


attribute of the entry with the current one and refetch the  entry  only
if  the entry has been updated since it was cached. A number of factors,
such as network latency, may render this policy  inefficient.  As  such,
clients  may  assume  entries lacking the ttl attribute never expire, or
that they expire in some client-defined time period, or that they should
never be cached.

5.  The cacheObject Object Class

The cacheObject object class is defined as follows:

   ( 1.3.6.1.4.1.250.3.18 NAME 'cacheObject' AUXILIARY SUP top
     DESC 'Auxiliary object class to hold TTL caching information'
     MAY ttl )

6.  Coexistence with entryTtl and DNS-related attributes

The entryTtl attribute, defined in [v3ext], is an operational  attribute
maintained  by  the  directory  server which appears to bear superficial
resemblance to the ttl attribute. The entryTtl attribute is only present
in entries of the dynamicObject object class, and may not be modified by
the user.  A value of 0 indicates that the entry may disappear from  the
directory without warning.

By contrast, the ttl attribute as defined here  refers  not  to  dynamic
entries,  but to those defined by the user which are accorded a specific
time to live.

Clients caching entries of class dynamicObject should use  the  entryTtl
attribute  instead  of  the  ttl  to determine an object's TTL. The same
behaviour applies: if the value is 0, the entry should not be cached.

The dNSDomain  object  class  [rfc1279]  contains  attributes,  such  as
dNSRecord,  which  may  include  embedded TTLs. If the caching agent has
specific cognizance of these attributes, it may wish to honour  them  in
preference to the entryTtl or ttl attributes. This is not required.

7.  Security Considerations

A caching scheme has implications on the accuracy and security of  data.
Both  applications  and  data providers should be aware of how important
information consistency is for the data they are using or providing.

When accessing anything but publicly available information, care must be
taken  by  the caching entity to ensure that the intended access control
policy of the directory is not violated. This may be accomplished by not
caching  non-public information at all, or by having an understanding of
the source site's access control policies.  Note  that  understanding  a



Howes & Howard                                                  [Page 3]


Expires March 1998                                        INTERNET DRAFT


site's  access  control  policy may be difficult, given the existence of
proprietary schemes, and the fact that there may be mechanisms in  place
not  visible  or  detectable by the caching entity. These mechanisms may
even make the determination of what information is  publicly  accessible
difficult or impossible.

8.  Bibliography


[ldapv3-1]Wahl, M., Howes, T., Kille, S., "Lightweight Directory  Access
          Protocol    (v3)",   INTERNET-DRAFT   <draft-ietf-asid-ldapv3-
          protocol-07.txt>, August 1997.

[rfc1034] Mockapetris, P., "Domain Names  -  Concepts  and  Facilities",
          Request for Comments (RFC) 1034, November 1987.

[ldapv3-2]Wahl, M., Coulbeck, A., Howes,  T.,  Kille,  S.,  "Lightweight
          Directory Access Protocol (v3): Attribute Syntax Definitions",
          INTERNET-DRAFT     <draft-ietf-asid-ldapv3-attributes-07.txt>,
          August 1997.

[x500]    "Information Processing Systems - Open Systems Interconnection
          -  The  Directory: Overview of Concepts, Models and Services",
          ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988.

[v3ext]   Yaacovi, Y., Wahl, M., Genovese,  T.,  "Lightweight  Directory
          Access  Protocol  (v3):  Extensions for Dynamic Directory Ser-
          vices",    INTERNET-DRAFT     <draft-ietf-asid-ldapv3-dynamic-
          06.txt>, September 1997.

[rfc1279] Kille, S., "X.500 and Domains",  Request  for  Comments  (RFC)
          1279, November 1991.

9.  Authors' Addresses

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA
   +1 415 937-3419
   howes@netscape.com

   Luke Howard
   PO Box 59
   Central Park Vic 3145
   Australia
   lukeh@xedoc.com



Howes & Howard                                                  [Page 4]


Expires March 1998                                        INTERNET DRAFT





















































Howes & Howard                                                  [Page 5]