Tài liệu Dịch vụ mạng thế hệ kế tiếp P9 doc

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