One document matched: draft-ietf-asid-ldapv3ext-00.txt

Expires in six months from                                              
    13 June 1996
Intended Category: Standards Track


                   Lightweight Directory Access Protocol:
                 Extensions for Dynamic Directory Services



1. Status of this Memo

This document is a proposal for extending an Internet-Draft. Internet-
Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups.  Note that other groups may 
also distribute working documents as Internet-Drafts.
 
It is expected that the proposed extensions in this memo will eventually
be folded into the LDAP V3 draft.

2. Abstract

The Lightweight Directory Access Protocol (LDAP) [1] supports
lightweight
access to static directory services, allowing relatively fast search and

update access. Static directory services store information about people 
that persists in its accuracy and value over a long period of time. 
Dynamic directory services are different in that they store information
about people that only persists in its accuracy and value while people 
are online. Though the protocol operations and attributes used by
dynamic
directory services are similar to the ones used for static directory 
services, clients that are bound to a dynamic directory service need to 
periodically refresh their presence at the server to keep directory 
entries from getting stale in the presence of client application
crashes.

A flow control mechanism from the server is also described that allows a

server to inform clients how often they should refresh their presence. A

precursor of this mechanism was previously described in [2].

3. Extensions for dynamic directory services

The main extension we propose to add is the ability for the client to 
refresh its presence with the server. This refresh is achieved by 
sending Refresh requests from the client to the server. The server 
can control the rate of these requests and their frequency by sending 
refresh responses.

We propose to add Refresh as an LDAP V3 protocol operation, as follows:

   LDAPMessage ::= SEQUENCE {
           messageID       MessageID,
           cldapUserName   LDAPDN OPTIONAL,
           protocolOp      CHOICE {
                   <Currently defined LDAP V3 operations>


Yaacovi and Settle                                              [Page 1]
Internet Draft   Dynamic Directory Extensions for LDAP         June 1996


                   refreshRequest   RefreshRequest,
                   refreshResponse  RefreshResponse } }

We expect these protocol operations to be connectionless LDAP
operations.


3.1. Refresh Request

Refresh is a protocol operation sent by a client to tell the server that

the client is still alive and the directory entry is still accurate and 
valuable. The client sends a Refresh request periodically based on the 
value of the client refresh period (CRP). The server can request that 
the client change this value. As long as the client sends a Refresh 
request within the CRP,the directory entry is guaranteed to persist on 
the server.

   RefreshRequest ::= SEQUENCE  {
           version         INTEGER (1 .. 127)
           clientID        INTEGER       } }

Parameters of the Refresh request are:

- version: The value of this field should be the LDAP protocol version.
- clientID: A client identifier. When a Refresh  request arrives at the
server, the server will use the clientID to quickly find the appropriate
client record and update it.

The cldapUserName provided with the Refresh request could serve as the 
sending client's identifier. The DN is guaranteed to be unique, but can 
consume substantial bandwidth for such a frequent request and it might 
not be quickly accessible at the server. We propose that the server 
assign client identifiers to clients. This can be done as a return value

to the Add request. The server implementation is required to ensure that

the client identifier is unique. The server may optionally use this
value 
to quickly locate the client record in Refresh requests. The client will

specify this value as the clientID in refresh calls.

The initial CRP value will be set by the server through the AddResponse.

Upon any Refresh request from a client, the server may respond with a 
new CRP value through a Refresh response.

Note that the server might assign a separate Time-To-Live (TTL) value
for 
client at the server. The TTL should always be higher than the client
CRP.

3.2. Refresh Response

By sending a Refresh response, the server acknowledges the receipt of a 
Refresh request, and can optionally dictate to the client a lower or 
higher CRP value. This will cause the client to send more frequent or 
less frequent Refresh request messages, respectively. A Refresh response

is required.

   refreshResponse ::= SEQUENCE {
          LDAPResult      LDAPResult,


Yaacovi and Settle                                              [Page 2]
Internet Draft   Dynamic Directory Extensions for LDAP         June 1996


          newCRP          INTEGER (1 .. 32767) } }

Parameters of the Refresh response are:

- newCRP: The period of time, in minutes, that the client is guaranteed 
to be registered and available at the server without sending Refresh 
requests.

If the server cannot find the client, it will respond with the
resultCode
of compareFalse. This will be an indication to the client that it needs 
to re-establish its presence at the server.


3.3 Modification to AddResponse

Refresh requests need to send the clientID as part of the request. The 
client ID is assigned by the server and will be sent to the client in 
the AddResponse.This requires the following change in the AddResponse.

   AddResponse ::= SEQUENCE {
          LDAPResult      LDAPResult,
          clientID        INTEGER OPTIONAL,   
          CRP             INTEGER (1 .. 32767) OPTIONAL  } }

4. Implementation issues

4.1 Storage of dynamic information

Dynamic information is expected to change very often. In addition, 
Refresh requests are expected to arrive at the server very often. 
Disk-based databases that static directory services often use are 
likely  inappropriate for storing dynamic information. We expect 
server implementations to store the dynamic attributes in memory 
sufficient to avoid paging.

If the LDAP static server and the LDAP dynamic server are separate, 
we expect each of these servers to store all the attributes in the 
appropriate storage mechanism (either memory-based or disk-based). 
However, if the same server stores both static and dynamic attributes, 
we expect that the client will tell the server that the set of 
attributes it adds or modifies in a request is dynamic or static. 
This can be achieved by using one attribute (objectClass) to tell 
the server if the list of attributes is dynamic or static. A new
objectClass for real time object (RTObject) can be used for that.

4.2 Transport protocol

We expect refresh requests and responses to be a connectionless LDAP 
protocoloperations over UDP.

Using UDP can reduce the load on the server but can also introduce 
problems. If a Refresh request is lost, it is possible that by the 
time the client times out waiting for the response and resends the 
request, the TTL of the directory entry on the server may expire, 
causing the server to remove the entry. Servers should maintain a 
TTL value for directory entries that is somewhat higher than the


Yaacovi and Settle                                              [Page 3]
Internet Draft   Dynamic Directory Extensions for LDAP         June 1996


client's CRP. In such a case, the Refresh request that the client will 
resend because of a lost response is redundant, but harmless.

4.3 Allocation of client IDs

Client IDs are allocated by the server. The typical server can allocate 
increasing numbers to clients to guarantee uniqueness. The server might 
also use some part of the client ID to allow it to quickly find the 
client record at the server. For example, part of the client ID might 
be the pointer to the client record at the server, which could allow 
direct access to the record by the server.


5. Localization
   
The are no localization issues for Refresh.


6. Security Considerations

There are no security issues for Refresh.


7. Acknowledgments

Robert Carney, Tony Genovese, Max Morris and William Lai had a
significant
part in this proposal.


8. Authors Addresses

       Yoram Yaacovi
       Microsoft
       One Microsoft way
       Redmond, WA 98052
       USA

       Phone:  +1 206-936-9629
       EMail:  yoramy@microsoft.com


       Kent Settle
       Microsoft
       One Microsoft way
       Redmond, WA 98052
       USA

       Phone:  +1 206-936-3027
       EMail:  kentse@microsoft.com





Yaacovi and Settle                                              [Page 4]
Internet Draft   Dynamic Directory Extensions for LDAP         June 1996


9. Bibliography

 [1] M.Wahl, W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access

     Protocol (Version 3)". <draft-ietf-asid-ldapv3-protocol-01.txt>

 [2] R. Williams, "User Location Service". <draft-williams-uls-00.txt>
















































Yaacovi and Settle                                              [Page 5]