Large scale network management databases in X.500

Peter Sylvester -- INRIA Roquencourt


Products implementing X.500 directory systems become more and more available. It is important to evaluate the behaviour of such products. The data used for the management of large scale networks seem to be an ideal candidate for such tests regarding the structure, size, and usage requirements of such databases. The definition of X.500 directory schemes can greatly benefit from experiments involving large databases, and from requirements of wide area network operation/information centers.

This presentation describes some experiences from experiments made with the database that is used to manage the infrastructure of the European Academic and Research Network (EARN) and cooperating network organizations such as BITNET or NetNorth. After an overview of the historical background of the work and some experiences gained earlier, the following aspects are discussed: definition of an appropriate scheme to allow easy integration with existing X.500 pilot services, as well as maintaining the intentions of the original database structures, global consistency of distributed data and update procedures. The selected solutions are compared with other possibilities concerning the representation of network configuration information.

The work is not related to any activity of the EARN association. The EARN database has been used as an example to demonstrate the possibilities of X.500.


The distributed directory service standard developed by ISO and CCITT commonly known as X.500 is currently being used in world wide connected pilot services for various purposes. The pilots provide user directory services including support for message handling systems, X.400 as well as Internet Mail. Interoperability tests and design experiences of X.500 implementations are also an important aspect of these pilots operations.

Directory systems are a fundamental requirement for all communication systems. Data bases describing computer networks are used for several purposes. They allow computer experts and networks administrators to find out details about the installed systems or to find contact persons to resolve network operational problems. In addition they contain the information to create network routing information, or parameters of distributed network applications. Since the database is the key information of a large networks, the quality of such databases must be ensured. Although this leads to the requirement of centrally managed data, there are as well the requirements of distribution of the data and acquisition of network information from those network entities who own certain data.

Standardized distributed directory service are needed in order to avoid proprietary solutions as much as possible. General interfaces should allow a simple and user friendly access for everybody who needs to use the network. Network specific tasks need specialized interfaces to the directory service, the directory service should be able to support such tasks to a great extent. Therefore it is useful to study the usability of X.500 as a means to support the directory service used to manage computer networks.

Historical background

The network management databases of EARN and its associated networks has a long history of modifications and enhancements. In 1984, when the networks EARN and BITNET joined to become a common network, a first compromise had to be found. After that, the EARN view of the data was used more and more in the common network due to an efficient way to distribute all information to all interested parties in the network. The structure of the database was revised in 1988 as a consequence of new requirements and better understanding of the network needs. The final implementation took place in 1991 after adopting existing user interfaces, and applications.

Already during the redefinition phase some attempts to use X.500 have been made. The goals of a joint IBM-GMD project N.I.C.E (Network Information Center Environments) were to develop user interfaces for the EARN NETSERV on other operating system platforms than the original IBM VM, and to study the usage of X.500 in order to distribute and access EARN information. Stefan Fassbender, GMD studied the implementation requirements for database systems to support X.500 [FASS].

After the switching to the new database format during my work at INRIA Rocquencourt I had the opportunity to test an X.500 implementation, namely UCOMX500 from the E3X company. It was obvious that I would try to use the ideas of the past work. With some help of my colleague Paul-Andre Pays I installed the DSA component of the product on a SUN IPX workstation during some rainy evening. The UCOMX500 product supports a bulk data textual load format. Since the EARN database is also in textual format the remaining task was to develop a kind of text formatting tool. This was a good chance to learn PERL. (After some 18 years of playing with IBM mainframes, I am now having fun with Unix machines.) After a few days I was ready for some real experiments.

The EARN database and syntax oriented representations in X.500

A complete description of the database, i.e., the so-called NODES FILE or BITEARN NODES, can be found in a document named NEWTAGS DESCRIPT available in each EARN NETSERV [NODE]. The database is used in BITNET, EARN, NetNorth and other networks to hold and distribute information about these nodes in the network, about the organizations running these nodes and about people who perform certain roles in relation to the network. The main purpose for which the database is used are: generation of routing tables, identifying network-related people to the network coordinators, to other people and to servers/programs, and to provide a set of information about nodes, e.g, hardware/software), sites and members (e.g., names, locations).

The database contains entries and tags. An entry describes a node, a site, or a member. Each entry consists of a set of tags, i.e., keyword/value pairs hold some information. Each entry has a special tag where tha value defines a unique name for the entry. Without further interpretation this structure can already be used for a mapping into X.500. At this point in time one of the most important requirements for the experiment has to be mentioned. Although the UCOMX500 software allows an arbitrary definition of object classes and attributes with fixed attribute syntaxes, I did not want to use this approach because this would have required updates in all DSA/DUAs in the world wide X.500 pilots. In other words, I had to find some existing object classes and attributes so that any (slightly mis)use them. Fortunately that was rather simple.

From the standpoint of the network organization each node is an organizational unit. Under some top level entry (which is also an organizational unit named C=fr; O=inria; OU=earn but should rather be something like C=FR; O=EARN because EARN is a french association) I placed a subtree, and mapped each entry to an organizational unit. For the first mapping only the attribute common name is used for naming and searching. All tags belonging to one entry are represented as organizational roles in a subtree; the name of the tag is mapped to a common name, the value to a DESC attribute. The result of this mapping was a subtree with more that 100000 entries. The DSA running on my small workstation (only 16Mo storage) was not able to manage this. After restricting the conversion to one third of the database, namely the EARN information, it was possible to store the information, and there was some space left.

Structure of first mapping:

      EARN:   :node.nodeid :tagname.tagvalue

     X.500:   <C=FR; O=INRIA; OU=EARN; OU=nodeid> = 
                 <Class      = top+organizationalUnit;
                  OU         = "nodeid"
              <C=FR; O=INRIA; OU=EARN; OU=nodeid; CommonName="tagname"> = 
                 <Class      = top+organizationalRole;
                  CommonName = "tagname";
                  DESC       = "tagvalue"

I also tried another syntax oriented mapping. I mapped all tags into multiple values of a DESC attribute of the organizational unit representing the node; the keyword/value pairs (tagname/tagvalue) was represented as tagname:tagvalue in one of the values of the DESC attribute. I had no problem storing these information into the database. In fact, I have a complete database using the first mapping for EARN subset of the data and the other mapping for the other network's data.

Structure of second mapping:

      EARN:   :node.nodeid :tagname1.tagvalue1 :tagname2.tagvalue2

      X.500:   <C=FR; O=INRIA; OU=EARN; OU=nodeid> = 
                 <Class      = top+organizationalRole;
                  OU         = "nodeid"
                  DESC       = "tagname1:tagvalue1"+

In both mappings I actually made a slight variation due to some knowledge about the structure of the tags. Some tags contain multiple values, and some of such tags are split into several ones due to length restrictions. In the X.500 version the information is recombined and split into multiple values at their semantic boundaries.

What are the results so far? Each existing user agent that knows about the schemes in the PARADISE pilot can be used to access the data. If a user has the knowledge to interprete the tags, the X.500 version can be used in a very similar way. None of the possibilities of X.500 had been used to assist the usage of the data. The definition of the EARN database consists of several rules for inheritance of information, i.e., if some normally required data are missing in one entry, they can be found either in another tag, or in some other entry. Examples: Certain roles like a network operator or user information manager are optional, the required administrator is responsible for these roles if they are not explicitely given. A telephone number, the administrator, or the director of an entry may not be defined in an entry if there is a higher level entry (site or member). The user interfaces used in EARN hide these details. Specialized DUAs can provide the same functionality on the user interface level. But let us see how pure X.500 features can be used to enhance the usability.

Enhancements to the mappings

In order to enhance the mappings more knowledge about the semantics of the tags has to be used. For certain tags one can easily find attributes, like a fax number, a postal address, telephone number, thus a mapping uses an appropriate attribute in the organization unit describing the entry.

Another parts of the tags consists of the definition of persons, and roles pointing to such persons. I have defined the tags defining persons by objects pilotperson, and mapped the structure information of the tags to attributes of this class. The obvious question at this point is: what about user friendly naming? The RDNs created from the original database are not user friendly. There is no way and it useless to attempt a user friendly naming at this point. Actually the pilotperson object created contain a two values for commonname, one is identical with the RDN, e.g., p_ps and the other contains the first component of the tagvalue with is the supposed user friendly name. Christian Huitema has discussed such naming problem in his presentation [HUIT], see also RFC 1430 [HKH] for a discussion of allocation of names.


   EARN:    :p_ps.Peter Sylvester;;+33 1

   X.500:   <CommonName = "p_ps"> = 
                 <Class      = top+person+organizationalPerson+pilotPerson;
                  CommonName = "p_ps"+"Peter Sylvester";
                  Phone="+33 1"

The values in the so-called role-tags like network operator, director, entry administrator, technical representative are actually a list of tagnames for persons, so the mapping of such tags can for example be done with a multiple value of See-Also attributes.


   EARN:    <CommonName = "admin"> =
                 <Class      = top+organizationalRole;
                  CommonName = "admin";
                  SeeAlso    = <C=FR;O=INRIA;OU=EARN;OU=node;CN="p_ps">

The inheritance mechanisms of the original database can be simulated in two ways: Values can be explicitely copied into lower level entries, or (in the first syntax oriented mapping) alias entries to the higher level entries can be added. In the second way one would maintain the original structure. None of this was done in the experiment.

Steve Hartcastle-Kille [HK] defines techniques to represent flat tables in the directory. The technique is useful to map the links-tags. The links tags in a NJE-entry define all the outgoing connections and their characteristics to other NJE-entries, in other words these tags define the topology of the network. In my first mapping I have represented the network connections as multiple values of a DESC attribute. This technique does not allow to read a specific connection as a single entity. Since the proposed object classes for flat tables are not used in all x.500 pilots I did not use the proposal for an experiment.

At this point it was clear that further modifications to the experiment would not lead to many new experiences. Further enhancements would require to change the flat naming tree to a hierarchy which is defined in the BITEARN NODES data, the hierarchy of members, sites, and nodes. This cannot be done easily with a pure syntax oriented mapping, i.e., the syntactical flexibility of the data allows the representation of several administrational structures which cannot be handled in a general way in a small experiment.

Attributes versus subtrees

The proposal to represent the IP network of the Internet using X.500 from Glenn Mansfield et al [MJK] allows to make some comparisons.

The flexibility of the EARN database allows to add new tags to any entry without effects to the rest of the data. Therefore it is not possible to represent each tag using an separate attribute in one new object class without loosing a lot of this flexibility. Each modification of the information would require the addition of another attribute to an object class. This flexibity had always been used to introduce new tags for new functions. In addition new experimental tags have never been verified by the central verification procedures. This aspect was another reason to represent all tags as subordinate entries, and not as attributes.

The other approach is used for example in the proposal to represent the IP network using X.500. If the semantics and pragmatics of the data are well defined and stable, the risk of required modifications is very small. In addition images or views of objects as proposed in [MJK] can be used to support extensions for different applications.

The 1992 versions of the X.500 standard provide for enhancements about the management of schema information using the directory itself. This is a necessary requirement for a real open environment. DUAs and DSAs will be able to handle objects and the structure of objects without previous knowledge.

Acquisition and distribution of data

The databases defining large network are central databases. For critical information, e.g., topology information, a consistent flat name space cannot be maintained otherwise. But there are possiblities to use X.500 to allow a distributed maintenance. Each country maintains its portion of the network in a separate subtree. In regular intervals these subtrees are collected and a new global version is created after some consistency verification. This is very close the actual procedure used in EARN (based on countries).

Some information is not critical and does not need to be replicated. If the main purpose of the network orgnaization is to ensure the connectivity of the network then only these data, e.g., the links tags of an NJE-entry and a few others need to be replicated and verified in the central network copy. The global entry would contain a pointer to the entry containing the remaining data.


Using the example of the EARN network database several aspects concering the representation of network data bases using X.500 have been shown. Although the discussed solutions are definitely influenced by the example, ome general considerations and requirements for such efforts have been shown. X.500 can been used to maintain network configuration data, and existing implementations of X.500 are able to handle the data.


FASS: Fassbender S., Entwurf und Realisierung eines modularen Datenbanksystems zur Unterstuetzung von X.500-Directory-Diensten, Universitaet Bonn, September 1990.

NODE: Nodes File Format and Contents, NEWTAGS DESCRIPT in NETSERV

BARK: Barker, P.; Kille S., "The COSINE and Internet X.500 Schema", RFC 1274, University College London, November 1991.

MJK: Mansfield, G.; Johannsen, T.; Knopper, M., Charting Networks in the Directory, Internet Draft Proposal, October 1992

HUIT: Huitema, C., "Naming: strategies and techniques", Computer Networks and ISDN Systems 23, proceedings of the second JENC Blois, France, 1991.

HKH: Hartcastle-Kille, S.; Huizer, E., A Strategic Plan for Deploying an Internet X.500 Directory Service, RFC 1430, February 1993

HK: Hartcastle-Kille, S., Representing Tables and Subtrees in the Directory, Internet Draft, University College London, April 1992

X500: CCITT/ISO, "X.500, The Directory - overview of concepts, models and services, CCITT/ISO IS 9594.

Copyright - Peter Sylvester 1992 - All rights resserved