CERBERUS NETWORK MANAGEMENT SYSTEM (CNMS) An Expandable, Experimental Network Management Platform

Transcription

1 CERBERUS NETWORK MANAGEMENT SYSTEM (CNMS) An Expandable, Experimental Network Management Platform National Technical University of Athens (NTUA) Division of Computer Science Department of Electrical & Computer Engineering Zographou, Athens, Greece Network Management and Optimal Design (NETMODE) Laboratory Fotios Stamatelopoulos Konstantinos Stathatos Theodoros Karounos Prof. Basil Maglaris

2 CERBERUS NETWORK MANAGEMENT SYSTEM (CNMS) An Expandable, Experimental Network Management Platform Introduction Cerberus Network Management System 1 (CNMS) is an experimental NMS platform developed within the NETMODE laboratory in National Technical University of Athens (NTUA). CNMS has been implemented for the MS-Windows graphical environment and is being tested on our campus high speed LAN. Expandability CNMS consists of two functional modules : the Network Management Server (NMS) and the Network Management Client Applications (NMCA). NMS is the core of the system and offers a simple, yet powerful, set of network management functions (services) to the applications it supports. NMCAs are applications-clients that operate on top of the NMS, utilising its services according to their needs. NMS does not offer an inherent user interface, which on the other hand can be developed as a NMCA. A graphical UI is currently being designed and implemented as the first NMCA. This client-server mechanism and the ability to build custom network management applications on top of a common NM platform, makes CNMS expandable and adaptive to user needs. In addition, it permits the concurrent and harmonious execution of multiple NM applications with different functionality, since they all use the same NM Server. Efforts are being made to improve this feature, that is to say to make producing NMCAs easier and less coding-demanding. Portability CNMS is designed with a modular structure as will be demonstrated further in this document. Moreover, the functional modules of NMS are arranged in a layered way. Modules use the services of lower ones and offer their services to modules of the higher levels. The current implementation (which is under development) supports TCP/IP networks and uses the SNMP protocol and the MIB-I and MIB-II definitions (we are working on supporting proprietary MIB extensions). By making changes only to the appropriate modules (namely changing the MIB definitions and rewriting the network interface module) portability to CMOT can be easily achieved without designing or even coding from scratch. We continue to work on improving the conceptual design schema trying to accomplish a higher degree of portability. 1 named after the ancient creature that guarded the gates of Hades in Greek mythology. Cerberus was the first communication management system, since he controlled what would go in and out from Hades. 2

3 Object Oriented Philosophy The modular design of CNMS as well as the event-driven style of programming imposed by the modern graphical environments (X-Windows, MS-Windows, etc) have urged us to adopt the object-oriented paradigm. Modularization and isolation of the NM Server's layers can be achieved by abstraction (both procedural and data) and encapsulation, reducing at the same time complexity. Inheritance is another feature of Object Oriented Programming (OOP) that together with encapsulation helps minimise rework when updating the NM Server or writing from scratch a NM Client Application. Viewing layers as objects (instances of classes) that communicate through messages, offers isolation that makes design, implementation and testing simpler and easier. In the current implementation we are using C++ as the implementation language. C++ supports object-oriented programming and, being an extension of C, is the best means to tame the world of MS-Windows. In addition, C++ (compared to other OOP languages like Smalltalk) produces fast, small and efficient code and keeps the flexibility of C. Structural Decomposition of the CNMS The structure of NMS can be decomposed in three layers as demonstrated in figure 1. Each layer uses services of its preceding layer in the stack and offers services to the following layer. Layer 1 contains the Network Interface (NI) module. Layer 2 contains the five management functional modules of the server : Network Object Manager (NOM), Monitoring (MON), Event Handler (EH), Alarm Manager (AM) and Log Manager (LM). These are based on the newer Systems Management Functions [1] proposed by the OSI committees [2]. According to the OSI proposals, the CFAPS management model [3] can be built using these generic fuctions. Layer 3 contains the DDE Server (DDES) module. NMCAs appear as an additional layer standing on top of the three layer stack, using their services through layer 3. 3

4 Management Applications (NMS GUI, Microsoft Excel, etc) Layer 3 DDE Server Log Manager Monitoring Layer 2 Alarm Manager Event Handler Network Object Manager Layer 1 Network Interface (SNMP Manager) Figure 1 Network Interface (NI). This is the front-end module that interfaces the Sever to the network to be managed. It contains a SNMP parser and packet builder, a Dispatcher and links to the TCP/IP drivers. All the other modules that need to communicate with the SNMPAgents issue requests to this module. NI builds and sends the appropriate packets for each request. Upon receipt of a packet (response or SNMP trap) the Dispatcher routes the parsed message to the responsible module. Network Object Manager (NOM). This module keeps and updates the configuration (CB) and inventory data base of the managed network. All resources, as well as the variables of the MIBs are treated in an object-oriented philosophy (similar to that in CMIP). Other modules or NMCAs can issue queries to NOM requesting topological, configuration or inventory information in this objectoriented framework. NMCAs can also issue requests for topological changes. This changes include add or removal of a node or LAN to the CB (i.e. to the managed objects) or change to the information about a node contained in the CB. All changes are check for validity from NOM This module uses services of the NI module. We are working on designing a mechanism of automatic detection of topology on installation by NOM. This mechanism will find all nodes having IP addresses and detect nodes equipped with MIBs when the CNMS is first installed or on user demand. Alarm Manager (AM). This is the module that manages the alarm mechanism of the NM platform. It offers predefined alarms for fault rates, probabilities, queue 4

5 lengths and throughput. The client application sets the alarms to be monitored by the AM, the threshold and the time interval for each alarm. User defined alarms can also be set by any NMCA. This module uses services of the NI and NOM modules. Event Handler (EH). This is the module that handles all the SNMP traps received from the NMS and the pseudo-traps generated by various modules in certain occasions (for example NI generates a Host-Down pseudo trap when the response from a host times out). The services offered by this module include configuring an event-trap filter and customising the reports generated on event receipt. For example a NMCA that uses the services of the EH can set an event filter that will permit report only of certain events (traps). This module uses services of the NI and NOM modules. Monitoring (Mon). A NMCA may request from this module to monitor a group of MIB objects (variables or tables) of a single or multiple nodes and provide the changing values in real time. Apart from monitoring MIB objects, MON has the ability to execute on demand certain calculations for reporting in real time throughput and fault rates or probabilities. A NMCA may, also, request an MIB walk, i.e. a dump of a specific MIB. In addition MON keeps copies of all the MIBs of the managed network in a data base (in the current version it is a flat file - it may expand to an RDBMS) which updates periodically (time interval set by the user). MON uses services of the NI and NOM modules. Log Manager (LM). This module keeps and updates all the log files of the CNMS containing information about alarms, events, configuration changes and the client applications that set them. Any NMCA may request customised reports from LM about information stored in the log files. LM updates the logs upon notice from the EH or AM or NOM modules. Dynamic Data Exchange Server (DDES). DDES interfaces NMCAs to the modules of NMSS that offer services. NMCAs issue requests to the DDES and receive responses containing information or result codes. DDES passes the requests to the appropriate modules and waits for an answer. In the current implementation this mechanism uses the DDE method [4] of MS-Windows environment. Various MS-Windows application support this mechanism. Microsoft Excel is one of them, which offers a simple user interface to NMS. The user can build in an easy user friendly way, customised Excel worksheets containing managing information (for example throughput or MIB variable values) that are being automatically updated in real time without any user interaction. 5

6 Software Engineering Topics - Design and Analysis Object oriented analysis and design (OOA and OOD) are relatively young methods. Standardisation is not yet achieved and substantial research is conducted world wide on these topics. In the analysis of our system we have adopted the structural analysis method [5][6]. Structural analysis is an old and well tested method and does not limit the design and implementation to the object oriented approach. Thus the analysis we have completed (expressed in the Software Requirements Specification Document [7] ) can be used to port CNMS to any system using any method of design and implementation, object oriented or not. In the current development we have adopted an OOD method being guided by several books and papers on OOD and OOA [8]-[11]. Using the results from the analysis procedure we define entities and then classes structured in hierarchies and relationships. For each entity-class attributes and services, that manipulate the attributes, are defined. Hierarchy and inheritance form the basis for a significant technique of explicit expression of commonality. This principle allows to specify common attributes and services once, as well as to specialise and extend into specific cases. We will continue to work on OOD in order to improve the efficiency of the design process. Good design results to less effort in implementation, better code and easier testing. References [1] Datapro International, OSI-Based Network Management, Network Management Information Service, 1991 [2] International Standards Organization, OSI Systems Management Functions, DIS through [3] International Standards Organization, Specific Management Fuctional Areas, N4981, N875R, N4091, N4077, N3311. [4] Microsoft Corporation, Microsoft Windows Software Development Kit, Volume 2, version 3.0, [5] Skordalakis, E., Introduction to Software Engineering, Symmetria Publications, [6] DeMacro, T., Structured Analysis and System Specification, Yourdon Press, New York, [7] IEEE Standard for Software Requirements Specification, IEEE Guide to Software, ANSI/IEEE Std [8] Coad, P. and E. Yourdon, Object-Oriented Analysis, Prentice Hall, 1991 [9] Coad, P, and E. Yourdon, Object-Oriented Design, Prentice Hall, 1991 [10] McGregor, J.D. and T. Korson, Understanding Object-Oriented : An Unifying Paradigm, CACM No. 9, pp , 1990 [11] Ballin, S.C., An Object-Oriented Requirements Specification Method, CACM No. 5, pp ,