a generic management system for heterogeneous networks

A Generic Management System for Heterogeneous Networks This paper summarizes the key requirements for the system, presents an object-oriented model of the heterogeneous networks, and gives a brief description of the main functional parts of the system. The model discussed in this paper consists of object classes representing protocol layers such as TCP/IP layers or the data link layer of the X.25 protocol.

By Bharat Bhushan and Ahmed Patel

Introduction

N etwork management is a very complex field and becomes increasingly so if one is to manage two or more different networks. There are some

proprietary network management systems but they support only a single manufacturer’s products. It is very difficult to use a management system for managing dissimilar networks because of the incompatible hardware and software configuration of network elements, differing proto-

Bharat Bhushan and Ahmed Patel are members of the Computer Net- works and Distributed Systems Research Group, Department of Com- puter Science, University College Dublin, Belfeld, Dublin 4, Ireland. Bharat Bhushan is a PhD student at present and his areas of research include network management, distributed systems and co-operative working. Dr Ahmed Patel’s main research interests include network management, security, protocol, performance evaluation, intelligent networks, CSCW and open distributed systems. He has published many technical papers and has co-authored two books on computer network security and one on group communications.

cols, and the different syntax of commands. There are many problems in accessing management information from a heterogeneous network. This situation requires a management system which integrates dissimilar network elements and allows the user to monitor and control them as if the network being managed were a homogeneous network.

everal vendors have begun addressing S what they perceive to be the most important need of network management- the integration of multiple, heterogeneous management systems.

Network management can be defined as the co- ordination, monitoring and control of the resources in a network. Various issues must be addressed when connecting different networks

158 SEPTEMBER 1994

with different topologies, protocols, and networking models. Interconnection of different protocols results in a heterogeneous network. The heterogeneity problem manifests itself when networks are connected to form an infrastructure for communication. The sources of heterogeneity include data representations, communication networks, protocols for interaction, and naming domains.’

-Related Architecture - Several vendors have begun addressing what

they perceive to be the most important need of network management-the integration of multiple, heterogeneous management systems. Promi- nent among these vendors are IBM, DEC and Hewlett-Packard.

IBM’s Netview-To support all the tasks of its System Network Architecture, IBM has developed a number of software and hardware tools that work with and in a SNA network. All these are consolidated into a single product line with the introduction of Netview.’

NetView is a host-based network management and control system running on an IBM/370 mainframe. It is a centralized management system feat- uring an open architecture. NetView is intended to operate across multiple networks, where networks may not all be SNA based, but may include token ring LANs, X.25 packet-switching networks, and even non-IBM wide area networks. To that end, some interfaces and operating details of NetView have been published to permit other suppliers to build NetView handles and extensions into their products, so that those non-IBM products can be part of Netview‘s network management con- tinuum. This concept is referred to as Open Net- work Management.

NetView, a group of software programs, monitors and reports on various aspects of network operation and supports IBM mainframe and PC network environments as well as non-IBM devices. It has been designed for continuous and automated operation and is a centralized management system with distributed operations.

DEC‘s Enterprise Management Architec- ture (EMA)-The EMA is DEC’s master plan for

distributed network management. The main features of EMA are:3

0 A consistent User Interface 0 A common management information struc-

0 OSI compatibility 0 A way to manage non-Digital resources.

The Digital enterprise management scheme draws heavily on the OSI management frame- work. Digital defines two basic elements in the EMA model: the managed entity and the managing director. Directors have domains that may include entities, other directors, other domains, or any combination thereof. Entities can be assigned to the domain of more than one director. However, each entity also has a distinct name that is compat- ible with Digital’s Distributed Names Services under DECnet. An entity is object-oriented information that passes within and between domains. Similarly, entities are grouped into object classes. Members or instances of object classes can be categorized by the following:

0 Attributes-a common characteristic or vari-

0 Events-alarms or notifications an object can

0 Operations-functions an object can perform

The objects can be a physical device, such as modem, or a logical construct, such as a database. The agent is always a piece of software, a logical construct. It controls information flow between the object and a director. A director has four parts: modules, the interface, the executive, and the Man- agement Information Repository (MIR).

The outermost layer of the director comprises modules that perform the actual communication between agents and the director. The director primarily uses an implementation of CMIP to allow communication between EMA software and third-party systems.

ture

able such as communication device

generate

HP OpenView-One of the most useful approaches to managing heterogeneous networks is provided by Hewlett-Packard’s OpenView4 which fits in the Distributed Management Environment (DME) and uses both SNMP and CMIP. Hewlett-Packard has developed two models as a part of its OpenView Network Manage- ment architecture. These models have been found

INTERNATIONAL IOURNAL OF NETWORK MANAGEMENT. 159

to be extremely useful tools for Network Manage- ment (NM) solution developers in the way they can capture a high-level view as well as a specific view of the NM environment.

The two models are the Organizational Model and the Operational Model. The Organizational Model is intended to assist designers in identifying management functions and their relationships to one another. In contrast, the Operational Model reveals sufficient design detail to support data flow and co-existence analysis. Both the models support multiple levels of integration, which allow many more systems to be integrated under a common network management architecture with varying degrees of effort. The Organizational Model is made up of three major components: the User Interface, the Management Application, and the Manage- ment Services. The Management Services are primarily provided by two subcomponents: the Object and the Datastore. The Organizational Model uses these components to model the functional and relational components of the NM solution. The OpenView Operational Model is a design-level model useful for illustrating how the components of the Organizational Model are deployed and how multiple NM solutions can co-exist. It also provides a means of dataflow and management super- vision analysis.

The Common Concepts of the Above Three

(1) They give the user a single view of management capabilities-as if these capabilities were provided by one system, even though they are provided by heterogeneous network elements and management systems.

(2) They concentrate on integrating the monitoring/configuration/event reporting of the managed objects/events across the individual management subsystems.

(3) They support network management services defined by the IS0 network management standards.

(4) They rely on translation and mapping to interface the local management communication protocol and structure with those related to their own network management implementation.

(5) They use a modularized, building-block approach to design the system.

Approaches-These are as follows:

-The Generic Network Management System (GNMS) -

Looking at the current trends in network management and applications using OSI and non-OSI network management protocols, it is seen that SNMP is the most widely used network management protocol whereas CMIS/P is seen as the protocol of future network management systems. Similarly, X.25 and TCP/IP are the two most widely used networking protocols. Although CMIS/P is complex and fairly difficult to implement, software manufacturers have started implementing it. SNMP, on the other hand, is easy to implement. The CMIS/P gives a set of powerful network management operations but SNMP has been in use for years and has become the industry standard. A generic and feasible solution to the problem of heterogeneity seems to be software which integrates both CMIS/P and SNMP. The GNMS presented in this paper integrates both CMIS/P and SNMP and has the following features:

0 An object-oriented model of heterogeneous networks

0 A set of network management operations for the model

0 Masking the heterogeneity by combining the syntax and semantics of the commands of heterogeneous network components

0 A comprehensive user interface to the heterogeneous network elements.

Problem Definition and Requirements Analysis

Problems due to heterogeneity arise in several specific areas:

e OSI network management model ?”” provides a powerful object-oriented model that has a comprehensive set of management operations.

0 Interconnection: How should heterogeneous systems communicate with each other? How

can systems and languages with different data representations be accommodated? Naming: How are the names given to network elements? What objects can be named across systems? How does the environment evolve as new systems and naming approaches are incorporated? User interface: What kind of user interface should be provided? How should the user interface represent the heterogeneous networks? How is a graphical view of the managed network ~ r e a t e d ? ~ , ~

- Requirements for the GNMS -

approach. The managed resources are accessed through object ab~traction.~ In the OSI model, the CMIS is used by an application process to exchange management information and commands for the purpose of system management. CMIS is a set of service primitives that constitute an Application Service Element (ASE), as well as the attributes passed in each pr imit i~e.~,~

The Internet network management model can be considered as a simpler version of the OSI model. The SNMP'O is a request-response protocol having five main operations: Get-Request, Get-Next- Request, Get-Response, Set-Request, and Trap. These commands or verbs are known as Protocol Data Units (PDU). The SNMP model is not a fully object-oriented model. In this model the objects are simple pieces of information that may be-read or written. The object-orientation provided in this model is through OBJECT-TYPE Abstract syntax Notation ae (ASN.~).

A fundamental question facing network users is how to integrate the functionalities of SNMP and CMIP. This is the basic requirement. Other key requirements include:

(1) A tool with a single interface to network resources and powerful but user-friendly commands for performing most of the network management tasks.

(2) A tool to manage heterogeneous communication protocol stacks.

(3) A management system which not only monitors network resources and collects statistics but also makes use of statistics for network management applications.

(4) A tool to provide the user with a set of basic management functions such as those defined by the IS0 Network Management Stan- dards.

(5 ) A management system which can easily be customized as the networks increase in size.

The OSI and Internet Approaches

The OSI network management model provides a powerful object-oriented model that has a com-

-A Comparison of CMIP and SNMP-

The two models are similar to some extent but also have many differences which mainly relate to their design aims. One of the main differences is that the CMIS/P uses an event-driven approach as opposed to the SNMP which follows a trap- directed pollinglo approach. Some other important differences are:

0 SNMP on UDP has poor security capability. CMIP, together with ACSE, provides a powerful security capability.

0 CMIP can specify multiple operations within a single request. SNMP can work on only one object at a time.

0 SNMP and CMIP both have three primitive operations: GET, SET, and EVENT (or TRAP). CMIP has three further primitives: CREATE, DELETE, and ACTION, which provide it with a powerful capability to create and delete managed objects.

0 CMIP uses the concept of inheritance whilst SNMP does not.

prehensive set of management operations. On the other hand, a different approach is followed by the Internet community in which a simpler solution

The Information Model of Heterogeneous Networks

has been adopted. The OSI model provides a powerful and general management infrastructure In order to make the GNMS independent of by adopting a fully fledged object-oriented specific network management protocols and com-

INTERNATIONAL IOURNAL OF NETWORK MANAGEMENT 161

munication protocols, resources of the heterogeneous network elements are described in terms of an abstract object-oriented model which is based on a classical Entity-Relationship information model."J2 The model includes entities and their interrelationships.

To model heterogeneous networks, each real resource is treated as an object. Objects with similar characteristics and behaviour are grouped into object classes. Among various object classes there are some object classes which possess a common behaviour. All such object classes are grouped into a domain. The model is a collection of heterogeneous domains. In the model, the root acts as the superclass of all the domains. In this hierarchy, a domain acts as superclass of all the object classes but the domain itself is a subclass of the root (see Figure 1). Figure 1 also shows the relationships among the superclass mot and its subclasses. Thus, root 'has' X25 domain which in turn 'has' X25HDLC, X25_Link, X25_Node, and X25Xet- work object classes. The behaviour of object classes

is defined by attributes they possess. Attributes include operating characteristics and service statistics of each resource.

A domain can be considered as the unit of heterogeneity. Within a particular domain all management information is homogeneous. The model defined for the GNMS consists of two domains- X25 and Internet-and it can be extended. These domains correspond to the X.25 and TCP/IP networks, respectively.

-Object Classes and lnstances-

This section contains the definition of the object classes defined in the model. The X25 domain consists of four object classes. Similarly, there are four object classes in the Internet domain (see Figure 1).

0 Class X 2 5 3 D L C : The object class X25HDLC represents the HDLC link level between two X.25 nodes inside the X.25 network and contains an instance named X25HDLC001.

root

Transport Domains /ff Layer

X25-HDLC @ 4 7 f \ * ' X25Link X25-Node X25-Network ip udp tcp system Object Classes

A

7%? A1 ...An A1 ...An A I . . . A ~ A1 ...An A1 ... An A1 ...An A1 ...An

A A ! A1 ...An

A A A A Instances : I I I

I I I I

I I I

X25-HDLCd01 X25-LinkbOl X25~NocieOO1 X25_N&wor~1 ip udp tip hostname

Inheritence Relationship ----* "IS Instance of' A1 ...An Attributes

Figure 7. Model of the network.

162 SEPTEMBER 1994

0 Class X25Xetwork: The object class X25Xet- work represents the X.25 wide area network and contains an instance named X25Xet- workOOl.

0 Class X25-Link: The object class X25-Link represents the packet level of a link between an X.25 node and a DTE on the X.25 network and contains an instance named X25-Link001.

0 Class X25Bode: The object class X25Xode represents the nodes inside the X.25 network and contains an instance named X25Xode001.

0 Class system: The object class system provides general information about managed system running TCP/IP.

0 Class ip: The object class ip represents the internet layer of TCP/IP and contains information relevant to the implementation and the operation of IP at the node. It contains only one instance, i.e. ip itself.

0 Class tcp: The object class tcp represents TCP and contains information relevant to the implementation and the operation of TCP at the node. It contains only one instance, i.e. tcp itself.

0 Class udp: Object class udp represents UDP and contains information relevant to the implementation and the operation of UDP at the node. It contains only one instance, i.e. udp itself.

-Attributes of X25 Domain Classes-

The attributes chosen are either configurable system parameters or system statistics as described in the CCITT recommendation for X.25 ne t~0rks . l~ Configuration of a system parameter results in changes in the behaviour of a physical component. Similarly, the statistics from a physical component can be used in monitoring the performance, calculating accounting information, etc. Table 1 lists the attribute names and their types.

Relative Distinguished Attributes--The Relative Distinguished attributes identify an instance of the class. There are four Relative Dis- tinguished attributes which identify the instances of four object classes. Attributes X25_NetworkId, X25_LinkId, X25XodeId, and X25HDLCId

identify an instance of the classes X25Xetwork, X25_Link, X25Xode, and X25_HDLC, respectively.

Other Attributes of the X25 Domain- 0 The attribute tlTimer is an integer reflecting

the current value of the TlTimer for X25Jet- work at the time when the attribute was accessed.

0 The attribute fiamesrecv is a gauge reflecting the accumulated number of Information Frames received on all the links of X25Aet- work.

0 The attribute numberCRCerrors is a gauge reflecting the accumulated number of Cyclic Redundancy Check errors occurred on X25LLink.

0 The attribute retransmission is a gauge reflecting the accumulated number of retransmissions which occurred on X25Xode.

0 Attributes framesThld, CRCerrorsThld, and RtrThld are the thresholds associated with framesrecv, numberCRCerrors, and retransmission, respectively.

Event reports- 0 The event report framesThldExceeded is trig-

gered by attribute framesThld. Similarly, frame- sTideMarkChanged is triggered by attributefra- mesTideMark.

0 The event reports CRCerrorsThldExceeded and RtrThldExceeded are triggered by the threshold attributes associated with them.

-Attributes of the Internet Domain Classes -

The attributes chosen for the object classes in the Internet domain are as defined in the MIB described in RFC 1214.14 The RFC 1214 is a translation of the SNMP MIB described in RFC 1213. The translation is from the SNMP Structure of Management Information / Management Infor- mation Model (SMI/MIM) to that of the OSI GDMO/MIM, the rules for which are described in RFC 1214. To realize the concept of a domain in practice, attributes of only four object classes of the SNMP MIB have been chosen. Table 2 lists the attributes and types.


Class name Attribute name Access Syntax

X25Xetwork x25JJetworkId xs sTime

framesrecv framesTideMark framesThld framesThldExceeded fr amesTideMar kchanged

xs ysTime numberCRCerrors CRCerrorsThld CRCerrorsThldExceeded

xsysTime retransmissions RtrThld RtrThldExceeded

linespeed

t l +T imer

X25-Link x25-LinkId

X25Xode x25XodeId

X25HDLC x25HDLCId

RW RO RW RO RO RO

RW RO RO

RW RO RO

RW RO

IA5String UTCTime Integer ObservedValue Tidemark Gau e Threshold x255etwork~eport x25JJetworkReport IA5String UTCTime ObservedValue Gau eThreshold x25- 8. inkReport IA5String UTCTime ObservedValue Gau eThreshold x25aodeReport IA5String IA5String

I

Table 1. Attribute of the X25 Domain Object classes

Class Name Attribute name Access Syntax

system systemId sysContact ipId ipForwarding ipDefaultTTL ipmeceives ipInAddrErrors ipInHdrErrors

iP

tCP tcpId tcpActive%j;iS

tcpPassive tcpAttempt ails udpId udpInDatagrams udpInErrors udpOutDatagrams

UdP

RO RW RO RO RO RO RO RO RO RO RO RO RO RO RO RO RO

PrintString PrintString PrintString Integer Integer Counter Counter Counter

PrintString Counter Counter Counter PrintString Counter Counter Counter

Table 2. Attributes of the Internet Domain Object Classes

8 $ r % B

164 SEPTEMBER 1994

Relative Distinguished At t ribu tes-As stated above, the Relative Distinguished attributes identify an instance of the class. Attributes sys- temId, ipId, tcpId, and udpId identify an instance of the class system, ip, tcp, and udp, respectively.

Other Attributes of the lnternet Domain- a

a

0

a

a

a

a

a

a

a

a

The attribute syscontact is the identification and contact information of the contact person for the managed node. The attribute ipForwurding shows whether the managed node is acting as an IP gateway (if value is l), or not acting as an IP gateway (if value is 2). The attribute ipDefaultTTL shows the default inserted in the Time-To-Live field of IP header of the datagram. The attribute ipInXeceives shows the total number of input datagram received from the interface, including those received in error. The attribute ipInAddrErrors shows the total number of datagrams discarded because the IP address in the destination field was not valid. The attribute ipInHdrErrors shows the total number of datagrams discarded due to errors in the IP header. The attributes tcpActiueOpens and tcpPussiue0- pens show the number of active opens and puss- iue opens have been supported by the TCP layer. The attribute tcpAttemptFaiZs shows the number of failed connection attempts that have occurred at the TCP layer. The attribute udpInDatagrums shows the total number of UDP datagrams delivered to the UDP users. The attribute udpInErrors show the number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port. The attribute udpOutDatagrams total the number of UDP datagrams sent.

The Main Functional Components of GNMS

The design of the GNMS is modular. The modularized, building-block approach facilitates easy

he GNMS can be seen as a set of

together in such a way that the combined functions of the programs support the main functions of the system as a whole.

T programs (functional modules) which fit

accommodation of unforeseen variations in the networks being managed. Thus, the GNMS can be seen as a set of programs (functional modules) which fit together in such a way that the combined functions of the programs support the main functions of the system as a whole. The main functions of the architecture are to execute management operations on network elements and the important features of the design are as follows:

An object-oriented model of heterogeneous networks Naming of the network elements and management information based on IS0 Manage- ment Information Model Transparent access to heterogeneous network elements Ability to modify the model A set of generic network management operations which support CMIS/P. A consistent user interface to the heterogeneous network elements.

This section describes the main functionalities of the components of the GNMS and how these functionalities are distributed between components. Figure 2 shows the main functional components.

-The Graphical User Interface (GUI)-

To ease the user interaction with the GNMS, an interactive user interface has been designed. This module is an interactive window-based interface to the system and serves two main purposes:

a Provision of a human-machine interface to allow the user to access the facilities provided by the GNMS

0 Integration of the various user interfaces to the devices being managed by CMIS/P and SNMP.


Knowledge of I domains. obiect Kernel Module I

X.25 and Internet System

Management Agents

I classes, hs&ces,l I

Common Management Information Protocol

* I Amlidon-&Network 1

Network Resources --e Figure 2. Main functional components of the system architecture.

The user interface provides a single view of the heterogeneous network elements. It also performs logical chaining of the functionality. For example, before accessing the network resources, the user is prompted to run the System Management Agents. Users of the GNMS can have different responsibilities such as network administrator or network operator. Each of these users will require a different view of the network (i.e. will want to see some and ignore other information). The user interface provides a focused interface to the management application function for different users.

The user interface is an object-oriented graphical interface in the sense that it encapsulates standard windowing behaviour in predefined objects. Elements of the GUI can be viewed as objects made up of both data and functionality. There are two main logical entities in the GUI-the user of the GNMS who executes management operations

on network elements, and the network elements which are subject to the network management operations.

The graphical user interface has been developed using X Window application programing toolkits. In principle, X Window application programing is object-oriented. It is based on the concept of a class in which a graphical object acts as superclass and contains child graphical objects.

The User of GNMS-On the basis of their responsibilities, users of GNMS can be categorized into two types: the Administrator of the network and the Operator of the network. As an Adminis- trator a user can:

0 Manage and browse through the model of the network

0 Invoke the System Management Agents 0 Receive Event Reports.

166 SEPTEMBER 1994

As an Operator a user can:

0 Obtain the value of a system parameter 0 Modify a system parameter of a network

element.

Graphical Representation of the Network Elements-There are eight graphic objects in the GUI which represent eight network elements of heterogeneous networks (see Table 3). Since objects contain both the data and the functionality, they more closely resemble the real-world entities being dealt with.

-The Kernel Module-

The Kernel module acts as the mediator between two communicating modules. The Kernel performs the following operations:

0 Binding all the modules together with the

0 Maintaining a logical relationship among

0 Managing and browsing the model 0 Execution of network management oper-

The Kernel also controls the execution of the operations in the GNMS (as an operating system does). These operations involve requests for services and the return of a response. A module requesting a service passes certain arguments to a

help of interfaces

mod u 1 e s

ations.

function and waits for the result. In fact, the arguments passed are given to the Kernel which contains the definition of the functions that control the operation in the GNMS. On receiving the arguments, the Kernel module invokes the appropriate function and returns the result to the calling module. With the help of these functions various modules communicate with each other and share services. There are two main types of function in the Kernel-network management functions and model management functions. These functions are defined below. As stated earlier, the Kernel main- tains a logical relationship among modules. For example, if an attribute is to be added, the Kernel prompts the user to add the necessary knowledge. Similarly, before accepting any request from the user, the Kernel module checks whether the Sys- tem Management Agents are running or not.

Knowledge of the Heterogeneous Net- works-The Kernel module as well as other modules in the GNMS need to share a common view of the object being managed. The domains, object classes, instances, attributes, etc. are collectively referred to as the knowledge about the heterogeneous network. The Kernel module is given knowledge of the heterogeneous networks as well as knowledge of what management operations can be carried out on network elements. The knowledge consists of text files containing definitioh of model, domain, object classes, instances, attributes and their types. The object classes are specified by a formal specification language, Guidelines for

Name of Graphic Object Representation

X251Vetwork X251Vode X25XDLC

X25-Link

X.25 network X.25 node connected to the X.25 network HDLC frame level between two X.25 nodes The packet level of a link between an X.25 node and a DTE on the X.25 network TCP layer of a TCP/IP network IP layer of the TCP/IP network UDP layer of the TCP/IP network The node running the TCP/IP protocol

Table 3. The Graphic Objects and network elements they represent

INTERNATIONAL [OURNAL OF NETWORK MANAGEMENT 167

X25-HDLC MANAGED OBJECT CLASS DERIVED FROM X25;

I

ATTRIBUTES linespeed GET;

REGISTERED AS ( .... ) 1 ... ... ...

ip MANAGED OBJECT CLASS DERIVED FROM Internet;

ATTRIBUTES

I

ipInFteceives GET; ipFurwarding GET; . . . . . . . . . . .,

. . . . . . . . . . . . .. REGISTEREDAS { mib4 )

figure 3. The m0del.M.

Definition of the Managed Objects (GDM0).15 Two tables, called attribute and domain, contain a list of all the attributes and domains defined in the model. When handling a request, the Kernel vali- dates the request, finds the class of the referred instance and invokes the operations to obtain or modify the value of the selected attribute. Figures 3 and 4 show the model.txt and instance.txt files.

The following files contain the complete definition of the model:

0 model.txt contains the definition of the model of the heterogeneous networks.

0 instance.txt contains the definition of instances of the object classes in the model.

0 application-attribute contains the definition and description of the application level attributes.

0 networkinternetAttribute contains the definition and description of the Network level attributes in the Internet domain.

0 networkX25~ttribute contains the definition and description of the syntactic level attributes in the X25 domain.

0 attribute contains the definition of all the attributes of the object classes in the model.

0 domain contains the definition of all the domains defined in the model.

Network Management Functions-Network management functions perform management operations on the managed objects and enable access to management information. The following two functions carry out two of the most essential network management operations:

0 Get(className, instance, attribute) 0 Set(className, instance, attribute, value)

The above two operations have as common parameters the class name, instance name, and the attribute name. A particular managed object, its instance and attribute are referred to by these parameters. With these two functions the Kernel obtains or modifies the value of an attribute. The Kernel passes three arguments to the Application- to-Network Translator (see below), i.e. the name of the class, the name of the instance, and the name of the application level attribute. On receiving these arguments the Application-to-Network Translator finds the exact mapping between application Zevel attribute and network level attribute and passes the request to the network level.

Another main operation which is related to managed objects is Report(className, EventType).

systemId=dallas@ x25-HDLCId=x25-HDLCOO 1 I INSTANCE CLASS: x25-HDLC DOMAIN: X25 SUPERIOR root 1 ( INSTANCJ? CLASS: ip DOMAIN: internet SUPERIOR root 1

systemId=dallas@ipId=" "

figure 4. The instance,M.

168 SEPTEMBER 1994

When an event is triggered, an event report is gen- erated and dispatched. To receive an event report, the Kernel initiates function Event-Report(className, EventType) which carries out this operation and starts receiving event reports from the System Manager. Parameter EventType specifies the type of the event for which reports have to be received (see above).

he functions for managing the model T play a very important role in the - ,

overall functioning of the Kernel, and with these functions an administrator can browse and modify the model.

The other two important operations are starting up the System Management Agent and terminating it. The functions lnitiateAgent(agentName) and TerminatedAgent(agentName) are used to invoke and terminate the System Management Agent.

Model Management Functions-The functions for managing the model play a very important role in the overall functioning of the Kernel, and with these an administrator can browse and modify the model. Modification to the model results in modification to the real network resources. A brief definition of some of the important functions is given here.

The functions Search-Class(className), Search- lnstance(c1assName) and Searck_Attribute(attribute) carry out the necessary search operations such as searching for a class, instance, or an attribute in the model. In return, these operations display obvious messages such as ’Found’ or ’Not Found’. When a new domain, object class, instance or attribute is added to or removed from the model, the knowledge needs to be updated. The functions Add-DomainO, Add-ClassO, AddJnstanceO, and AddAttributeO add a domain, class, instance, and an attribute to the model and update the knowledge.

Similarly, the functions Remove-Domain(), Remove-ClassO, RemoveJnstanceO, and Remove- Attribute0 remove a domain, class, instance, and an attribute from the model and update the knowledge.

- Application-to-Network Translator-

The Application-to-Network Translator integrates heterogeneous network resources. The integration is a two level process: the network level unifies all the syntax of the network management operation and the application level unifies the semantics of network management operations of heterogeneous network elements. The Application-to- Network Translator gives a single semantic and syntax to the user (the user can be a human user, module or network management application). The application level breaks up a user’s request into smaller pieces of information and the network level breaks them up further into real network elements’ management operations. The functionality of the application and network levels can be understood by the example given below (see Figure 5).

If a management application’s objective is to compare the total number of calls connected on two different nodes during a certain time, it would need to calculate the total number of calls connected on two nodes (for example, an X.25 gateway and an IP router) in a given time. This management information is calculated from two attributes: the total number of calls connected on the X.25 Gateway and the total number of calls connected on the IP router.

In this case, there are two application level attributes: ‘Total Number of calls connected on X.25 Gateway during certain time’; and ‘Total Number of calls connected on IP router during certain time’. To calculate ’Total Number of calls connected on X.25 Gateway during certain time’, it would require ’Total Number of Calls connected’ and ’Node last reset’, Similarly, to calculate ’Total Number of calls connected on IP router during certain time’ it would require ’Total Number of Calls connected’ and ’IP router last reset’.

The management application would access the network by the Application-to-Network translator. It would pass its statistical parameter requirement, which is the total number of calls connected on the X.25 Gateway and the IP router, to the application level. The application level consults the appli- cation_attributes (see above), finds the exact mapping between the application and the network level attributes and passes the request(s) to the network level.


Application Level “Total Number of Calls

Connected on X.25 Gateway”

Network Level

“Total Number of Calls Connected on IP Router”

I

Figure 5. The application and network levels.

“Node Last Reset” “Total Number of calls Connected”

-The Mapping Between Application and Network level Attributes-

“Total Number of calls connected” “Router Last Reset’

A mapping from an Application level attribute into a Network level attribute is a ‘rule’ that associ- ates each attribute at Application level with a unique attribute at Network level. The mapping used in the Application-to-Network Translator can be of two types: a One-to-one mapping or a One-to-Many mapping. Figure 6 shows an example of the map- pings.

In a One-to-one mapping an Application level attribute (System Name) depends on only one Nef- work level attribute whereas in a One-to-Many mapping an Application level attribute (Throughput) depends on more than one Network level attribute.

- OSI System Manager - The OSI System Manager is a set of three pro-

grams which connect to a System Management

Agent and retrieve the management information. The System Manager accepts the get, set, and event report requests and sends them to the System Man- agement Agent and waits for the reply. When the Manager receives the Get, Set, or EventXeport requests, it checks the classNume argument. The value of classhrame argument is used to determine which Agent the request should be sent to. The System Manager is made up of three main programs: cmis-get, cmisset, and cmis-evrep.

cmis-get and cmisset-The cmis-get program receives the arguments passed by request Get, connects to the System Management Agent, and retrieves the management information. In order to retrieve the value of an attribute, the cmis-get program first establishes a management association with the System Management Agent, requests the managed objects (using an M-GET CMIS request) as given by the network management function Get, and sends the result or error to the Get. The cmisset program receives the arguments passed by network management function

170 SEPTEMBER 1994

Set, connects to the System Management Agent, and modifies the management information (managed object attribute). In order to modify the value of an attribute, the cmisset program first establishes a management association with the System Management Agent, requests the set operation to be performed (using a M-SETConf CMIS request) as given by the function Set, and sends the result or error to the function Set.

cmisXvrep-The cmis-evrep program connects to the OSI System Management Agent, passes the type of the event for which report has to be received, and receives event reports. The cmis-evrep program first establishes a management association with the system management agent, requests the 'evenType' as specified through 'Event Report' (using a M-EVENTRep- Conf CMIS request), and sends the event report to the network management function EventReport.

- 0 S I System Management Agent-

OSI System Manager accesses the network elements through the OSI System Management Agent. Access to a network element involves col- lecting its statistical information and exercising control over it. Agents perform management operations as a result of management operations com- municated from the Manager. In the GNMS, there are two OSI System Management Agents with which the Manager interacts. These agents act as the lowest-level functional components of the GNMS and provide access to the TCP/IP network and the X.25 network through X.25 and Internet MIBs.

The OSI System Management Agent handles wild-card naming, scoping, filtering, and access control. The OSI System Manager sends two types of requests to the Agent: association establishment/release requests or CMIS operation requests. While handling association establishment/release requests it performs the access control function. The Agent handles the CMIS operation requests by interacting with the selected managed objects to get and set management information.

Interfaces Between Modules

In order to support communication between the modules the Kernel uses interfaces. An interface acts as a link when communication between two modules takes place. In simple terms, interfaces are the names and syntax of the arguments passed (requests) to a function and the value returned by the function (response). Modules communicate with each other with these arguments and the return value. The important interfaces through which the modules communicate are shown in Figure 7

0 UI-Kernel interface: This interface allows the GUI to communicate with the model and real resources.

0 Kernel-network interface: This interface is a set of network management functions which use UNIX interprocess communication facilities.

0 CMIS interface: This interface is specified in CMIS syntax and is used to access the managed objects. All the scoping, filtering, and synchronization is done at this interface.

User Interface r - . e I

I A UI-Kernelhterface

* I

Application-to-Network Translator

CMIS Interface

Managed Objects

Figure 7. Main interfaces between modules.


-Information Access Points-

Information Access Points are the sources from which the Agents obtain the management information. In general, network elements store their statistics and machine-dependent parameters in tables, files, etc. Files, tables, and databases associated with a network element are considered as information access points. These tables also control the behaviour of the associated components.

In the case of the Internet domain the information access points are within the UNIX kernel. This means that the real resources information is retrieved by accessing the UNIX kernel. Similarly, the real resources information of the X25 domain is retrieved by accessing an X.25 switch.

Summary and Conclusions In this paper we have presented the results of

the design and a prototype implementation of a Generic Network Management System for managing heterogeneous networks. The method used for the design provides a workable solution to the problem of managing heterogeneous networks. One of the main features of the system is an object- oriented model of heterogeneous networks. The model consists of managed object classes which are an abstract representation of the network elements. The user interacts with the model and any changes in the model reflect changes in the real resources. We have also shown how a complex application level information can be trans- lated into a very simple form and how heterogeneous network elements can be integrated. The Application-to-Network translator facilitates these two important purposes. It integrates the heterogeneous networks and breaks up complex information into commands which can be executed on real resources. The integration is a two level process: the application lmel which combines various semantics of commands and the network level which combines various syntaxes of commands.

The prototype has been tested on X.25 and TCP/IP networks. By choosing two of the most widely used communication protocols as well as CMIS/P and SNMP, GNMS can manage a wide range of network resources. The graphical user interface hides the complicated functionality of GNMS (which is the result of CMIS/P-SNMP

y choosing two of the most widely used B communication protocols as well as CMISIP and SNMP, GNMS can manage a wide range of network resources.

integration) and makes it easy to interact with the system. CMIS/P has been used to manage the model, thus the software can cope with the techno- logical changes which may occur in future. It can easily be enhanced as the networks being managed increase in size. The same holds true for the graphical user interface.

Acknowledgements

We wish to thank Ms Olga Have1 of the Department of Computer Science, University College Dublin, for her valuable contribution to the project. We are grateful to Mr %amus 0 Ciardhuhin of the Department of Com- puter Science, University College Dublin, for reviewing the paper. We, on behalf of UCD and Euristix, also wish to thank the Irish Science & Technology Agency (EOLAS) for funding this project under the Higher Edu- cation & Industry Co-operation (HEIC) program (project number 91/33).

References 1. H. Derok, Information transfer within advanced

logical architecture, Plessey Research and Tech- nology, Roke Manor, Romsey, Hampshire, Research Internal Document, June 1991.

2. IBM SNA and NetView, Section-Integrated Net- work Management, Report NM40-491-101, Datapro Network Management, 2, No. 5, October 1990.

3. C. H. Baum, Digital Equipment Corporation’s enterprise management architecture’, Datapro Inter- national-Network Management Information Service, Issue 1-Standards, Protocols, and Architectures, Janu- ary 1992.

4. C. H. Baum, Hewlett-Packard Open View, Datapro International-Network Management Information Ser- vice, Issue 1-Standards, Protocols, and Architectures, January 1992.

5. J. L. Crawford, Graphics for network management: an interactive approach, Proceedings of lFlP Confer- ence on In fegrated Network Management, 1989.

6. R. S. Gilbert and W. B. Kleinoder, CNMgraf- graphic presentation services for network management, Proceedings of Ninth Data Communication Sym- posium, pp. 199-206, IEEE, 1985.

7. G. Pavlou, et al., Automating the OSI to Internet

**a

172 SEPTEMBER 1994

Management Conversion through the use of an object-oriented platform, Proceedings of IFIP Confer- ence WG 6.4 Advanced Information Processing Tech- niques for LAN and MAN Management, MAS1 Labora- tory, Versailles, France, April 1993.

8. IS0 DIS 9595-2, Information Processing Systems- Open System Interconnection-Management Infor- mation Service Definition-Part 2 Common Man- agement Information Service, ISO, Geneva, December 1988.

9. IS0 DIS 9596-2, Information Processing Systems- Open Systems Interconnection-Management Infor- mation Service Definition-Part 2: Common Man- agement Information Protocol, ISO, Geneva, Dec. 1988.

10. M. T. Rose, The Simple Book-An Introduction to Man- -agement of TCP/IP based Internet, Prentice-Hall, Englewood Cliffs, NJ, 1991.

11. P.P.S.-Chen, The entity-relationship model- Towards a unified view of data, ACM Transaction Database System, 1, No 1, 9-36, March 1976.

12. Tl.MlTl.M1.5/89410R3, Proposed Draft Stan- dard-Generic Network Model for Interfaces

Between Operations Systems and Network Elements, December 4, 1989.

13. CCITI Recommendation X.25, Interface between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminal Operating in the Packet Mode, 1984.

14. L. Labarre, OSI Internet management: management information base, Request for Comments 1214, The MITRE Corporation, April 1991.

15. IS0 DIS 10165-4, Information Technology-Open System Interconnection-Management Information Service-Part 4: Guidelines for the Definition of

rn Managed Objects, ISO, Geneva, June 1990.

If you wish to order reprints for this or any other articles in the International Journal of Network Management, please see the Special Reprint instructions inside the front cover.

CCC 1055-7148 /94 / 0301 58-1 6 0 1994 by John Wiley & Sons, Ltd

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT 173

a generic management system for heterogeneous networks

Documents