Interaction of a TMN-oriented Network Management Platform with a Network Planning application M. Calisti
Arti cial Intelligence Laboratory Swiss Federal Institute of Technology (EPFL) IN-Ecublens, CH-1015 Lausanne, Switzerland Voice: +41-21-693-6677 Fax: +41-21-693-5225 E-mail:
[email protected] .ch
Abstract The TMN, Telecommunication Network Management, is both an architectural framework and a structure, in which the management of heterogeneous hardware becomes possible. The main goal of TMN is to allow di erent vendors management platforms with di erent managed devices and also to guarantee a good portability of management applications. In this general context the CMIS/CMIP (Common Management Information Service/Common Management Information Protocol) protocol has been developed by OSI to support the exchange of management information between manager and agents. The interaction between a Network Resource Planning (NRP) application and the Global Manager of the network is supported by an Application Interface (API) which follows the CMIS paradigm. This paper describes the basic steps required in implementing an Application Programming Interface. Following the reference, given by the Network Management Forum, (see [3]), in order to have a framework independent of the constructor of the management platform. In fact even if the communication behaviour required for inter-operability between management system has been speci ed by the various standards, it is the application developer that must de ne the nature of implementations that exhibit that behaviour. To test a speci c interface it is then possible to use a simulation. This testing work is outlined, describing the main features of simulation studies supported by the CMIS/CMIP protocol and the information model conformant to this standard.
Keywords: Telecommunication Network Management, CMIS/CMIP, Network Planning, Information Model, Application Interface
1 Introduction Network managers are demanding more and more from their Network Management Platform. They want them to be easier to use, o er more information, and expand their management capabilities, such as adding system management and performance tuning. This involves a good capability of interaction with software application modules, developed to optimise the deployment of Network Resources. Section 2 introduces the Telecommunication Management Network framework, describing the manager/agent paradigm. This explains how TMN supports a management function. Communication between management entity involves two main issues: the communication protocol and the information model. These two latter topics are brie y presented in sections 2.1 and 2.2. To describe all steps involved in the interaction between a Network Management Platform and a software application, this paper focuses on describing Network Resource Planning (NRP) tools (see sec. 3). The main reason of this choice is that NRP needs to strictly interact with the Network Management, and thus provied good example of all the issues that have to be taken into account, when developing an Application Programming Interface. Furthermore, NRP applications are becoming more and more important in various situations:
with an application architecture which is geographically dispersed, with a large number of users, that have to interface among di erent servers and/or databases. When the network is a shared resource and it is vital to discover possible single-points-of-failure or bandwidth bottlenecks. With the emergence of new carrier services and new network technologies, such as ATM, servicelevel guarantees are required for network users. Several new applications, namely many Multimedia services, require a certain degree of Quality-of-Service. When there are changes on the network at the application level or in communication patterns as well as enhancements to communication infrastructure. Once the API is developed, simulation seems the most suitable instrument to test its performance. Section 4 shows the main steps involved in the simulation set-up. Some nal remarks are provided in section 5.
2 TMN Network Management Paradigm: Agent/Manager Interaction The notion of TMN was developed by the ISO/CCITT in recommendation M.3010. The main goal is to allow di erent vendors management platforms with di erent managed devices and also to guarantee a good portability of management applications. A TMN management function is essentially a cooperative activity involving two application processes, also called management entities, one in a managing system and the other in a managed system. A managed system could be a network resource, such as modem, network node or computer system. A management entity is an application that supports either manager or agent services. Agents gather and store information about resources to provide a uniform interface between managers and Management Information dataBase (MIB). In addition an agent may spontaneously generate noti cations messages to the manager indicating the occurrence of events in the managed object under its control. Managers process and interpret the information that agents provide. Both the manager and the agent have an information model that represents the resources in the network. Their communication about resources is based on shared information in their respective information models. Both information and communication models have been standardised to allow an higher degree of inter-operability and portability. Common Management Information Service/ Common Management Information Protocol (CMIS/CMIP) is the protocol, developed by OSI, that supports the exchange of management information between managers and agents. The Information Model addresses in a generic fashion the abstractions of those aspects of network resources required for management purposes.
2.1 Communication Support: CMIS/CMIP
The reference model follows a client/server paradigm, and is speci ed in two parts: The interface with a user: CMISE. CMISE provides the management entity with an entry point to the OSI stack. CMISE also allows elements residing in the application layer to communicate with each other using the common management information protocol (CMIP). The CMIP protocol speci es the protocol data unit (PDU) format and associated procedures. For the management-operation services, the CMISE element employs CMIP to exchange protocol data units. Before managers and agents can communicate, an association must be established between them. Once the association is established, the manager and the agent communicate using the CMIP, g. 1. The system management has to handle objects modelling the network elements. The possible operations, performed by the CMIP, can be listed as follows:
M CREATE to create an instance of a object in the agent's MIB. M DELETE to delete an instance of a managed object in the agent's MIB. M ACTION to request user perform an action. M SET to modify management information, namely attributes values of objects. M GET to retrieve management information, getting attributes value of objects. M CANCEL GET to cancel a previously requested and currently outstanding invocation. M EVENT to report an event about a managed object. The services can be con rmed or not. A con rmed service requires a remote management process sends a response to indicate receipt and success or failure of the requested operation; non con rmed services do not provide response.
2.2 Resource Information Modelling
The Information Model addresses in a generic fashion the abstractions of those aspects of telecommunications resources required to manage a network. Following the Guidelines for the De nition of Managed Objects (GDMO) [4], and using the Abstract Syntax Notation.1 (ASN.1) [5], a general class library has been de ned. The general classes are technology-independent and are characterised by a series of attributes, noti cations and allowed actions, g. 2. The attributes allow users to control and/or observe the behaviour of the resource. Attributes may also allow users to control and/or observe the relationships between resources. Resources may be physical or logical. Physical resources include customer or provider systems (PBXs, digital crossconnect systems), their associated subsystems and also the links that interconnect them. Such systems are generally called Network Elements (NEs). Logical resources include communication protocols, applications programs, and network services. System-management operations or actions apply to the attributes of an object or to the managed object as a whole and de ne the behaviour of the managed resource. When some external or internal occurrence a ecting the object is detected, managed objects emit noti cations. Noti cations can be transmitted externally in a protocol or logged and are usually contained in an event report. In a real management system, instances of these standardised classes represent the objects to be managed and stored in the Management Information Database (MIB), g. 3.
3 Application Programming Interface de nition This section describes a particular case of interaction between an application (representing a possible set of user-requirements) and a speci c Network Management Platform (NMP). In recent years a lot more applications requiring increased inter-operability with Network Management have appeared. The information that needs to be exchanged is largely data normally handled by the Network Management Agent
Manager
CMIP CMISE
CMISE
OSI Stack
OSI Stack
Figure 1: CMISE/CMIP logic position in the Management Model.
Agent OBJECT GDMO
M-Create M-Delete
M A
Attribute 1
Real Resource characteristics
Attribute 2
M-Get, M-Set
N
Attribute 3
A
...................
G
Action 1
E
Action 2
M-Action
actions
...................
R M-Event-Report
Notification 1 Notification 2 ...................
events
Figure 2: Real Resources and Information Objects Class formal definition of an object’s managed class
Switch device
Attributes Id equipment Localisation Serie’s number Operational Status Utilisation Status Administrative Status Notifications Status changed Alarm equipment Actions Test Reset
instance of the class in the MIB ATM switch MIB XCON2 Object
XCON1
Objects class managed= equipment Equipment name=ATM switch Id Equipment= switch 1 Localisation= "RSM" Operational Status=" enabled" Utilisation Status= "active" Administrative Status= "unlocked"
Figure 3: Class and object. System (NMS), data concerning alarms and general events in the network and control information for intervening directly in Network Con guration. Network Resource Planning (NRP) applications are one type of application which requires direct interaction with NMS. Such information must pass between the Network Planning Tool and the NMP(see below 3.1). Even though standards for the communication of management information between management systems exist, these are just general interface de nitions and an application developer must still implement all the underlying functions and methods. Any system which is to interact with a real network must work with an interface of this sort and doing so can be a very complex software engineering task. When building such interface the primitives which one has to work with are very low level. Standards specify management primitives (such as MGET, MSET routines etc. for the CMIP protocol) that work over the managed objects in a speci c database (the Management Information Database (MIB) for SNMP or the Guidelines Objects Model (GOM) for CMIP) 2.1, 2.2. These primitives provide a basic coordination mechanism to allow inter-operability between two network operators, or between an application tool and a Network Management Platform. To build an Application Programming Interface(API) the following issues have to be considered: The information needing to be retrieved for the NRP from the NMP. The information which can be e ectively retrieved from the NMP. How knowledge about network resources is mapped into object instances present in the general database (Management Information Database) holding all the network information. Selecting the appropriate communication protocol primitives to support the dialogue. It is clear that this requires not only a deep knowledge of what the software application has to do but also deep knowledge of how the speci c Network Management Platform works, the language required to interact with it (namely the communication protocol) and the general structure of the information model. Knowledge of this depth normally requires a network management expert. Developing such an interface requires time and a good understanding of di erent standards and Information Models.
3.1 Network Resource Planning
Because of the increasing rate of change occurring in most Network environments, many Network Managers addressed the need for 'real-time planning'. In the Network Management world, the Network
Resource Planning (NRP) application, is a software-supported set of processes that ensure distributed applications achieve an acceptable Quality-of-Service at minimum network cost. The main needs for the Network Planning Resource application that are considered here can be summarised as follows: Network Con guration Detection of new demands between two end-points. Monitoring trac statistics to check if the QoS constraints are satis ed. Detection of failures. Detection of shutdowns. Di erent phases are involved. First of all the NRP application has to acquire general data de ning the network and its current state, in order to create and maintain accurate and complete documentation of the current physical network con guration. This involves collecting of information about the trac volume to produce a baseline of the network in terms of network trac utilisation. Then, using recovered data, statistical descriptions can be created to model the network load. These statistical descriptions model the impact of an application on the existing network, allowing some prediction on the network behaviour under speci ed conditions. Furthermore mathematical and/or heuristic algorithms are used to design optimal cost or performance solutions and to resolve reliability problems. Finally these solutions to be implemented, have to be passed to the Network Management platform, which is responsible for translating the conclusions into a physical reality.
3.1.1 Exchange of Network Information
A possible solution to support the exchange of information between the Network Resource Planning and the API is represented by the implementation of a common database, to which both NRP and API can have independent access. Today, di erent commercial databases are available, which are fast and quite simple to use. They o er standardised primitives to store and read data. The API reads the information describing the Network Topology. There can be changes on the network and these changes should be detected and stored in the MIB by the Network Management entities. Then the API retrieves this information from the global MIB(network level view) by using the CMIS primitive M-GET and stores them into the common database. There is also a ow of information from the common database to the global MIB. The NRP application writes the new Network Con guration or more generally the results of its computations, into the database. It speci es all the links involved to allocate each demand between any two nodes in the network.
3.2 Application Programming Interface Implementation
This session describes di erent steps that have to be followed in order to realize the API. The API has to read names and values of attributes describing each managed object. To retrieve this data from the global MIB, the API sends the M-GET(...) CMIP primitive to the agent of the Global Manager Network. This agent can directly handle the MIB's objects. After API gets back this information, it writes it into the common database, from where the NRP can retrieve all information needed to know the network topology. To coordinate the two parts one can imagine a signal from the API to the NRP saying that a new Network Con guration has been stored in the common database. At some time the NRP calculates a new resource plan, in order to optimise the allocation of all demands in the network. It writes this information in the global MIB. It is possible to establish a polling mechanism to force the API to periodically read the information stored in the common database. But it would be better to coordinate the write and read operations, with signals exchanged between the API and the NRP. The coordination between the two modules is indeed crucial. When the API gets a new Network Con guration, two main actions have to be taken:
Network Resource Planning
cm
common database
API
MIB
agent Global Network Manager
global network view
agent
agent Network Element 1
Network Element N
local MIB
agent
local MIB
Network Element 2 local MIB
Figure 4: Modules involved in the interaction between NRP and NMP.
{ a loop to delete the connections previously established. The M-DELETE(\old subnetworkConnections") CMIP primitive has to be used. { a loop to establish the new connections: M-CREATE(\new subnetworkConnections") CMIP primitive has to be used.
4 Simulation Set-Up Once the API has been developed, a good instrument to test its interaction with Network Management platform is the simulation. In fact, before implementing this interface in a real environment, one should verify that the right objects are considered and that all di erent components involved work together as expected. Today, the market o ers di erent TMN Simulator Tools, that are able to create a simulated environment. Those simulators support CMIS/CMIP as a communication protocol, and are GDMO and ASN.1 conformant, allowing to be speci ed as a standardised MIB. The steps for the general testing procedure could be summarised as follows: Initialise the API. Start the agent with which the API will interact. This agent can be a simulated entity, run by a TMN Simulator Tool. From the API establish the necessary associations with the agent. Perform the test scenarios for the component of the API it is being tested.
4.0.1 Virtual MIT from MIB
The Management Information Base(MIB) contains GDMO de nitions for all the possible resources that an agent can administer. The MIB includes all managed information, including managed objects, the rules governing them, and the tree-like structure in which they are stored. In these studies, the standard MIB, proposed by I-ETSI and called GOM [6], has been implemented. This library is aimed to support the de nition of interfaces for the Network level view. The Network level viewpoint is concerned with the information representing the network, both physically and logically. It is concerned with how network element entities are related, topologically interconnected and con gured to provide and maintain end-to-end connectivity. For technology speci c requirements (e.g. ATM or SDH) it is possible to specialise and to pro le this library, [9], [8], [17].
The containment tree, Management Information Tree(MIT), stores managed objects instances actually in use in a speci c implementation. Name binding is the process of naming a managed object instance in the containment tree. Name Bindings require three pieces of information: the managed object instance the distinguishing attribute (the identi er for this managed object) with its value the superior of the managed object instance as located in the containment tree Using a simulator Tool, once a speci c MIB has been implemented, a \virtual" MIT can be speci ed, virtual because it is emulated. The MIT structure corresponds to the speci c Network Scenario. In fact for each Network Element(NE), namely nodes and links, an object instance is created in the MIT, summarising which are the information about that NE.
4.1 Testing Processes
As the previous section 4.0.1 explains, after MIB de nition it is possible to specify the MIT structure. Thus with objects instances corresponding to the Network Elements in the network scenario. To test if this rst process is correct two steps should be followed: The API creates managed objects in the agent's MIT. This allows to verify if the created objects are conformant to the given de nitions. The API sets and gets attribute values in the created managed objects. This phase veri es that only operations de ned following GDMO de nitions are well performed in the MIT. When testing the CMIP operations speci ed in the MIB, it is important to include both positive and negative test situations for each CMIP operation. This in order to check if operations work well when expected and that error conditions are generated otherwise. Furthermore, to test event generation and handling, you have to verify that an event generated in the agent (such as alarm) and sent as a noti cation to the API are handled appropriately.
5 Conclusions In the TMN framework, inter-operability between a Network Management Platform and a generic software application needs to be supported by the communication protocol CMIS/CMIP. Moreover, it is crucial to have a standardised model of information, which is referred for this interaction. As a matter of fact, a standard representation of managed information allows a good degree of portability for those software applications. Even if the communication behaviour required for inter-operability between management system has been speci ed, it is the application developer that has to de ne the nature of implementations that exhibit this behaviour. This corresponds to de ning a speci c Application Programming Interface. This paper describes the steps involved when de ning an API for a speci c kind of application: Network Resource Planning tools. Simulation is the instrument that seems actually the more realistic and the more suitable to test: The good implementation of the information model as a preliminary step. The correct functioning of API: the right managed objects being manipulated as expected.
Acknowledgements This work could not have been made without the generous help of Simon Znaty, for fundamental suggestions concerning in particular Network Management solutions. I wish also to thank Steven Willmott and Jean-Philippe Martin-Flatin for useful discussions. Thanks also to Prof. B. Faltings and Christian Frei for useful comments.
References [1] M. Calisti. \API Interface: just some basic questions". Internal report, 13 January 1998. [2] M. Calisti.\Network Management and Network Planning: how they should interact ". Internal Report, December 10 1997. [3] "CMIS++: CMISE and ACSE C++ Application Programming Interface ", Draft 8, Issue 1.0 January 1996. [4] ISO 10165-4, "Guidelines for the De nition of Managed Objects" [5] ISO 8824/ITU X.208, "Speci cation of an Abstract Syntax Notation One ". [6] I-ETSI 300 653 "Telecommunication Management Network(TMN); Generic managed object class library for the network level view", May 1996. [7] CMIP ITU-T X.710|ISO/IEC 9595, " Common Management Information Service Element ". [8] Recommendation G.774. "Synchronous Digital Hierarchy(SDH) Management Information Model for the Network Element view". November 1992. [9] ITU-T Recommendation I.751."Asynchronous Transfer Mode Management of the Network Element view", March 1996. [10] M. Wooldridge, N.R. Jennings."Agent Theories, Architectures and Languages: a survey". Intelligent Agents Proc. ECAI-94, Amsterdam, August 1994. [11] S. Franklin, A. Graesser. "Is it an agent, or just a program?: a taxonomy for autonomous agent". ECAI'96 Workshop(ATAL), Budapest, August 1996. [12] J.P. Martin-Flatin, S. Znaty, J.P. Hubaux, "A survey of Distributed Enterprise Network and System Management Paradigms", November 30 1997, submitted to JNSM. [13] FIPA 97 Speci cation, Prat 7. Network Management and Provisioning. October 1997, Geneva Switzerland. [14] J. Agnello, R. Raud, "Top Down not Bottom Up TMN Network Models", white paper, August 1997. [15] L. Deri, "Network Management for the 90s", IBM Research Division, Zurich Research Laboratory. [16] " Mini Structured Query Language ", http://www.Hughes.com .au, mSQL 2.0.1, July 1997. [17] The ATM Forum, Technical Committee, Network Management, "M4 Network View CMIP MIB", Speci cation version 1.0, af-nm-0073-000, January, 1997.
