A Distributed Network Management System - CiteSeerX

A Distributed Network Management System'

Kwang-Hui Lee Dept of Computer Science Changwon Nation University Changwon, KyungNam 641-773. South Korea ABSTRACT This paper presents a distributed network management system which provides a means to manage communication network for distributed systems. For efficient network management, the multi-level domain approach has been used. Management function (Configuration , Fault, Performance management) is distributed in each management domain. The management system was composed of several elements. Some of those were previously implemented in the project of the single level multi-domain network management system. The integration of different networks which have different network management schemes can also be achieved with the distributed network management system. The object-oriented distributed database was chosen for management information base (MIB). We finished the design of the system and are in the middle of it implementation in the environment of distriibuted campus network (CNUNet).

introduced, which is referred to as the distributed network management system (DNMS). In this paper, management of the communication networks for distributed systems is focused. This project was started with the main goal to develop a distributed network management system which can operate regardless of the types of distributed systems and management protocols. But, for short term purpose, the distributed network management system run in the environment of campus network (CNUNet :Changwon National University Network) has been developed. The distributed network management system designed in this research can provide a means of interconnection between networks which have different management policies and management parameters. The multi-level management domain concept allows the distributed network management system to be developed. The system can operate in heterogenous management environment. The domain concept used in this paper is basically adopted from our previous work[8]. This concept has been extended in order to manage a network for distributed systems.

I Introduction In recent years there has been a considerable growth in the use of distributed systems to share resources with efficiency and reliability. The modularity of network components to achieve fault-tolerant service and resource sharing service is achieved by distributed system structures. The size and complexity of distributed system makes it hard or even impossible to manage each component of distributed systems. Distribution naturally implies the need for a communication to allow interaction. As various distributed systems have been developed, efficient management of the communication system is needed. Most of network management system recently designed and implemented are based on centralized control scheme. The centralized techniques are inadequate when applied to distributed systems because communication architectures of distributed systems are different from those ot centralized systems. Due to this reason. if a centralized mechanism is applied to distributed system, it can reduce advantages of distributed system[ I]. It, therefore, is clear that different approaches are needed to manage a network for distributed systems[2][3][4][7]. This makes a new approach be

Section 2 presents brief description on network management system implemented in the previous research. Multi-level domain concept which is vital element of this research is introduced in section 3. The structure of the distributed network management system is given in section 4. Section 5 discusses the implementation environment. Finally we summarize the main conclusion of the study and outline future research avenues. 11. Single-level Domains

In this section, brief description on general network management system and introduction of the network management system designed and implemented in the previous study are given. Network management is all about ensuring that the network operates correctly, efficiently, and according to the policies of the organizations the network serves. For this purpose, a network management system has to obtain

'

This work was supported in part by the Nondirected Research Fund, Korea Research Foundation from Sep. 1993 to Aug. 1994. 0-7803-1820-XI94 $4.00 0 1994 IEEE

548

information on the current states of managed objects, make management decisions and perform appropriate control operations on the objects to modify their behaviour. In I S 0 (International Organization for Standardization)/OSI (Open Systems Interconnection) framework, network management has been divided into five functional areas : configuration, fault, performance, security and accounting management. IS0 has defined a series of standards for the management of the communication system for OSI. The structure of OS1 network management and the function of each element can be found in 11 11. In the previous study, the network management system was developed in focusing on configuration, fault and performance management which were based on OS1 network management framework. When it was designed, security and accounting management functions were omitted because they were not urgent in our environment. But these functional areas can be implemented without disturbing other components of the system. In the previous work, the multi-domain network management concept was introduced and a domain was defined as a unit of managed communication networks and management itself. There can be one or more domains in global communication network. The domain is not physical or geographical configurational unit, but logical one. Each domain is independent and disjoint. It means that there is no managed objects which overlapped in several management domains. One managed object can be included in just only one domain. Also, there can be only one manager in a domain and a manager controls all agents in the domain. An agent is concemed with one or more managed objects, which are representation of real resources to be managed. If necessary, a manager in a domain can access a managed object in a remote domain through the remote domain manager using MMP (Multi-domain Management Protocol). The internal structure of a manager is illustrated in figure 1. The simulator provides two services: real-time simulation and non real-time simulation. The MIB was implemented with object-oriented database based on OS1 etwork management approach. The directory server allows management entity to map managed object identifier to the location of them. More precise discussion on function of each component in a manager was presented in [SI.

1

\

1

U.I.

111. Multi-level Domains In this section, the multi-level network management domain concept is explained, which is one of essential components in order to manage a network for distributed systems. As managed objects themselves and controls are distributed in several elements in a distributed system, management function should be distributed into each communication element for efficient management. Therefore, the distributed network management approach can be the best solution to manage networks for distributed systems. It provides efficiency in managing a network for distributed systems. Of course, this scheme can be applied to not only distributed systems environment, but also centralized one. For this, the management function has been split into several domains. In the previous research, it was assumed that two domains should be independent and disjoint each other. The assumption could be convenient for the centralized environment, but it can not be convenient for the distributed environment. In this paper, it is assumed that two domains can be independent or nested. A domain may be fully contained by other domain or vice versa, and two domains can be disjoint. Figure 2 shows the example of the structure of independent and nested relationship among domains. The independent relationship means that a manager in a domain can not directly access managed objects located in a remote domain through the remote manager.

~

Figure 2. Relationship of management domains

I

“hMPD” I

m Domain #1

Domain H

Some managed objects can be overlapped among domains and controlled by different management domains. Because the domain concept is not physical but logical, some communication equipments can be controlled by several domains. Suppose that while one domain uses SNMP (Simple Network Management Protocol) as management protocol, the other domain CMIP (Common Management Information Protocol) as management protocol and one communication equipment is accessed by these domains. In this case, each management domain has different management view on the overlapped objects. One management object is shared by two management domains. The managed object provides two

Domain #Z

management interface views, one of which is for SNMP domain and the other for CMIP domain. For this, the structure

Figure 1. The structure of multi-domain Network management

549

It is assumed that there can be only one top-level domain which represents all the networks to be managed. If there are several subnetworks to be managed, each subnetwork can be mapped into a network management domain. The subdomain, of course, becomes the parent domain of the lower subdomain(s). The parent can directly manage only subdomain(s). It doesn’t know which managed objects are in subdomain and which management policies are applied to them.

of managed object should be defined for managed objects shared by domains. Domain does not consist of real managed objects, but view of managed objects. Mapping the management view to real managed object is needed. One of approaches to solve this problem is shown in [ 5 ] [ 6 ] . If a manager intends to access remote managed objects, then it should request to the parent manager in which the manager is nested. The parent manager could send the request message to the manager which includes the managed objects related to the request if the local manager has the accessibility and the parent manager is also parent of the remote manager. If the parent manager is not a parent of the remote manger, then it should pass a request message to the higher parent manager. But, it can make a serious problem if the top-level manager fails. In this case, the management domain can be divided into two parts. Another problem may be heavy communication overhead in top-level manager. But, the latter problem is not serious because most communication happens locally. In other words, communication through the top-level parent is rarely occurred in the normal operational environment. To solve the former problem, a transaction mechanism should be supported. As current system is proto-type, the mechanism is not supported but, if possible, it could be constructed. All domains construct a tree structure and there can be several levels in the tree. Figure 3 illustrates the management domain tree of domains shown in figure 2. As shown in figure 1 , the manager of domain is composed of configuration manager (CM), fault manager (FM), performance manager (PM) and several elements. In the distributed network management system, those functions can be distributed into several domains, which are nested in common higher level network manager. As shown in figure 2, the manager in domain A provides management service to the manager in domain B which is the parent domain of domain A . Also, the manger in domain B provides the manager in domain C network management function related to the managed objects which are included in domain B. The manager in domain C can not directly access the managed objects which reside in domain A without interfacing to the manager in domain B.

Advantages of the use of multi-level domain concept are followings. Firstly, appropriate management functions can be allocated to each management level and domain. The manager in the highest domain totally performs configuration, fault, and performance management functions. The lower level managers perform these management functions on the managed objects in the lower level domains. For instance, the top-level manager rarely needs to know the state parameter of the modem interfaced to the user in the specific subnetwork (subdomain). This parameter can be monitored by the related domain manager. That is, the top-level manager needs only global information of managed networks. In other words, management information can be localized to the domain to which the information is closely related. This provides the efficiency in managing communication networks. Secondly, we can naturally get filtering function which is one of the essential elements in order to manage a large network and is recommended by OS1 network management framework. The number of managed object generating management information in a large network can make the manager be overloaded. Filtering, therefore, is introduced for a distributed network management. In OS1 network management, the filtering function makes many problems in implementing it. Many implementers of OS1 network management system have excluded this function. Using the distributed network management system with multilevel domain concept makes it easy to implement filtering function. Even though fault is developed and detected in a management domain, other domains could normally operate while it tries to recover from the failure state. One of the most important factor of this system is that each domain manager can have different management policies and management parameters as described earlier in this section. This capability is allowed by the use of multi-level management domain concept and interface view of managed object. This, therefore, can support an integrated network management system.

Domain H

Domain C

Domain E

IV. Distributed Network Management

Domain B

Domain F Domain G

In this section, the structure of the DNMS is explained in more detail. As mentioned in section 3, the management system is composed of several elements. Fist of all, management information base (MIB) is described. One of the critical components of network management framework is the management information model to be used. As the DNMS was

A Domain D

Domain A

Figure 3. Management domain tree

550

introduced in order to get benefits of distributed systems, the distributed database should be supported for MIB. Each domain has a MIB for local management. Also, some parts of management information need to be duplicated among several domains for rapid access and fault-tolerance of this information. It required that a mechanism have to be introduced for the consistency of duplicated information. For this, we are designing a new distributed database management system (DDBMS) which is supported by object-oriented approach in other project. In this system, managed object is defined with object-oriented model which is recommended and used by OS1 network management. Management information should be exchanged among domains. It is supported by DIP (Domain Interface Protocol) which is mentioned later.

networks, it makes some overhead. It, but, is normal that a domain does not interact with many domains. Actual communication between domains can be observed in the case of parent-children relationship.

In the previous work, we did not introduce a group communication facility. After finishing that project we realized the necessity of group communication facility for efficient management and have developed the group communication mechanism[9], which is similar to ISIS system[lO]. Group communication facility is used to exchange management information between domains (managers) which have the nested relationship. Because two independent domains do not exchange management information, group communication facility needs not to be used. The group communication function designed and implemented in [9] is not perfectly appropriate for this distributed network management system because the actual communication pattern happened in the DNMS is l:n communication. But the implemented group communication facility can well support our requirement for network management system. It is the reason why we adopt this one.

Domain #I

Domain #2

Figure 4. The structure of distributed network management system

The structure of the DNMS in this research is shown in figure 4. The actual communication occurs between same functional area managers, for instance, between configuration managers. As each domain can have different management policies and management parameters, the interface must be newly defined. Therefore, Domain Interface (DI) is defined as shown in figure 4. The function of DI is to provide the interface between domains. For example, in order that the configuration manager(CM) in domain 1 sends a request to other CM in domain 2, the CM in domain 1, firstly, sends a request to DI in domain 1. Then, DI in domain 1 sends this request to DI in domain 2 with DIP. After that, DI in domain 2 passes the request to CM in domain 2. In the end, the request can be delivered to the CM in domain 2.

V. Implementation Environment The environment of this project for implementation is described in this section. The system is designed and implemented in the environment shown in figure 5. CNUNet is a distributed experimental campus network which is composed of thirteen mini-computers and several hundreds of workstations. The components are interconnected with ringtype backbone network (FDDI) and several bus-type networks (Ethernet). CNUNet is also connected to other domestic networks and Internet through other network service. In the early stage, it was, we thought, convenient that one domain was assigned to one Ethernet network. There could be three level domains. The bottom one was the Ethernet domain, the middle one was building domain, and the top one was FDDI domain. But, at this point, it can not be true. One network can not be directly mapped to a domain. One network can be mapped one or more domains and one domain can include one or more networks depending on necessity. That is, we can say that a domain is not physical element but logical one.

The DI supports a platform for integrated network management and performs function related to accessibility. When DI receives a request message from other domains, it first checks the accessibility with domain relation. If the access is not permitted, it ignores this message. If permitted, it passes the message to the related functional area manager. Of course, the message format exchanged between domains has the header and information. The header includes information about domains. If there are so many domains in the managed 55 1

ter

projects. As some parts of components have been implemented already in the previous version, the whole implementation should be completed soon. After implementing it, we have a plan to test it in WAN environment.

To other PSDN (DACOMnet)

~

References [ I ] M. Siegal and K, Sauer, "Efficient network management for a highly distributed system", Proc. of IFIP TC6/WG6.4 2nd International Conf. on Local Communication Systems, Palma, pp42 1-43 1, June 1991. [2] M. Mansouri-Samani and M, Sloman, "Monitoring Distributed Systems", IEEE Network, vol. 7, no.6, pp20-30, Nov. 1993. [3] M. Sloman, "Distributed System Management", Proc. of the IFIP TC6iWG6.4A Workshop on LAN Management, West Berlin, pp15-46, July 1987. [4] M. Sloman and J. Moffett, "Domain Management for Distributed Systems", Proc. of the IFIP TC6iWG6.6 Symp. on Integrated Network Management, Boston, pp505-5 16, May 1989. [ 5 ] B. Muralidharan, "Multiprotocol Management Agent: A Look at an implementation and the issues to consider", IEEE J. on Selected Area Communication, vol.11, no.9, pp13361345, Dec. 1993. [6] 0. Newkerk, M. Nihart and S wong, "The common agent A Multiple Management Agent", IEEE J. on Selected Area Communication, vol.11, no.9, pp1346-1352, Dec. 1993. [7] G. Goldszmidt and Y.Yemini, "Evaluating Management Decision via Delegation", Proc. of the IFIP TC6iWg6.6.6 3rd International Symp. on Integrated Network Management, San Francisco, pp247-257, April, 1993. [8] K.-H. Lee, "Design of a Configuration Management", Proc. of IEEE GLOBECOM'93, Houston, Nov., 1993. [9] K.-H. Lee, "Design of and efficient and reliable group communication protocol", TR0993, Changwon National Univ., Sep. 1993. [ l o ] K.P. Birman, A Schiliper and P. Stephenson, "Lightweight causal and atomic group communication", ACM Trans. on Computer Systems, vol. 9, no. 3, pp272-314, Aug. 1991. [ 1 11 W. Stallings, SNMP, SNMPv2 and CMIP, The practical guide to network management standards, Addison Wesley, 1993.

.......

the

CSNet

Figure 5 . Implementation Environment Many parts of components of domain were implemented in the previous project. The DI has been added and MIB has been modified. Of course, a little bit of modification on other components (e.g. CM, FM, PM and simulator) has needed. The naming scheme should be totally modified because multi-level domain concept was not introduced in the previous version. But it did not make it difficult to develop the DNMS. After finishing this experiment we have a plan to introduce this concept to wide area network (WAN) which is installed in Korea for research and development. We think that no modification will be needed when it is installed in WAN because it has no special characteristics for LAN. The group communication facility, of course, can be used in WAN without modification because it has been designed regardless of the type of networks. VI. Conclusions

In this paper, the multi-level management domain concept has been introduced to mange a network for distributed system. As a result, the distributed network management system which is efficient and provides atomicity, has been designed. With this management system, it can be easily done to manage networks which have different management policies and management parameters. For example, different two networks (one supports CMIP and the other SNMP) can cooperate in the aspect of network management. For this, the network management function was scattered into several domains. We think that this concept can help to develop an efficient and reliable distributed network managment system. The group communication facility has been introduced. We have finished the design of the distributed network management system and have been implementing it in several

552