A Layered Architecture for Network Management ... - Semantic Scholar

Download PDF
3 downloads 526 Views 25KB Size Report
Comment
Jun 25, 1998 - In this paper, a network management architecture is presented, which is ... [8, 9], which uses CMIP to issue requests for management services.
Network and Optical Communications (NOC’98) Manchester, UK, 23-25 June 1998

A Layered Architecture for Network Management Applications Nikos A. Nikolaou, Odysseas I. Pyrovolakis, Aggeliki A. Dede, Theodore B. Zahariadis, George I. Stassinopoulos National Technical University of Athens Department of Electrical and Computer Engineering Heroon Polytechniou 9, 157 73 Athens, Greece e-mail: [email protected] Telephone: +30-1-77 21 512, Fax: +30-1-77 22 534 Abstract The crucial role of networked systems has increased the competition stemming from new services. New technology communication products are required in order to provide better quality of service and reduce both risks and cost [1]. In an open multiventor environment, management applications, compliant with standards, are mandatory. In this paper, a layered network management architecture is presented, based on the use of current network management standards and experience gained while building Network Management Systems (NMS).

1.

Introduction

In this paper, a network management architecture is presented, which is organized in successive layers (Figure 1), each of which constitutes a component with a predefined interface. Some of the components are based on standards of SNMP and CMIP [2], providing the framework to be used. At the same time, two decisive components have been identified - MIB Handler and Communication SNMP-based CMIP-based MIB MIB Manager - whose design and implementation is not determined by well known standards. W e can define specific interfaces for those non-compliant with standards components, which will support a minimum set of operations, SNMP CMIP covering their desirable functionality. SNMP CMIP The first two layers of the proposed architecture cover the topics of Agent MIB Handler Agent Alarm Handler storage and acces s of network management information. They are based on Threshold Handler two widespread management protocols: SNMP [3] and CMIP [4]. MIB Handler is responsible for the management information maintenance Communication in a continuously updated state. Additionally, MIB Handler incorporates two Manager sub-components Alarm Handler and Threshold Handler. NE Communication Manager (CM) undertakes the responsibility of providing a common interface to Network Elements (NEs), hiding their peculiarities and Figure 1. Proposed Network enforcing an efficient utilization of network resources. Management Architecture Incorporating different components with predefined interfaces, we achieve to organize a layered architecture for building network management applications and thus, make the network management system easy to be understood, implemented and expanded. In section two we describe the structure of the Management Information Base (MIB). Interaction with MIB is discussed in section three. In section four we present the MIB Handler component, which incorporates sufficient knowledge for keeping MIB in an up-to-date state. Section five describes the Communication Manager. Finally, we conclude this paper with design issues concerning the proposed architecture.

Network and Optical Communications (NOC’98) Manchester, UK, 23-25 June 1998

2.

Management Information Base - MIB

MIB is the core component of a Network Management System. It is organised in a well-defined manner, providing clear interfaces to access, update and delete information. In fact, MIB is used to model the most important functional units of NEs, reflecting their time-changing condition. MIB provides a view of the underlying network resources, hiding unnecessary information. The concept of MIB is viewed in regard to the underlying network management protocol. There are two approaches, one based on Simple Network Management Protocol (SNMP) and, another, based on Common Management Information Protocol (CMIP). Generally, MIBs based on CMIP can model complex network resources [5], whereas the modelling power of SNMP-based MIBs is limited. However, memory and processing resources needed to handle managed objects are by far more demanding in the case of CMIP than SNMP based MIBs. The SNMP Structure of Management Information (SMI) is based on collections of objects [2] defined using ASN.1 notation. On the other hand, the OSI SMI is based on collections of objects, some defined in X.720 series of standards, whereas others can be found in the TMN M.3100 standards [6]. In the case of TMN MIBs, access to managed information is provided by the Common Management Information Service Element (CMISE) [8, 9], which uses CMIP to issue requests for management services.

3.

MIB Handler

MIB is a structured collection of information, regarding the underlying SNMP-based CMIP-based MIB MIB network resources. It is essential for the objective of Network Management System (NMS) to be able to perform operations on the MIB, in order to maintain it in a continuously updated state. This significant issue is SNMP CMIP undertaken by a separate component, named MIB Handler (Figure 2). MIB Handler holds the role of the interconnection-link between NEs and managed objects stored in MIB. On this account, it must have interfaces to MIB Handler CM and the utilised network management protocol. In general, MIB Handler Alarm Threshold Handler Handler should incorporate the following functionalities: send requests to NEs and receive answers, process data received from NEs and, finally, update Figure 2. MIB Handler information that resides in MIB. MIB Handler should embody knowledge concerning the way in which useful information is taken from NEs. It should know which specific commands must be sent to the NE and how their responses must be interpreted. This process of extracting information may be resource and time consuming. In such cases, commands should be sent thrifty. Responses received from NEs contain data in a format that MIB Handler should be able to understand. Useful data will be processed, so that the information that is necessary to update the MIB is obtained. This processing includes the mapping and combination of proprietary parameters and values to attributes defined by network management standards. Based on gathered information, MIB Handler proceeds to update MIB. Update process comprises the creation of new structured information, the deletion of out-of-date data and the modification of existing data. The major objective is to provide a consistent view of managed NEs. On this account, On this account, MIB Handler incorporates an update policy that aims at keeping the MIB up-to-date on periodic, demand and event basis. MIB Handler contains two sub-components that deal with alarms and thresholds. Alarm Handler is responsible to check for existing alarms and process them, in order to determine the malfunctioning unit, the cause of the problem, as well as any other affected functional units. In some cases, it is desirable to make correlation among existing alarms, generate summary of alarms in case of storms of events. This process of combining alarms is time consuming and requires a considerable amount of resources. Threshold Handler is a sub-component of MIB Handler, responsible for maintaining and monitoring a set of threshold values over NEs. Whenever it is sensed that a threshold is exceeded, a notification or warning will be emitted.

Network and Optical Communications (NOC’98) Manchester, UK, 23-25 June 1998

4.

Communication Manager

Communication Manager hides the NE’s peculiarities, realises protocol translation, establishes virtual communication channels to NEs and provides a consistent and uniform interface between the NE and the MIB Handler. Based on common experience, a small number of well-defined operations is usually needed, in order to communicate with a network resource. Those operations include: ?? OpenComSession, which opens a session with a NE. Each session represents a virtual channel to the NE. A new communication channel may be established every time it is needed. On the other hand, it is possible to maintain a pool of active channels, ready to be used according to communication needs. ?? TerminateComSession, which terminates an established session. The communication channel may be permanently destroyed or it returned to the pool for future use. ?? SendCommand, which is used to send to the NE a command or a sequence of commands. ?? ReceiveDataSynchronous, which is used to receive a response from a NE in a blocking manner. ?? ReceiveDataAsynchronous, which is used to receive a response from the NE in a non-blocking manner. Facing the communication with a specific type of network resource as a distinct entity, it eliminates the cost of implementation, since CM is split in simpler parts. Furthermore, CM can manage the resources required to establish and maintain connections, in an efficient way and according to limitations imposed by the specific NE. Network Management is, in most cases, not restricted in a specific kind or type of NEs. A network consists of many different types of NEs. Each NE must support standard or proprietary access protocols, which may vary from those of a NE of another type or even of the same type. Thus, it is proposed to divide CM to subcomponents that will implement the particular features emerging from each NE. In this way, we are able to distinct the differences between NEs and concentrate on them. MIB Handler It is clear that CM should be constructed in a hierarchical OpenComSession TerminateComSession SendCommand fashion. A two-layer architecture seems to be a straightforward ReceiveDataSynchronous ReceiveDataAsynchronous approach (Figure 3). Layer 1 will consist of a number of subLayer 2 CM Operations components that implement a specific protocol. Each sub- Communication Manager component of Layer 1 will embody all the knowledge that is Protocol 1 Protocol 2 Protocol 3 Layer 1 necessary to communicate with a specific type of network resource. NEs of the same type will each directly communicate NE1 NE2 NE3 with a distinct sub-component of Layer 1. A second layer will hide the sub-components of Layer 1 and provide a uniform Figure 3. Communication Manager interface to access NEs. Thus, CM serves as a stable path to reach and communicate with NEs.

5.

Conclusions

In a modern telecommunications network, the presence of a mechanism for resource management is necessary, as it will allow immediate monitoring and, at the proper time, prevention and correction of erroneous and abnormal situations. A Network Management System must be based on the widely utilised protocols of SNMP and CMIP. Network management standards establish the framework to be used. At the same time, two important components have been identified - MIB Handler and Communication Manager - whose design and implementation is not determined by well known standards. Specific interfaces can be defined for these two components that will allow the effective interaction between them and their adjacent components, shown in Figure 1. Thus, we result in a layered architecture for Network Management Systems, which is scalable, expandable and easy to be understood and implemented [10].

6. [1] [2] [3]

References A. Leinwand and K. Fang, Network Management: A Practical Perspective, Addison-Wesley, 1993. Stallings, W., SNMP, SNMPv2 and CMIP: The Practical Guide to Network Management Standards, Addison-Wesley, 1993. J. Case, M. Fedor, M. Schoffstall and J. Davin, Simple Network Management Protocol (SNMP), STD 15, RFC 1157, May 1990.

Network and Optical Communications (NOC’98) Manchester, UK, 23-25 June 1998

[4]

X.711- OSI Management, Common Management Information Protocol (CMIP) Specification for CCITT Applications. [5] Yechiam Yemini, The OSI Network Management Model, IEEE Communications Magazine, May 1993. [6] M. 3100 (1992) Maintenance Telecommunications Management Network, Generic Network Information Model. [7] X.721 ISO/IEC 10165-2 (1992) - Information Technology - Open Systems Interconnection - Structure of Management Information: Definition of Management Information. [8] X.710 - OSI Management, Common Management Information Service (CMISE) Definition for CCITT Applications. [9] Lakshmi Raman, CMISE Functions and Services, IEEE Communications Magazine, May 1993. [10] Theodore B. Zahariadis, Aggeliki A. Dede, Nikos A. Nikolaou, Odysseas I. Pyrovolakis, Nikolaos Skiadas, Ilias Iliopoulos, George I.Stassinopoulos, Implementation of a TMN ISDN Mediation Device: Practice and Experience, accepted for presentation in the International Conference on Telecommunications, Chalkidiki, Greece, 22-25 June 1998.