44

COSINE Specification Phase

Directory Services and COSINE

E d u a r d o M E N D O Z A Softlab GmbH, Zamdorfer Strasse 120, D-8000 Miinchen 80, Fed Rep. Germany (Tel.." + 49 89 930010)

A Directory is an important building block of a COSINE infrastructure for the European research community. The CCITT X.500 (1988) Recommendations provide a sufficient functional basis for such a COSINE service. Fundamental COSINE requirements have been identified and justify more detailed studies and the initiation of pilot projects. X.500 products will be introduced by a number of vendors from mid-1989.

Keywords: Directory Service, CCITT X.500, Directory In- formation Base, COSINE Requirements, M A P / T O P 3.0 Di- rectory, Directory Access Protocol, Directory System Protocol.

1. I n t r o d u c t i o n

At present, when using COSINE services and applications, users have little support in getting information about remote end-systems, applica- tion entities or communication partners. The main problem in using these services is the time and effort required for getting the information. A COSINE Directory can provide this information in a comfortable manner. Besides being a separate information service, a Directory can be used to support COSINE services such as FTAM and MHS. This paper argues"that a COSINE Direc- tory service based on CCITT X.500 is an im- portant initial building block for a COSINE in- frastructure, due to the following reasons: - the X.500 (1988) recommendations provide a

sufficient functional basis for a COSINE service;

- a short study done by Softlab for COSINE has identified a number of requirements to justify more detailed studies and starting pilot pro- jects; and

- X.500 (1988) products are forthcoming.

2. O v e r v i e w o f t h e X . 5 0 0 D i r e c t o r y S t a n d a r d

Eduardo Mendoza joined Softlab GmbH, Munich, in July 1986, where he is currently Project Manager for OSI. His responsibilities include pro- iects on X.500 Directory, OSl Net- •vork Management and MHS. He was also the Project Coordinator of CeBIT 88 X.400 Multivendor Demonstration. Dr. Mendoza worked as a communi- cations software developer for Sie- mens (1980-1983) and as a consultant for SCS Scicon (1984-1986). He finished his M.S. and Ph.D. in

Mathematics at Bonn University.

North-Holland Computer Networks and ISDN Systems 16 (1988/89) 44-47

Table 1 indicates the C C I T T / I S O Documents which will become international standards by the end of 1988.

The Directory may be viewed by a user as an entity holding a database called the Directory Information Base (DIB) and providing access to this database. The DIB can contain entries for any "object of interest" in the communications en- vironment. Particular characteristics of the DIB are: - it may be distributed, - rate of queries >> rate of updates, - temporary inconsistencies are quite acceptable.

0169-7552/88/$3.50 © 1988, Elsevier Science Publishers B.V. (North-Holland)

E. Mendoza / Directory Seroices and COSINE 45

~ DUA

d e n o t e s a n i n t e r a o t i o n

T h e D i r e c ~ o ~

~1 n)sn I+ -I I-

]O, 1" ]B=

D U A :

D S A :

D i r e c t o r g U s e r A g e n ~

D i r e c t o r w S g s t e m A g e n t

Fig. 1. Functional model.

Table 1 Directory documents

CCITT ISO Title

X.500 9594-1 X.501 9594-2 X.511 9594-3 X.518 9594-4 X.519 9594-5 X.520 9594-6 X.521 9594-7 X.509 9594-8

Overview of Concepts, Models, Services Models Access and System Services Definition Distributed Operations Access and System Protocol Selected Attribute Types Selected Object Classes Authentication Framework

The Directory Functional Model (Fig. 1) con- sists of the DIB, one or more Directory Systems Agents (DSA) and Directory User Agents (DUA), the latter representing users--humans or applica- t i o n s - o f a Directory. Each DSA will provide

direct access to the information it holds a n d - - b y communicating with other DSAs via the Directory System Protocol (DSP) - - to the complete DIB. If DUA and DSA are located in different open systems, the Directory Access Protocol (DAP) is used to transmit requests and results between them.

An entry in the DIB consists of one or more attributes, each one describing one property of the "object of interest". Figure 2 illustrates the struc- ture of an entry. An entry belongs to an "object class", which determines the mandatory and per- missible attribute types in the entry. The X.500 standard defines an extensive set of object classes and attribute types (cf. X.520, X.521), covering the general needs of current telecommunications ap- plications. The standard also introduces the sub- class mechanism, which can be used to introduce

I [ ~ ~ i ! ! P ~ ~ I I'+~++~++++:,+1 I ENTRY ~?:.~:~:~:~:~.A:~.:~:~:~::....,::~:~...~:~:::,...::: • • t :~::~::. ========================== ::::::.:::::::

+ ATTRI!UTE ................................................................ + + : ................................. ...............

H Typ. !+#~+] v ~ + i l

I " . . . . . . . . . . . . . . : " " ' ' 1

Fig. 2. Structure of an entry.

4 6 E. Mendoza / Directory Services and COSINE

R o o t

O r g a n i z a t i o n a l U n i t

~-7 P e o p 1

RDN .{).

{ C : U I < )

{ O : T e l e c o m )

{ O U = S a l e s }

{ C N = S m J . t h )

Distinguished Name

{ )

{ C = U I < )

{ C : U I < , 0 T ~ l ~ c o m } -

{ C = U K , O = T e l e c o m . O U = S a l e s )

{ C = U K , 0 T e l e c o m , O U = S a l e s , C N m S m i t . h }

Fig. 3. Determination of distinguished names.

new attribute types in standardized classes or to define new object classes. Specific needs of users can thus be met, and object classes for "pr ivate" use may be "invisible" for interconnected systems.

The X.500 standard uses a hierarchical ap- proach to solve the problem of managing a (potentially) worldwide name space in a flexible and user-friendly way. Each entry has a Relative Distinguished Name (RDN), which consists of one or more attribute values and is chosen when the entry is created. The R D N is unique among the entries with same superior mode. The entry Distinguished Name (DN) is the concatenation of the RDNs of all superior entr ies--s tar t ing at the

hypothetical entry r o o t - - a n d its own RDN. Fig- ure 3 gives an example of X.500 naming.

The Directory provides the following interroga- tion services: - R e a d : to read a particular entry when some or

all the attributes of that entry are to be re- turned;

- C o m p a r e : to check whether a supplied value matches a value of a particular attribute of an entry;

- L i s t : causes the Directory to return a list of immediate subordinates of a particular entry in the DIB;

- S e a r c h : causes the Directory to return informa-

User

l u s e r e l e m e n t ]

I D R S E D A P

u s e r e l e m e n t I

D R S E I

.-II-++f I---t

I ) S P

u s e r e l e m e n t

D A S E

"-Jl- p r e s e n t , a t , i o n - c o n n e c t , i o n

DASE = ACSE = ROSE :

D i r e c t o r U R p p l i o a t i o n S e r v i c e E lemen ts l~sso©ia t ion C o n t r o l S e r v i c e E l e m e n t s Remote O p e r a t i o n S e r v i n e E lemen ts

Fig. 4. Directory protocol model.

E. Mendoza / Directory Services and COSINE 47

tion from all entries within a certain portion of the DIB which satisfies the filter conditions;

- Abandon: applied to an outstanding interroga- tion request to inform the Directory that the requestor is no longer interested in the result.

Modification services provided are: Add Entry, Remove Entry, Modify Entry and Modify RDN.

Figure 4 illustrates the Directory Protocol Model.

COSINE applications like FTAM and MHS will be more effective and useful, if they can avail of Directory Services. Directory uses of MHS include storing of distribution lists, user agent capabilities, support of MHS administration (organizational domains, responsibilities, user authentication) and MTA-routing information.

COSINE requirements not addressed by X.500 (1988) include access control and Charging and Accounting Procedures.

3. C O S I N E R e q u i r e m e n t s f o r D i r e c t o r y S e r v i c e s

COSINE users need information in a number of different areas, as shown by the present IES ECHO service. The requirements include informa- tion on - general purpose data associated with COSINE

users (location, etc.), - facilities, end-systems, devices, - projects, applications and services, - conventions and responsibilities, - documents.

A COSINE Directory should provide services for "white page" queries (name to entry informa- tion mapping) and "yellow page" access (incom- plete description to list of entries matching). A user-friendly interface is very important for this information service.

4. P r o d u c t s

MAP/TOP 3.0 has specified a Directory Service based on an early version of X.500. The initial implementation of this is a central directory re- motely accessible via the DAP. Products based on this specification will be available by the end of 1988. Several vendors will introduce X.500-based distributed Directories by mid-1989.

A c k n o w l e d g m e n t

This paper is based mainly on "COSINE Study on Directories" authored by my colleagues A. Biber and J. Forster.