Integration of the Directory Service in the Network ... - CiteSeerX

Integration of the Directory Service in the Network Management Framework  James W. Hong, Michael A. Bauer and J. Michael Bennett Department of Computer Science University of Western Ontario Abstract

This paper examines the potential role and feasibility of using the X.500 Directory Service in the network management framework. We examine the network management requirements and investigate how the Directory Service can satisfy them. A simple network load monitoring tool was adapted to use a prototype X.500 Directory Service (Quipu) for the storage and retrieval of (1) network domain information, (2) host information, (3) network monitoring tool application information, and (4) network management information. We report on our experiences using Quipu and assess the appropriateness of using the Directory Service to provide support for network management information.

Keyword Codes: C.2.4; C.2.3; H.3.4 Keywords: Distributed Systems; Network Operations; Information Systems and Software

1 Introduction Managing networks involves generating and collecting a vast amount of information about a variety of managed objects throughout the network. Information gathered may relate to current device con gurations, recent faults, accounting information, security and performance. Information about the managed objects must be stored somewhere in the network so as to be accessible to the management tools. Some of the collected information about these managed objects must be stored and updated periodically in order to provide information for other network applications or services (e.g., network load monitoring). The Directory Service, proposed by the X.500 Standards [CCIT88, CCIT92], has been designed as a distributed repository of information. Recently, many commercial and non-commercial implementations of the Directory Service have been made available to users [Lang92]. However, their primary uses have been limited to providing directory services of human information (e.g., names, phone numbers, addresses). In this paper, This paper has been published at the Third International Symposium on Integrated Network Management, San Fransisco, CA, April 1993, pp. 149-160 

1

we investigate the possibility of using the Directory Service as a repository of information other than human information, network management information for example. Some attempts have been made to design and implement databases speci cally for network management information [Bapa91, Valt91]. Unlike these attempts, we examine the feasibility of using the existing Directory Service for providing the storage and retrieval of managed information in the network management framework. Since we do not envisage that all types of management information can possibly be stored in the Directory, we investigate what types are suitable. We also investigate whether the Directory Service can be used in a reasonably ecient way such that it does not become the bottleneck in network management operations. We have implemented an integrated network management tool that uses the Directory Service as a managed information server for network management information. The network management tool monitors network trac load in an interconnected network environment, and uses Quipu [Kill91] as a repository of management information. We report on our experiences using Quipu and assess the appropriateness of using the Directory Service to provide support for network management information. The rest of this paper is organized as follows. Section 2 presents a set of requirements for managing networks. Section 3 presents a brief overview of the X.500 Directory Service and how it satis es the network management information repository requirements. Section 4 presents an integrated network management architecture using Directory Services. The components of our prototype implementation are given in Section 5. The performance of each component is examined and compared in Section 6. Section 7 presents the summary of our work along with some possible future work.

2 Requirements for Network Management In this section we examine the components of and requirements for network management. We particularly focus on the types of network management information and their repository service requirements.

2.1 Components of Network Management

Traditionally, managing networks involves one or more network management stations (NMSs) trying to monitor and control one or more (typically hundreds or thousands) of network elements (NEs) (e.g., hosts, gateways and bridges). An NMS is typically a management application program (or a set of programs) running on a host, acting as a monitoring and controlling point for a set of managed NEs. How these NMSs and NEs communicate is de ned by network management protocols (e.g., CMIP [ISO91a] and SNMP [Case90]). Management information exchanged between NMSs and NEs is de ned in the management information base (e.g., OSI-SMI [ISO91c], MIB-I [McCl90] and MIB-II [McCl91]). The standards also specify what kinds of services should be provided. For example, in the OSI management framework, the create and delete, get and set, event-report and action information access operations are provided [ISO91b]. In the Internet management framework, four operations are provided: get,

get next, set and trap [Case90]. However, they do not specify how these protocols, services or MIBs should be implemented. Below, we take a close examination of the characteristics of information in the MIB.

2.2 Management Information

The MIB is a conceptual repository of information on objects being managed. It speci es a set of objects which should be implemented by NEs. The structure of management information (SMI) [ISO91c, Rose90] de nes the rules for de ning the structure of objects and the relationships between them. It is interesting to note that most (if not all) MIBs de ned thus far (whether experimental or private) form a hierarchical name space. The contents of MIB can be largely divided into three groups: static, dynamic and semi-dynamic. The static information in the MIB consists of those objects whose contents hardly change (if at all) during the lifetime of the operation of a NE. Examples of such information are hardware and software con gurations of a NE. Hardware con guration information may include the CPU type, type of network interface or the amount of physical memory installed. Software con guration information may include the name of operating system and its version. Such information needs to be updated only when there is a hardware upgrade (e.g., replace CPU to more powerful one or add more memory) or a software update (e.g., update OS to the latest version). But occurrences of these events are very infrequent { it may take place (if at all) once in a few months or years. Other examples of the static information in the MIB include information pertaining to the NEs themselves. The name of a technical contact person responsible for a NE and where he/she can be found, where the managed NE is physically located, the type of NE (e.g., host or gateway), the NE's logical name, the NE's addresses (e.g., Ethernet and IP) and address translation mappings (e.g., IP addresses to media speci c addresses) are some of such examples. On the other hand, the dynamic information in the MIB consists of those objects whose contents change quite frequently (i.e., every few microseconds or milliseconds). Incoming and outgoing network trac information on a host are examples of such information. For instance, the number of packets that have been sent and the number of packets that have been read by the interface to and from the network are constantly being updated. These statistics are also updated in the counters maintained in the upper layers of the communication protocol stack. For example, in the network layer various statistics on the IP packets are constantly updated and in the transport layer those on the UDP and TCP packets are maintained. The dynamic information in the MIB mentioned above are raw data that are maintained by the managed devices themselves. These are frequently polled/reported from/to an NMS, which may collect and perform some analysis on them. For example, in order to determine the average network load for a time interval, the NMS may simply collect the total output packets sent to the network from each device on the network, sum the numbers and then divide by the number of devices (a more elaborate example of the network load monitoring application will be given in Section 5). The historic or trend data such as this is dynamic but the frequency of it being updated is much smaller than the kinds of dynamic raw data described above. We will call such kind of MIB information

semi-dynamic.

2.3 Management Information Repository

Management information that is collected as part of network monitoring needs to reside somewhere on the network. It is desirable that a repository for such management information have the following set of characteristics. The repository should (1) provide a single logical view but be physically distributed, (2) provide a general naming structure so that the managed objects can be easily stored and retrieved in a uniform way across heterogeneous systems, (3) provide a simple and ecient access interface through which application programs or processes can easily access management information stored in the repository, (4) have an international recognition so that it has the potential for growth and acceptance worldwide, (5) should provide a reasonable performance so that the use of it by management tools does not become the bottleneck, (6) provide some form of security in order to regulate the access of important information, and (7) support the replication of management information to increase availability, reliability and performance. In the following sections, we examine how the X.500 Directory Service can satisfy these repository requirements.

3 Overview of X.500 Directory Service The X.500 Standards [CCIT88, CCIT92] speci es a Directory Service which provides and manages information about entities. The X.500 Directory Service (or simply the Directory Service) and its Directory information is distributed physically, yet provides a uni ed, single logical functional view. The information held by the Directory is called the Directory Information Base (DIB). The DIB consists of entries (or objects) which contain information about entities. Each entry consists of a set of attributes each with a type and one or more values. The types of attributes which are present at each entry are dependent on the class of entities which the entry describes. Classes can be de ned by user, and thus various types of information can be stored in the Directory. Entities in the DIB are represented by entries in a global, hierarchical name space called the Directory Information Tree (DIT). Entries are placed in the DIT according to the organizational relationships between the entities which they represent. The X.500 Abstract Service De nition [CCIT88, CCIT92] de nes abstract ports and operations which provide the user functionality for retrieving, searching and modifying directory information. These operations form a simple interface protocol called Directory Access Protocol (DAP). The current X.500 Standards support the read, compare, list, search and abandon interrogation functions and the basic add, remove and modify entry manipulation functions. The Directory Service (including the DIT) is distributed over physically separated entities (such as computer hosts) called Directory Service Agents (DSAs). This distribution is transparent to the user through the use of Directory Service Protocol (DSP) operations between DSAs. Each user or user-process is represented by a Directory User

The Directory DUA DSA DSA DUA

DAP

DSA DSP

DSP

DSA

DUA

Figure 1: Functional Model of the Directory Service Agent (DUA) which is responsible for interacting with the Directory. Thus, users can easily and eciently access the Directory information through local or nearby DSAs. The functional model of the Directory Service is illustrated in Figure 1. It is assumed that some service will be provided regardless of network partitioning resulting from events such as non-local site failures. This is achieved by the distributed nature of the DSAs and replication of Directory information [CCIT92]. X.500 also provides a security mechanism so that directory information access by unauthorized users can be prevented. Caching is also recommended to increase the performance of the Directory Service but it is a local issue. That is, the X.500 Standards do not provide caching algorithms and it is up to the implementor of the local DSA to do so. Thus, the Directory Service satis es the requirements for the storage and retrieval of network management information. In Section 6, we examine the performance aspect of the Directory Service.

4 Integrated Network Management Architecture

4.1 The Architecture

In this section, we introduce an architecture that integrates the Directory Service into the network management framework. The architecture, shown in Figure 2 uses the Directory Service as a repository for network management information. As described in Section 2, the Directory Service provides a repository of information. The Directory is distributed and replicated for increased availability, performance and reliability. The fact that there may exist multiple DSAs distributed over the network or the fact that some (or all) information is replicated is transparent to the user. What the Directory provides to the user is the ability to insert, remove, update and search information entries. The NM-DUA (Network Management - Directory User Agent) is required as an interface between the NM tools and the Directory. Management information that is to be

Network Management

The NM-DUA

Directory

Tools

Service

Figure 2: An Integrated Network Management Architecture stored in the Directory is passed from a management entity (either NMS or NE) to the NM-DUA, which then communicates with an appropriate DSA in the Directory Service to complete the task. The Directory Access Protocol (DAP) [CCIT92] is used between NM-DUA and DSA. The NM-DUA must at least support the operations to add, update and retrieve information entries.

4.2 Management Information for the Directory

Network management involves a great deal of management information. We have classi ed management information into three groups in Section 3: static, dynamic and semidynamic MIB. We envisage that the static management information should be stored in the Directory for various management applications. Since the static MIB information is updated infrequently but will mainly be retrieved for the lookup purpose, this type of data suits the intended usage characteristic of the Directory Service quite well. The dynamic MIB information which is constantly being updated is not quite suitable for being stored in the Directory because of its update frequencies. As mentioned earlier, the dynamic MIB information is usually updated every few microseconds or milliseconds. That rate of update frequency to the Directory is, in general, expected to be more than what the Directory Service can handle. This is mainly because of the communication cost involved in accessing the Directory Service. Even if the Directory Service is not distributed (i.e., the Directory Service consisting of a single DSA), the same problem would still exist. The semi-dynamic MIB information which is in general updated a lot less frequently than the dynamic MIB, however, should also be suitable for being stored in the Directory. Typically the semi-dynamic MIB information contains historic data or data that is updated every few minutes or hours. This rate of update frequency should be adequately handled by the Directory Service. In order to store MIB information in the Directory, MIB objects and attributes must be de ned in the Directory Service. The Directory Service allows the user to de ne the objects and attributes of information which is to be stored in the Directory. In the next section, we describe our experience of de ning objects and their attributes for storing static and dynamic MIB information in the Directory.

5 Implementation In this section, we describe a prototype implementation of the integrated network management architecture. We rst describe the network management tool and the Directory Service implementation used in our prototype implementation. We then describe the object and attribute de nitions for management information that is to be stored in the Directory. A description of the NM-DUA interface as well as the overall operation is also given.

5.1 Network Management Tool

The network management tool used is a network trac load monitoring system, which uses the aggregate agent concept [Grat92]. The tool has been designed and implemented to overcome two major problems that arise when managing large heterogeneous interconnected networks. The rst problem deals with communication between two or more NMSs involved in network management. When managing a group of subnets, some of the data collected by an individual NMS will need to be made accessible to other NMS managing nearby subnets and to NMS responsible for groups of subnets. The NMSto-NMS communication is required to identify the scope of a current subnet anomaly as local to that subnet or a symptom of a more global factor, or simply to provide statistical information on the health of a subnet. The second problem arises from the desire to impose a hierarchical structure on the ow of management information. This hierarchical structure allows a central authority that is responsible for overall network management to monitor changes occurring in various subnets and take appropriate action. In this hierarchical scenario, any intermediate-level NMS could be monitoring and controlling groups of subnets. In this way, departmental or regional network administrators not only have direct access to their networks for management but also participate in the overall management hierarchy by passing their subnet information to higher levels. AANMS

AA

NMS 1

Host

Host

Gateway

NMS 2

Gateway

Host

Host

Figure 3: An Example of Hierarchical Network Trac Load Monitoring System

An example of a network load monitoring system using the aggregate agent concept is shown in Figure 3. The system basically works as follows. An NMS manages a number of NEs, each of which monitors network trac information from its interface(s). The number of packets that have been sent to the network from the device and the number of packets that have been read from the network from the device are examples of such trac information. An NMS periodically polls each NE and collects the trac information. The collected trac information is then averaged out (per second, for example) and then passed to the aggregate agent (AA) which collects network load information from one or more NMSs. Aggregate agents are then polled by higher-level managers called aggregate agent managers (AANMS). In this way, the network load information can be passed up hierarchically all the way up to the root of the hierarchy.

5.2 The Directory Service

The implementation of the X.500 Directory Service we are using is Quipu version 7.0 [Kill91]. The Directory Service testbed has been installed in our systems laboratory which consists of a heterogeneous network of ve hosts (2 Sun 3's, 2 Sun 4's and a MIPS), and a DSA runs on each host. For the purpose of our uses, these DSAs are connected among themselves but are isolated from DSAs running in the rest of the world. The NM-DUA (shown in Figure 2) interface was implemented to provide access to the Directory. All operations (e.g., store, update and retrieve) from the management tool to the Directory is through this interface. It is also responsible for setting up and tearing down the connection to and from a DSA in the Directory.

5.3 MIB De nitions

Since generic de nitions of objects and attributes in most X.500 implementations (including Quipu) are for information about people, they do not meet the requirements for network management. Thus, we de ned a new set of objects and attributes and added to the existing Quipu de nitions. The following two objects and their attributes are two most relevant ones that need to be mentioned here.

5.3.1 Domain Object

A domain is a logical entity within an interconnected network, and consists of a set of NEs. The Quipu de nition for the domain object is as follows. csdDomain:

csdLocalObjectClass.4 : csdLocalTop : \ domainName : \ description, subnetAddress, subnetMask \ netload, hostList, adminContact, techContact

is the name of the domain object class whose object identi er is . The domain object inherits attributes of the csdLocalTop object class and has a single mandatory attribute called domainName. The description,

CsdDomain csdLocalObjectClass.4

, , , , and techContact attributes are optional. The hostList attribute contains the names of NEs in the domain. In our prototype implementation, a domain is the basic unit that an NMS manages. The network load information for this particular domain for some time interval is stored in the netload attribute, which can be retrieved by other applications (such as aggregate agent managers) for various uses. For example, overall network load of an entire departmental (possibly consisting of one or more domains) or campus entire network can be analyzed. In the domain object de nition, only the netload attribute is a semi-dynamic MIB; the others are static. subnetAddress subnetMask netload hostList adminContact

5.3.2 Network Element Object

A network element object is a physical or logical computing device on a network. It appears to the user as a distinct entity that can be used for running user applications (e.g., management agent programs). The Quipu de nition for the network element object is as follows. csdMachine:

csdLocalObjectClass.6 : csdAdmin : \ machineName : \ machineType, description, networkAddress, operatingSystem, \ applications, adminContact, techContact, location

is the name of the NE object class whose object identi er is . The NE object inherits attributes of the csdAdmin object class and has a single mandatory attribute called machineName. The machineType, description, networkAddress, operatingSystem, applications, adminContact, techContact and location attributes are optional. The applications attribute contains the names of applications that a particular network element can run. It also tells where the application programs can be found. For example, it contains the le path of the agent program that collects network trac information. This is where the NMS fetches the le paths of the agents when activating them. The network element object de nition consists of static MIB information only. As discussed earlier in this paper, dynamic MIB information is best kept locally within each device. In this section, we described our prototype implementation of integrating the Directory Service in a network load monitoring system. In the next section, we examine the performance of the Directory Service in the prototype.

CsdMachine csdLocalObjectClass.6

6 Performance In order to determine the performance of the Directory Service in the network load monitoring tool example given in the previous section, we have compared the times taken for accessing the Directory with the rest of the integrated management system. To simplify the performance evaluation, we only included one manager (NMS) and ve

agents in our prototype implementation. The NMS interacted with the Directory for accessing and updating management information. The prototype management system is divided into four phases. 1. retrieve domain, host and application information from the Directory, 2. start up the agents on managed devices, 3. poll the agents to collect network load information, and 4. store network load in the Directory. Figure 4 shows the actual times taken for each phase and the percentage of each compared to the overall time taken. The performance measurements were taken from running our prototype implementation on our systems laboratory described earlier. The rst phase took only three seconds to retrieve the domain, host and application information from the Directory. This phase involved initializing the NM-DUA (including the connection set-up to a local DSA), getting the list of hosts by searching the hostList attribute in the Directory for a given domain (our systems laboratory subnet consisting of ve hosts), and then subsequently querying the agent application information (e.g., where the executable is located) for each host. The second phase involved starting up the agent on each remote host in the domain using the UNIX rsh command. The third phase started as soon as all the agents got started and were able to reply to polling by a management station. The nal phase involved updating the network load information for the domain in the Directory by modifying the netload attribute. Phases Information Retrieval Agent Startup Collection Netload Update Time (seconds) 3 22 60 0.011 % 3.53 25.88 70.58 0.01 Figure 4: Comparison of Four Phases in the Network Load Monitoring Application Surprisingly, the phase for updating the netload information to the Directory took only 0.011 second (or 0.01% of the overall time). In our detailed analysis, we found that the NM-DUA set-up took approximately 1 second or one-third of the rst phase. The other two-thirds involved six search operations (1 domain and 5 hosts) to the Directory as well as capturing the replies and processing them. We found that the actual search operation itself is as fast or faster than the update operation. However, capturing and processing the replies from the Directory and making them meaningful to the management tool was taking most of the rst phase. Nevertheless, the total time for accessing the Directory took merely less than 4% of the overall time. Sixty seconds or 70% taken by the collection phase is the time taken to poll ve agents and receive the replies from them. The collection phase included 55 seconds of idle period (i.e., polling interval) and 5 seconds of actual polling time (approximately a second per agent). In practice, however, the polling interval may be a lot larger than what we used

in order to avoid ooding the network with the polling trac (which will contribute to the degradation of network performance). If we were to poll agents every few minutes or tens of minutes (which is more common and practical), the times for the rst, second and fourth phases would remain constant but the collection phase will dominate the total time taken for the application. Thus, the percentages for accessing the Directory would be very small. In another words, the cost of using the Directory for the information retrieval and storage is quite minimal in the overall management operations. We also ran some tests to determine the maximum rate of update frequency that can be handled by the Directory Service. In order to generate as many updates to the Directory as we can in our implementation, we eliminated the idle period between the polls and polled only one agent. Since it takes approximately one second to poll a single agent, the maximum rate was an update at every 2 seconds or less. The result was that the Directory Service handled the update operation at that rate without any problem. We envisage that this performance by the Directory Service is more than sucient to provide the storage and service to most (if not all) types of semi-dynamic MIB information. In summary, the preliminary performance results obtained from our prototype implementation suggest that the X.500 Directory Service can be used for the storage and retrieval of network management information. The results also show suggest that the Directory Service can be used without it being the bottleneck in certain management operations.

7 Concluding Remarks We have examined the feasibility of using the Directory Service for the purpose of storing and retrieving management information in the network management framework. We have examined the requirements for network management, particularly the management information repository aspects. We showed how the X.500 Directory Service can satisfy these requirements. Preliminary results from our prototype implementation show that the Directory Service can be used for the storage and retrieval of management information in the network management framework. Our prototype implementation retrieved from the Directory not only the information about hosts on a given domain but also information about agent applications on each host. Although it was quite minimal, the Directory was also being used for what we would call distributed applications management. Managing distributed systems involves just more than managing networks. It needs to manage not only the networks and devices on them but also the applications running on the system. As an extension of our work, we are also looking at the feasibility of using the Directory Services for the purpose of distributed applications management.

Acknowledgements

The authors wish to thank the reviewers of this paper for their helpful comments and suggestions.

References

[Bapa91] S. Bapat, \OSI Management Information Base Implementation", Integrated Network Management, II, Elsevier Science Publishers B. V., I. Krishnan & W. Zimmer (Editors), pp. 817{832, North-Holland, 1991. [Case90] J. D. Case, M. S. Fedor, M. L. Schostall, and J. R. Davin, \A Simple Network Management Protocol", Internet Request for Comments 1157, Network Information Center, SRI International, Menlo Park, CA, 1990. [CCIT88] CCITT, \X.500 Directory Services (Parts 1-8)", CCITT, 1988. [CCIT92] CCITT, \X.500 Directory Services, 1992", CCITT, 1992. [Grat92] B. E. Gratto, J. W. Hong, and J. P. Black, \The Aggregate Agent Concept: A Paradigm for Hierarchical Network Managment", The First International Conference on Computers and Communication, pp. 148{152, San Diego CA, June 1992. [ISO91a] ISO, \Information Processing Systems - Open Systems Interconnection - Management Information Protocol Speci cation - Part 2: Common Management Information Protocol", International Organization for Standardization, International Standard 9596, 1991. [ISO91b] ISO, \Information Processing Systems - Open Systems Interconnection - Management Information Protocol Speci cation - Part 2: Common Management Information Service", International Organization for Standardization, International Standard 9595, 1991. [ISO91c] ISO, \Structure of Management Information Part 1: Management Information Model", International Organization for Standardization, International Standard 10165-1, 1991. [Kill91] Stephen E. Kille, \Implementing X.400 and X.500: The PP and QUIPU Systems", Artech House, Boston MA, 1991. [Lang92] R. Lang and R. Wright, \A Catalog of Available X.500 Implementations", Internet Request for Comments 1292, Network Information Center, SRI International, Menlo Park, CA, January 1992. [McCl90] K. McCloghrie and M. T. Rose, \Management Information Base for Network Management of TCP/IP based internets", Internet Request for Comments 1156, Network Information Center, SRI International, Menlo Park, CA, May 1990. [McCl91] K. McCloghrie and M. T. Rose, \Management Information Base for Network Management of TCP/IP based internets: MIB-II", Internet Request for Comments 1213, Network Information Center, SRI International, Menlo Park, CA, March 1991. [Rose90] M. T. Rose and K. McCloghrie, \Structure and Identi cation of Management Information for TCP/IP based internets", Internet Request for Comments 1155, Network Information Center, SRI International, Menlo Park, CA, May 1990. [Valt91] R. Valta, \Design Concepts for a Global Network Management Database", Integrated Network Management, II, Elsevier Science Publishers B. V., I. Krishnan & W. Zimmer (Editors), pp. 777{788, North-Holland, 1991.