Directory services and COSINE

44

COSINE Specification Phase

Directory Services and COSINE Eduardo MENDOZA 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 C C I T T 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 n u m b e r of vendors from mid-1989.

Keywords: Directory Service, C C I T T X.500, Directory Information Base, COSINE Requirements, M A P / T O P 3.0 Directory, Directory Access Protocol, Directory System Protocol.

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

At present, when using C O S I N E services and applications, users have little support in getting information about remote end-systems, application entities or communication partners. The main problem in using these services is the time and effort required for getting the information. A C O S I N E Directory can provide this information in a comfortable manner. Besides being a separate information service, a Directory can be used to support C O S I N E services such as F T A M and MHS. This paper argues"that a C O S I N E Directory service based on C C I T T X.500 is an important initial building block for a C O S I N E infrastructure, due to the following reasons: - the X.500 (1988) recommendations provide a sufficient functional basis for a C O S I N E service; - a short study done by Softlab for C O S I N E has identified a number of requirements to justify more detailed studies and starting pilot projects; and - X.500 (1988) products are forthcoming.

2. O v e r v i e w

Eduardo Mendoza joined Softlab G m b H , Munich, in July 1986, where he is currently Project Manager for OSI. His responsibilities include proiects 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 communications software developer for Siemens (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

of the X.500 Directory

Standard

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 environment. 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

~

The

45

D i r e c ~ o ~

~1 n)sn I+

DUA

-I

I-

]O, 1" ]B= denotes an interaotion

DUA:

Directorg

User

DSA:

Directorw

Sgstem

Agen~ Agent

Fig. 1. Functional model.

Table 1 Directory documents CCITT

ISO

Title

X.500 X.501 X.511 X.518 X.519 X.520 X.521 X.509

9594-1 9594-2 9594-3 9594-4 9594-5 9594-6 9594-7 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

direct access to the information it holds a n d - - b y communicating with other DSAs via the Directory System Protocol ( D S P ) - - t o the complete DIB. If D U A 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 structure of an entry. An entry belongs to an "object class", which determines the mandatory and permissible 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 applications. The standard also introduces the subclass mechanism, which can be used to introduce

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

I [~~i!!

P~~I

~?:.~:~:~:~:~.A:~.:~:~:~::....,::~:~...~:~:::,...:::•

•

t

I'+~++~++++:,+1 I ENTRY :~::~::.===================== ::::::.::::::: =====

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

H

I "

..............

Typ.

++: ................................. ...............

!+#~+] v~+il

:

"

"

Fig. 2. Structure of an entry.

'

'1

E. Mendoza / Directory Services and COSINE

46

Distinguished Name

RDN .{).

Root

{)

{C:UI<)

{C=UI<)

{O:Telecom)

Organizational Unit

{C:UI<,

T~l~com}-

0

{OU=Sales}

{C=UK, O=Telecom. OU=Sales)

{CN=SmJ.th)

{C=UK, 0 Telecom, OU=Sales, CNmSmit.h}

~-7 Peop1

Fig. 3. Determination of distinguished names.

hypothetical entry r o o t - - a n d its own R D N . Figure 3 gives an example of X.500 naming. The Directory provides the following interrogation services: Read: to read a particular entry when some or all the attributes of that entry are to be returned; Compare: to check whether a supplied value matches a value of a particular attribute of an entry; List: causes the Directory to return a list of immediate subordinates of a particular entry in the DIB; Search: causes the Directory to return informa-

new attribute types in standardized classes or to define new object classes. Specific needs of users can thus be met, and object classes for "private" use m a y be "invisible" for interconnected systems. The X.500 standard uses a hierarchical approach to solve the problem of managing a (potentially) worldwide name space in a flexible and user-friendly way. Each entry has a Relative Distinguished N a m e (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 N a m e (DN) is the concatenation of the R D N s of all superior entries--starting at the

User luser

element]

user

I

DRSE

user

element I

DAP DR

SE

DASE

I

.-II-++f present, DASE = ACSE = ROSE :

element

I)SP

I---t

at, i o n

- connect,

"-Jlion

Director U Rpplioation Service Elements l~sso©iation Control Service Elements Remote Operation Servine Elements Fig. 4. Directory protocol model.

E. Mendoza / Directory Services and COSINE

tion from all entries within a certain portion of the DIB which satisfies the filter conditions; Abandon: applied to an outstanding interrogation 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. -

3. C O S I N E

Requirements

for Directory

47

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.

Services

COSINE users need information in a number of different areas, as shown by the present IES ECHO service. The requirements include information 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 information mapping) and "yellow page" access (incomplete 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 remotely 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.

Acknowledgment

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