Abstract Decentralised Approaches for Network Management

Mohsen Kahani, H.W. Peter Beadle

The Institute for Telecommunication Research (TITR)Elec. and Comp. Eng. Dept., University of WollongongNorthfield Ave, Wollongong, NSW 2522, Australia

email: {moka|beadle}@elec.uow.edu.au

Abstract

Centralised network management has shown inadequacy for efficient management of largeheterogenous networks. As a result, several distributed approaches have been adapted toovercome the problem. This paper is a review of decentralised network management techniquesand technologies. We explain distributed architectures for network management, and discusssome of the most important implemented distributed network management systems. Acomparison is made between these approaches to show the pitfalls and merits of each.

1.Introduction

Systems are increasingly becoming complex and distributed. As a result, they are exposed toproblems such as failure, performance inefficiency, resource allocation, security issues, etc. So, anefficient integrated network management system is required to monitor, interpret, and control thebehaviour of their hardware and software resources [1]. This task is currently being carried out bycentralised network management systems, in which a single management system monitors thewhole network.

Most of existing management systems are platform-centred. That is, the applications areseparated from the data they require and from the devices they need to control. Although someexperts believe that most network management problem can be solved with a centralised SimpleNetwork Management Protocol (SNMP) [2], there are real network management problems thatcannot be adequately addressed by this centralised approach [3]. Also, as managed devices areincreasingly equipped with powerful processing resources, device-centred management can easilymake use of these resources and provide a simpler, more scalable, more flexible, and cheapermanagement paradigm than platform-centred ones . There are a number of metrics that can beused to determine if a network management application is more appropriate for a centralised ordistributed system. Figure 1. shows a metric presented in [3].

Figure 1. Metrics to determine decentralisation

In this paper, we focus on non-centralised approaches for network management, and discusseveral architectures proposed to accomplish this purpose. We initially, explain differentarchitectures for network management systems. Then, we present background information ondistributed systems and then discuss several implemented distributed network managementsystems. Finally, we will conclude the paper with a comparison between these systems and discusstheir pitfalls and merits.

2.Network Management Architectures

There are three basic approaches for network management systems: centralised, hierarchical anddistributed [4]. Currently, most network management systems are centralised. That is, there is asingle management machine which collects the information and controls the entire network(Figure 2.-a). This workstation is a single point of failure, and if it fails, the entire network couldcollapse. In case the management host does not fail, but a fault partitions the network, the otherpart of the network is left without any management functionality. Also, a centralised systemcannot easily be scaled up when the size or complexity of the network increase [5].

A variation of centralised systems is the platform approach [6] (Figure 2.-b), in which a singlemanager is divided into two parts: the management platform and the management application. Themanagement platform is mainly concerned with information gathering and simple calculations,while management application uses the services offered by the management platform to handledecision support and higher functions [7]. The advantage of this approach is that applications donot need to worry about protocol complexity and heterogeneity. The drawback is that it stillinherits limited scalibility from its centralised architecture.

The hierarchical architecture uses the concept of “Manager of Managers” (MOM) and managerper domain paradigm[4, 6] (Figure 2.-c). Each domain manager is only responsible for themanagement of its domain, and is unaware of other domains. The manager of managers sits at ahigher level and request information from domain managers. In this architecture, there is no direct

ManagementWorkstation

ApplicationApplicationManagement PlatformNetwork

(Multiple-vendor)Network(Multiple-protocol)Agent

Agent

Agent

AgentAgentAgent(a)

Manager ofManagers(MOM)(b)Manager 1domain 1Manager ndomain nManager 1domain 1Manager ndomain nNetworkNetworkAgentAgentAgentAgentAgentAgent(c)(d)Figure 2. Different management approaches: a) Centralised, b) Centralised Platform-based,

c) Hierarchical and d) Distributed.

communication between domain managers. This architecture is quite scalable, and by addinganother level of MOM a multiple level hierarchy can be achieved.

The distributed approach (Figure 2.-d) is a peer-to-peer architecture[4]. Multiple managers, eachresponsible for a domain, communicate with each other in a peer-system. Whenever informationfrom another domain is required, the corresponding manager is contacted and the information isretrieved. By distributing management over several workstations throughout the network, thenetwork management reliability, robustness and performance increases, while the networkmanagement costs in communication and computation decrease [5]. This approach has also beenadapted by ISO standards and the Telecommunication Management Network (TMN)architecture [8]. The Management model for ATM networks, adapted by ATM Forum, is basedon this approach, too [9].

A combination of the hierarchical and distributed architectures, known as ‘network architecture’,can also be used [6] (Figure 3.). This architecture uses both manager-per-domain and manager ofmanagers concepts, but instead of a purely peer-system or hierarchical structure, the managers areorganised in a network scheme. This approach preserves the scalibility of both systems andprovides better functionality in diverse environments.

IntegratedManager 1IntegratedManager 3IntegratedManager 2ElementManager 1ElementManager 2ElementManager nNetworkdomain 1domain nFigure 3. Network Architecture

3.Distributed Systems and Services

Fault tolerance and parallelism are key properties of a distributed system [10]. A distributedsystem should use interconnected and independent processing elements to avoid having a singlepoint of failure. There are also several other reasons why a distributed system should be used.Firstly, higher performance/cost ratio can be achieved with distributed systems. Also, they achievebetter modularity, greater expansibility and scalibility, and higher availability and reliability [11].Distribution of services should be transparent to users, so that they cannot distinguish between alocal or remote service. This requires the system be consistent, secure, fault tolerant and have abounded response time. The form of communication in such systems is referred to as client/servercommunication [12]. The client/server model is a request-reply communication that can be:synchronous and blocking, in which the client waits until it receives the reply; or asynchronousand non-blocking, in which the client can manage to receive the reply later.

Remote Procedure Call (RPC) [13, 14] is well-understood control mechanism used for calling aremote procedure in a client/server environment. The idea is to extend the use of procedure call inlocal environment to distributed systems. This results in simple, familiar and general methods thatcan be implemented efficiently.

The Object Management Group’s (OMG) Common Object Request Broker Architecture(CORBA) [15] is also an important standard for distributed object-oriented systems. It is aimedat the management of objects in distributed heterogenous systems. CORBA addresses twochallenges in developing distributed systems: making the design of a distributed system not moredifficult than a centralised one; and providing an infrastructure to integrate applicationcomponents into a distributed system [16].

4.Non-centralised Network Management

In this section, we will discuss some of the most important proposed systems for management ofnetworks using non-centralised approaches. These systems include distributed big brother, fromthe University of Michigan; Distributed Management Environment, from the Open SoftwareFoundation (OSF); hierarchical network management, from the Technical University of Vienna(TU-Wien); and management by delegation, from the University of Columbia. A comparison willbe presented in the next section. There are several other approaches, which are not discussed inthis paper. Interested readers can refer to [17-24].4.1.

Distributed Big Brother

Distributed Big Brother (DBB) is a distributed network management system consisting ofcooperative autonomous computing agents [5]. DBB has been designed with the goal ofdistributing management and organisational tasks, while maintaining a central location controlover the whole system. It uses some technologies from the field of distributed AI, such ascontracting information, organisational structuring, election for role management, and hierarchicalcontrol.

DBB distributes the management tasks by using mid-level managers that can be executed inparallel. It also uses the Contract Net Protocol [25] to reduce the overhead in authority structure.As the computer networks changes dynamically, it is not desirable to distribute the tasks only attime of initialisation. So, DBB allows the system to undergo an organisational self-design [26],and changes the submanagers roles as the network structure varies.

In DBB each agent consists of three basic functional modules: the communication process, thecontracting process, and the task process. The communication process continuously checkswhether a message has been sent to the agent, and if so, transmit it to the contracting process,which parses them and does appropriate actions. Finally, the task process carries out the agent’smanagement task.

Agents' roles are not static. An agent does not have any management role as it enters the network.At the time of initialisation, or whenever required, the agents choose a chairman to elect the LANmanager. The chairman announces the election and selects the best nominate (eg. least busy host)and broadcasts its decision. After electing the LAN manager, all other agents become groupmanagers and execute tasks for information gathering. The LAN manager, which is responsiblefor managing the whole LAN, uses contracting to assign tasks to group managers. Finally, there isa fixed top manager, which uses contracting to request reports from LAN managers.

A network can have an arbitrary number of LAN managers and group managers. As LANmanagers have some sort of autonomy and independency, more LAN manager means moreautonomous and independent network management systems, which corresponds to higherrobustness. Increasing the number of group managers increases the number of polling agents,which corresponds to a more frequent polling and more updated management information.However, there is trade off between increasing number of LAN and group managers and extra

traffic caused by communication between top manager and LAN managers, and between eachLAN manager and its group managers.4.2.

Distributed Management Environment (DME)

The Open Software Foundation’s (OSF) Distributed Management Environment (DME) is anattempt to represent a structure under which the management of systems and networks can bebrought together [27]. It tries to provide a standard set of services to bring management toeverything, from bridges and router to server-based operating systems and applications [28].DME is operating system-independent and supports several standards, such as SNMP and CMIP.DME is tailored to OSF Distributed Computing Environment (DCE) [29]. DCE is acomprehensive and integrated service that allows development, distribution and maintenance ofdistributed applications. It masks the physical complexity of the networked environment andprovides a layer of logical simplicity. DCE uses RPC for communication and provides distributeddirectory services, security services, time services and thread services. Using services provided byDCE, DME provides manageability and allows network components and applications to be wellmaintained.

DME consists of a framework that provides the building blocks for application development andsome of the most critical system management functions, such as software management, licencemanagement and printing services. The architecture of the DME allows the addition of newservices. It consists of two key components: Manager Request Broker (MRB) and Object Server,as shown in Figure 4.

The MRBs are central pieces in the DME framework; they implement the basic APIs that accessthe services furnished by the DME. The MRB establishes a standardised programming interface toSNMP and CMIP, known as Consolidated Management API (CM-API). The MRB also provides

ManagementApplicationManagementApplicationManagementApplicationManagementRequestBroker (MRB)SNMP/CMIPManagementProtocolManagementRequestBroker (MRB)SNMP/CMIPAgentObjectServerObjectServerObjectServerAgentFigure 4. DME in details

a way for management applications to invoke one of the methods associated with a DME object.The object server provides access to the data stored in the object and can create or deleteinstances of an object. Whenever the MRB receives a message, it sends it to an object server thatis associated with the target object. The MRB finds the object by using the Distributed ComputingEnvironment (DCE) directory services.

The major problem of DME is that, if all network management platform vendors adapt theirsystem to the DME framework, there will be no differentiating features [30]. As a result platformvendors haven’t attempted to conform to the it, and although DCE gained success and popularityin the market, DME has not.4.3

Hierarchical Network Management

Hierarchical network management system [31] uses the concept of SubManager, similar to themanager-to-manager(M2M) protocol described in SNMPv2[32]. A SubManager is associatedwith a few agents, and collects the primitive information from them, performs some calculations,and produces more meaningful values that can be used by a superior manager. This methodsignificantly reduces the amount of management traffics, because only high-level information issent to the master manager.

Whenever network operators need more, or high-level, information a downloaded NetworkManagement Procedure (NMP) is dynamically assigned to the system. This allows dynamicreconfiguration at run-time, and removes the need to hard-wire everything at compile time [31].The NMPs are loaded into submanagers, and are stored in two tables: subMgrEntry andsubMgrOps. Each procedure is Periodically activated and a “Worker” is created, which

SubManagerCreate WorkersubMgrEntry get/response (SNMPv1/v2)AgentsubMgrsubMgrOpsControllersubMgrValueWorkerWorkersubMgr Presentation of resultManager Network Management Procedure (NMP)Figure 5. Internals of the SubManager

evaluates the procedure and stores the result into subMgrValue table This table is read by themanager. This procedure is illustrated in Figure 5.4.4.

Management by Delegation (MbD)

Most distributed management systems use a traditional client/server process interaction method,such as Remote Procedure Call (RPC). The current implementation of this architecture lacks therequired flexibility and needs recompilation and reinstallation of the application whenever amodification is made [1]. Management by Delegation (MbD) [33, 34, 35] is a more flexibleparadigm and uses the concept of elastic server [36], whose functionality can be extended atexecution time by delegating new functional procedures to it.

In MbD, instead of bringing a device’s data to the management platform application, applicationsare delegated to devices and executed in the same environment that data exists. The delegatorentity (manager) uses a delegation protocol to download and control a delegated program (DP).An elastic server resides in each device, which maintains and executes DPs, as illustrated inFigure 6.

DPDelegatorDelegation ProtocolFigure 6. Delegating to an elastic server

ElasticServerA DP may be delegated to a device at boot-time so that the device assumes autonomousresponsibilities to handle port failure. This will reduce the need for communication at the times ofstress. As automation of management functions distributes the load, the overall load on operationcentre is reduced. Also, MbD does not require a uniform semantic model of device data, whichsimplifies the handling of heterogeneity problem across devices and eliminates barriers tomanagement application development.

MbD can inter-operate with current management protocols, extend their capabilities and evenprovide a complementary paradigm to them. The entire protocol agents may also be incorporatedwith an MbD-Kernel as a delegated program, which allows flexible programming for provision ofdevice information. The other feature of delegation is that it may be used as a converter amongdifferent management protocol. For instance an SNMP device may be scripted to support CMIPaccesses, as well.

MbD improves the survivability of distributed systems by maximising their autonomy. Using MbDallows devices to acquire regional autonomous management capabilities, conditional on thenetwork status. In case of losing communication with management entities, the device mayactivate management programs that permit fully autonomous management.

5.Comparison

In this section a comparison is made to show the advantages and drawbacks of the discussedsystems. We focus our comparison on the performance of these systems for several requirementsof distributed network management systems, such as polling method, communication betweenlayers of management, extensibility and flexibility. The comparison is presented in Table 1 and willbe explained in the following paragraphs.

CentralisedDistributedDistributedHierarchicalManagementManagementBig BrotherManagementNetworkby DelegationEnvironmentManagementArchitectureCommunica-tion methodPollingmethodCentralisedN/ADirectHierarchicalContractingProtocolIndirect(via groupmanagers)LowGoodMediumHighHierarchicalRPCIndirect(via objectservers)LowFairHighMediumHierarchicalClient/ServerIndirect(viasubmanagers)LowFairHighMediumDistributed/HierarchicalDelegationProtocolIndirect(via elasticservers)LowVery goodVery highVery highPollingIntervalAutonomyExtensibilityFlexibilityHighN/ALowLowTable 1- Comparison of systems

All of these systems share the feature of not polling management information for the wholenetwork from a central location. Instead, they take in events, alarms and alerts from mid-levelmanagement platforms. As a result, the number of nodes that management information has totravel is significantly reduced. Although, the communication between each layer of managementintroduces a new bandwidth penalty, a much less amount of data has to be sent to the higherlayer. This is because raw data gathered from network elements is processed before being sent tothe higher level. In other words, the management traffic has been localised.

Also, as these systems use parallel polling, they reduce the time to poll the whole networkelements' status. Consequently, more recent management information is available. The time to pollthe network is directly related to the number of sublayer managers. However, increasing thenumber of layers increases the traffic because of extra overhead required for manager tosubmanagers communication. So, there is a trade-off between polling interval and managementtraffic.

The method of communication between each manager and its submanagers is different for eachsystem. DME and hierarchical network management are based on client/server architecture. DMEuses RPC for communication, and hierarchical network management utilises NMPs to downloadprocedure into submanagers. Distributed Big Brother employs contracting protocol to distributedthe task between submanagers. MbD, however, employs a completely new approach, known asdelegation protocol.

In current RPC-based systems, the communication is limited to the procedures defined at the timeof implementation. Although some techniques, such as Dynamic Link Library (DLL), allow moreflexibilty, still adding a new functionality to the system might require that the system beingshutdown, recompiled and installed again, which cannot be an everyday task. NMP conceptimproves this situation by allowing the addition of script at run-time. However, MbD enjoys fromdynamic reconfiguration by adding procedure at run-time, and delegating them to elastic servers.Managing a distributed network requires real-time access to the status of each network part. Aspolling several variables from each segment of the network is not efficient, these data should becompressed. One method of compressing operational data is computation of index functions,known as health functions [1]. Health functions, typically utilise a linear combination of someMIB variables, such as ifInOctets and ifOutOctets, at which status indicators change.Health functions are calculated at lower layers of management from the raw data, and the result ispolled by the upper layers from time to time. Whenever a fault occurs in the system, it may bedesirable to have a special health indicator which can help the manager localised the fault quickly.In systems other than MbD, the health functions are fixed and can not be changed easily. So, if therequired indicator has not been already provided, the manager has to poll raw data which may adda significant amount of traffic.

In terms of autonomy of submanagers, MbD and DBB provide more flexibility. Whenever a faultpartitions the network, so that one part of the network becomes unreachable from the centralmanagement station, the manager agents in that segment can get full autonomy, and monitor andmanage the network, until the connection is restored.

Most commercial distributed network management systems, such as Cabletron’s Spectrum, IBM’sSystemView and Hewlett-Packard’s OpenView, are based on the concept of ‘manager ofmanagers (M2M)’ [37]. This may be because of simplicity of this approach compared to theothers. However, MbD provides a more flexible approach. The popularity of Java [38] as aplatform-independent language has eased the implementation of MbD. As trend in networkmanagement is toward using flexible and scalable semi-autonomous area managers [39], it seemsthat MbD will get more popularity than any other available models.

6.Conclusion

In this paper, we discuss several distributed approaches for network management. Four of mostimportant architectures were discussed and compared with each other. Distributed Big Brother is

a system based on some AI techniques, such as contracting protocol, and self-organising network.It has been implemented at the University of Michigan, and has shown some satisfactory resultswhen appropriate numbers of LAN and GROUP managers were chosen.

Distributed Management Environment (DME) is based on OSF Distributed ComputingEnvironment (DCE) to bring the management of systems and networks together. DME does notseem to have successed.

Hierarchical network management uses the concept of submanagers and manager of managers ofSNMPv2, and utilises the manager-to-manager MIB to communicate between managementagents. This idea has been implemented in several commercial systems, because of its simplicityand the popularity of SNMP.

Management by Delegation (MbD) is a new approach for distributed management. It uses theconcept of an elastic server, which reside in each management agent, and its functionality can beextended in run-time by delegating procedures to it. It provides significant flexibility andautonomy for management agents. Management of huge and diverse emerging broadbandnetworks will justify the deployment of this approach, and the availability of platform-independentprogramming language, such as Java, will ease its implementation.Acknowledgment

This work is supported by a postgraduate scholarship from ministry of culture and highereducation of I.R. Iran granted to M. Kahani. The financial support of The Institute forTelecommunication Research (TITR) at the University of Wollongong is also herebyacknowledged.

References

[1][2][3][4][5][6][7][8][9][10]

Goldszmidt, German, “On Distributed System Management”, In Proceedings of the Third IBM/CASConference, Toronto, Canada, October 1993.

Case, J., Fedor, M., Schffstall, M., Davin, J., “A Simple Network Management Protocol (SNMP)”, RFC1157, May 1990.

Meyer, K., Erlinger, M., Betser, J., Sunshine, C., Goldszmidt, G., Yemini, Y., “Decentralising Control andIntelligence in Network Management”, Proceedings of International Symposium on Integrated NetworkManagement, May 1995.

Leinwand, A., Fang, K., “Network Management: A Practical Perspective”, Addison Wesley, 1993.

So, Y., Durfee, E., “Distributed Big Brother”, 8th International Conference on Artificial Intelligence andApplications, 1992, pp. 295-301.

Herman, J., “Enterprise management Vendors Shoot it Out”, Data Communication International,November 1990.

Stamatelopoulos, F., Chiotis, T., Maglaris, B., “A Scalable, Platform-Based Architecture for MultipleDomain Network Management”,

ITU-T Recommendation M.3010, “Principle and Architecture for the TMN”, Geneva, 1992.

Alexander, P., Carpenter, K., “ATM Net Management: A Status report”, Data Communication Magazine,September 1995.

Mullender, S., “Distributed Systems”, ACM Press Publication, Addison Wisley, 1990.

[11][12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27][28][29][30][31][32][33][34][35][36][37][38][39]Spector, A., “Achieving Application Requirement on Distributed System Architecture”, in DistributedSystem Book, ACM Press, Addison Wisley, 1990.

Coulouris, G., Dollimore, J, Kindberg, T., “Distributed Systems: Concepts and Design”, Addison Wisley,1994.

Nelson, B., “Remote Procedure Call”, CSL-81-9, Xerox Palo Alto Research Center, 1981.

Weal, W., “Remote Procedure Call”, in Distributed System Book, ACM Press, Addison Wisley, 1990.

“The Common Object Request Broker: Architecture and Specification-Revision 2.0”, Available at URLHTTP://www.omg.org/corbask.htm. July 1995.

Schmidth, D., “Object-Oriented Network programming: An Overview of CORBA”, Available at URLhttp://www.cs.wustl.edu/~schmidt/corba4.ps.gz.

Agoulmine, N., “Distribution of Management Over Multi-Domains Network Management Systems”, IEEEGLOBECOM’93, 1993, pp. 1217-1221.

RACE Project - Research and Technology Development in Advanced Communications technologies inEurope, RCO-CEC, Brussels.

Ahrens, Mike, “Key Challenges in Distributed management of Broadband Transport Networks”, IEEEJournal on selected areas in communications, vol12, no. 6, August 1994, pp. 991-999.

Kiriha, Y., Nakai, S., Sakauchi, H., Okazaki, F., Okazaki, H., “Concurrent Network Management Systemusing Distributed Processing Techniques”, IEEE GLOBECOM’93, pp. 202-206.

Lee, k., “A Distributed Network Management System”, IEEE GLOBECOM’94, 1994, pp. 548-552.

Stamateopoulos, F., Roussopoulos, N., Maglaris, B., “Using a DBMS for Hierarchical networkmanagement”, Engineering Conference NETWORLD+INTEROP ‘95, March 95.

Madruga, E., Tarouco, L., “Fault management Tools for a Cooperative and Decentralised NetworkOperations Environment”, , IEEE Journal on selected areas in communications, vol. 12, no. 6, August 1994,pp. 1121-1130.

Zhang, X., Seret, D., “Supporting Network Management Through Distributed Directory Service”, , IEEEJournal on selected areas in communications, vol. 12, no. 6, August 1994, pp. 1000-1010.

Smith, R., “The Contract Net Protocol: High-level Communication and control in a distributed ProblemSolver”, IEEE Transaction on Computers, C-29(12), December 1980, pp. 1104-1113.

Corkill, D., “A Framework for Organisational Self-Design in Distributed Problem Solving Networks”, PhDthesis, University of Massachusetts, Feb 83.

“DME Overview”, OSF online document, OSF-DME-PD-0394-2, 1992.

Herman, J., “Distributed Network Management: Time runs for mainframe-based systems”, DataCommunications Magazine, June 1992, pp. 74-84.

“The OSF Distributed Computing Environment”, OSF online document, OSF-DCE-PD-1090-4, 1992.

Acosta, Victor S., “OSF/DME (Distributed Management Environment)”, Available at URLhttp://www.frontiernet.net/~/vsa184/paper/osf-dme.htm.

Siegle, M., Trausmuth, G., “Hierarchical Network Management: A Concept and its Prototype in SNMPv2”,JENC6, 1995, pp. 122/1-10.

Case, J, McCloghrie, K, Rose, M, Waldbusser, S, “Introduction to version 2 of the Internet-standardNetwork management Framework”, RFC 1441, SNMP Research Inc. Highes LAN Systems Inc., DoverBeach Consulting Inc., Carnegie Mellon University, April 1993.

Yemini, Y., Goldszmidt, G., “Network Management by Delegation”, 2nd International symposium ofIntegrated Network Management, April 1991.

Goldszmidt, G., Yemini, Y., “Evaluating Management Decisions via Delegation”, 3rd Internationalsymposium of Integrated Network Management, April 1993.

Goldszmidt, German, “Distributed Management by Delegation”, Proceedings of 15th InternationalConference on Distributed Computer System, June 1995.

Goldszmidt, German, “Distributed System Management via elastic Servers”, Proceedings of 1st IEEEinternational Workshop on System Management, April 1993.

Jander, Mary, “Distributed Net Management: In search of Solution”, Data Communication Magazine,February 1996.

“Java Language Specification: version 1.0 Beta”, Sun Microsystem, 1995.

Wellens, C., Auerbach, K., “Towards Useful Management”, The Simple Times, Vol. 4, No. 3, July 1996.