9 Directories – More Than Just Information Storage 9.1 Introduction Directories are rapidly becoming the cornerstone to delivering flexibility for advanced services, both as means of storing location information, user configuration and resource privileges and as a means of storing service- specific information allowing for rapid provisioning of customers and rapid modification of services. One of the key issues that directories will resolve for the next-generation networks is the dynamic nature of the future services and the desire to reach services based on useful text- based naming. In the previous chapter on representing information we explored a number of exciting uses of Extensible Markup Language (XML) to allow applications to discover and use services, none of this discovery process would work without directories. I start this chapter with a brief look at the domain name system (DNS), possibly the best-known directory system, since most of us use it every day. I continue the chapter by looking at X.500 and Lightweight Directory Access Protocol (LDAP). X.500 is the International Telecommunications Union (ITU) standard for directory technologies and whilst complex is arguably the most influential of all the directory technologies. We then take a look at the concept of meta-directories, directory systems that link other directories together. Next Generation Network Services Neill Wilkinson Copyright q 2002 John Wiley & Sons, Ltd ISBNs: 0-471-48667-1 (Hardback); 0-470-84603-8 (Electronic) 9.2 Domain Name System (DNS) The DNS was created to overcome the scaling problems associated with the distribution of a text file (hosts.txt) based database that listed all the hostnames and their Internet protocol (IP) addresses. The main part of the DNS is the definition of a hierarchical naming scheme based on a domain model and a distributed database (directory). Two application components are used to interrogate the database, a ‘resol- ver’ for the client application to use and a server application called the ‘domain name server’ that accesses the directory and responds to the query. The hierarchical naming scheme in the DNS breaks the address space into an upside-down tree structure, with several hundred Top-Level Domains (TLDs) sitting at the top of the tree, with one single un-named root. The structure of the tree is reflected in the namespace by the use of periods (.) that separate branches and leaf nodes (branches and leaves being known as labels). For example www.telecomsoapbox.org.uk, www is the leaf, telecomsoapbox a branch of the org branch, which itself is a branch of the TLD uk. Figure 9.1 shows this represented as an upside- down tree. We mentioned above that the database is distributed; this is achieved by virtue of the hierarchical address space. For example I own the domain telecomsoapbox.org.uk. If I chose to run my own domain name server for this domain, I could choose any name I liked within this namespace, for example my PC on my desk has the name neillspc (original I know!) and in the telecomsoapbox.org.uk domain it is neillspc.telecomsoapbox.or- g.uk. DIRECTORIES – MORE THAN JUST INFORMATION STORAGE116 Figure 9.1 DNS name space tree OK so that’s fine and dandy, I can create my own names for my own addresses, but how does anyone find these out or for that matter actually contact the host which, whilst the name is useful to humans, computers like to refer to computers on the Internet by their IP address. That’s where the resolver and the domain name server come in. When an application (say a web browser) gives the resolver a name, www.telecomsoapbox.or- g.uk for instance, what the resolver does is issue a dns request to the domain name server giving it the name, the server responds with the ‘resource records’ for that name. Now in most cases that is just an IP address, but other resource records exist (start of authority – SOA, mail exchange – MX, name server – NS, etc.). The last paragraph explained the records and that a name server is responsible for delivering the results of the query, but clearly you need to be able to connect to a name server in the first place and since we’ve already said that the DNS is distributed and each domain can run their own server, then there’s clearly more than one. These multiple servers are grouped into ‘zones’, with each zone having an authoritative name server (essentially the root of that zone). When a resolver needs to query a name server, it queries its local one, which is usually configured in the host either manually or via dynamic allocation using for example Dynamic Host Configuration Protocol (DHCP). The local domain server may not know anything about the name it has been given, so it sends the query on to the TLD server for the domain requested. If the top-level server does not know the address, it must refer it to one of its children and so on until the server that is the authority for that domain is found. The response finds its way back down the chain. The alternative to this chaining mechanism is for the name server to respond with the address of another name server that may know the answer (referral). In this case the resolver must try this address instead and so on. Also clearly it is inefficient to keep repeating a long path to an authoritative source, so most domain name servers keep a cache of addresses with time to live fields so that they know when to flush the cache. That’s a very brief encounter with the DNS, the salient point is that the DNS is what runs the name resolution mechanism of the Internet. The records held by the domain name servers are added to over time to be able to resolve different entities for example the use of a SRVrecord (RFC 2782) has been proposed to include the identity of Session Initiation Protocol (SIP) servers for a particular domain. The most recent development around the DNS is under the ENUM working group in the Internet Engi- neering Task Force (IETF). The working group is looking to add telephone number records to the DNS database that will allow translation to for example Uniform Resource Locators (URLs). The idea is that a telephone number might be used to reference a number of services. 9.2 DOMAIN NAME SYSTEM (DNS) 117 9.3 X.500 and LDAP X.500 is a collection of recommendations for the organisation, storage and publication of directory information. The main downside, some might say, about X.500 is its size, complexity and reliance on the OSI protocol stack. To a degree all this is true, but with the use of the recommendations in RFC 1006 (OSI applications over IP) and a cut down ‘light’ version of the directory access protocol (LDAP), X.500 directories represent power- ful, accessible repositories of information. OK the basics; like the DNS, X.500 specifies a structure to the informa- tion in the directory in a hierarchical way, this is called the Directory Information Tree (DIT). The top of the tree is referred to as the ‘root’, branches and leaves are referred to as ‘containers’ and there is also a pointer or ‘alias’ element, which allows referrals to other leaves of the DIT. A DIT that has been populated with information is known as a Directory Information Base (DIB). The directory server(s) is organised into authorities or organisations, known as the Directory Management Domain (DMD). Each directory server is known as a Directory Systems Agent (DSA) and the equivalent client application to the DNS resolver is called a Directory User Agent (DUA). DUAs interrogate directories through DSAs and the three mechanisms for finding information are chaining, referral and multicast. The first two are the same as the operations described for the DNS, multicast is where the DSA sends a request to multiple other DSAs either in parallel or sequentially. The way a DUA communicates to a DSA is through the Directory Access protocol (DAP), the original DAP communicated through the OSI stack, which made for a complex DUA that was difficult to implement on early PCs. The IETF RFC 1006 combined with a light version of the DAP – LDAP. LDAP version 3 is specified in RFC 2251 and is supported by RFC 2252 which describes the syntax of the attributes of the directory to help define the directory schema for use with LDAP and RFC 2849, which describes the LDAP Data Interchange Format (LDIF) used to import and export information from an LDAP directory. Unlike the DNS which is organised around the resolution of servers and server addresses, X.500 is organised around geographic, organisa- tional and people elements. This has been found to be restrictive and alternative schemas have been proposed including incorporating the DNS scheme into an X.500 directory. That was also a whistle-stop tour of X.500 and doesn’t cover all the aspects of X.500, but hopefully gives a flavour of what it is about. XML has also got a place in defining a schema for an X.500 directory server, DirXML has been proposed and also Directory Services Markup Language (DSML – see www.dsml.org) as a means of mapping directory DIRECTORIES – MORE THAN JUST INFORMATION STORAGE118 information obtained from LDAP queries into an XML document. The idea behind this is to allow easy access to multiple directory sources through a standard specification. The ideas of DSML bring us nicely to meta-directories…. 9.4 The Meta-Directory A meta-directory simply put is a consolidation point for information from multiple directory sources and is proposed to link organisational (inter- nal) directories to external directories. The idea is to provide a single point solution for application to access that can transparently synchronise the update of information from multiple data sources. A meta-directory is as much a data management process as it is a directory in its own right, and relies heavily on technologies such as LDAP and DSML to provide the glue to consolidate the multiple data sources. Meta-directories will become increasingly important in the next- generation network. As applications get more complex and more intelli- gent, the need to synchronise information across multi data sources such as: provisioning databases, authentication, profiles, enterprise databases, service capability database (such as Home Location Registers (HLRs) and Service Data Points (SDPs)) and operational support and business support systems, will increase. Not to mention finding services that are out there. In Chapter 8, a discussion of Universal Description Discovery and Integration (UDDI) was put forward under the topic of representing information. UDDI is more than just this and represents a cornerstone in the web services infrastructure as a meta-directory of services, and how to find and communicate with them. 9.5 Other directory technologies and ideas There is currently a proliferation of directory technologies that this short chapter cannot hope to cover, listed below are just some these: † Microsoft’s Active Directory. This is used in Microsoft networks from Windows 2000 onwards as a distributed repository of information about the users, applications and devices present on the network. † NetWare NDS. This provides a distributed system similar to that of Active Directory. † The Common Information Model (CIM), network management and the Directory Enabled Network (DEN) proposals. † Service data points and HLRs (see Chapter 4). † Remote Address Dial-In User Service (RADIUS) server. This is used to control admission to dial-up network resources. 9.4 THE META-DIRECTORY 119 I hope this chapter has given a taste of directories and their importance in the next-generation networks. I suggest for a more complete explana- tion of directories and their technologies the reader looks up [KAMP]. DIRECTORIES – MORE THAN JUST INFORMATION STORAGE120 . JUST INFORMATION STORAGE118 information obtained from LDAP queries into an XML document. The idea behind this is to allow easy access to multiple directory