Using a DBMS for Hierarchical Network Management - CiteSeerX

Using a DBMS for Hierarchical Network Management F.Stamatelopoulos1, N.Roussopoulos2 and B.Maglaris1 1

Network Management & Optimal Design Laboratory (NETMODE) Computer Science Division Electrical & Computer Engineering Department National Technical University of Athens (NTUA) Hroon Polytechnioy 9 - Zografou 15780 Athens - Greece Tel: +301.74.84.922 - Fax: +301.77.90.186 E-Mail: {fotis, maglaris}@theseas.ntua.gr 2

Computer Science Department University of Maryland at College Park E-Mail: [email protected] Abstract - We propose a manager architecture for hierarchical management based on a DBMS core module, aiming to minimize the management traffic overhead and the system response time. All management information and services, including manager-to-manager communication and inter-operation, are mapped on objects stored in the DBMS. We define key management services covering manager-tomanager communication and most of the OSI System Management Functions (SMFs), and present their mapping on database objects. Depending on access patterns, three update methods for the database objects are supported: periodical (polling), on demand (lazy) and on demand with a temporal tolerance. In our research we consider two data models (relational, object-oriented) and standard protocols (SNMP, SNMPv2, CMIP).

I. INTRODUCTION Network management is data-based[25]. Vast amounts of information (especially in large, complex networks) are collected by the network agents and sent to the manager sites. The manager collects network performance and configuration information, maintains historical and statistical data, handles events and reports. All this information, which explodes in size with network complexity and size augmentation, need not only be stored efficiently but it must also be enriched with powerful data management features that allow the realization of demanding, high level management functions like temporal reasoning, decision-making, planning[12], etc. Additional functionality is required in large, multiple domain networking environments since different classes of managed data consumers are organized in a hierarchy. In a first-level processing, management functions (applications) manipulate network data in full detail. Other functions, in higher levels, may require only a summary, a historical collection or a statistical analysis of these data (possibly collected from more than one domains), or a mixture of remote summarized and local detailed data.

A database management system is a commonly accepted solution for this purpose and it is central to the development of an efficient network management system for large networks ([4], [23], [6], [1]). Examples of network management architectures/products using storage systems as core modules are the DEC Enterprise Management Architecture (EMA)[7] and the OSF Distributed Management Environment (DME)[5]. A central component of the Director, the core module of EMA, is the Management Information Repository (MIR) that stores information for all the managed objects. The DME layered approach also relies on a similar module: the Management Information Storage. Although network and telecommunications management have been an important research topic for the past years, relatively little work has been done on the associated data storage and data management aspects. Wasson et al.[21] evaluate the suitability of conventional relational DBMSs for implementing management information bases, and propose some modifications to these systems. The Columbia University NETMATE project has investigated the model of the network and its architectural relationship with management systems[6]. Yemini et al.[25] present a semantic model of managed information by extending the entity-relationship model and Wolfson et al.[22] propose a modeling of network management functions as datamanipulation operations in a DBMS. Haritsa et al.[8]. introduce the MANDATE design, a database system for effectively supporting the management of large enterprise networks. Finally, a distributed information repository architecture for integrated network management is presented by Hong et al.[10]. In this paper we present a manager/platform architecture built around a data storage & management module maintaining the manager repository. Manager entities of this type may be organized in hierarchical structures for managing large, multiple domain networks. The management services offered by the manager/platform

higher performance requirements are satisfied by creating more domains and adding a respective number of managers.

entity are mapped on database objects of the manager repository. Mappings and associated architectures are presented for relational and CORBA-based object implementations. The manager repository is used as a ‘cached view’ of the distributed conceptual database consisted of the managed element MIBs, aiming to minimize network access (update requests), thus yielding lower manager response time and smaller network overhead.

(c) The hierarchical architecture[9][16][11] approach also relies on multiple (domain) managers and introduces the concept of the manager of managers (MOM). Each manager is solely responsible for the management of a domain and is unaware of the rest of the network. The MOM operates on a higher hierarchical level, retrieving information from and coordinating the domain managers. Unlike the previous architecture, the domain managers do not communicate. The architecture can easily scale up and more than one MOMs can be added as MOMs for MOMs can be introduced building a multiple level hierarchical scheme. This architecture offers easier development of integrated applications that retrieve information from multiple (possibly heterogeneous) domains.

The remainder of this paper is organized in the following fashion. In, Section II, current network management architectures are overviewed and our proposed approach is presented. In Section III we describe the proposed managerentity structure in detail and we specify the role and operation of the database module. Then, in Section IV, we demonstrate the mapping of key management services (for supporting manager-to-manager communication and most OSI SMFs and) on database objects considering two data models: relational and object model. Finally, in section V we outline our future research and development goals.

(d) The network architecture[9] is a combination of the distributed and hierarchical approaches. Instead of a purely peer-systems or hierarchical structure, the managers are organized in network scheme. This approach combines features and advantages from both architectures, preserves the scaleability and exhibits better functionality and adaptation in diverse, noncanonical environments.

II. A HIERARCHICAL MANAGEMENT MODEL Various architectures are currently being used or proposed for network management systems based on the manager-agent paradigm. Four approaches seem to prevail[9][11]:

The platform approach offers an attractive framework for developing and maintaining a network management system but it lacks scaleability, an important feature in today’s networking environments. When the network grows (in size, traffic or both) it is impossible to scale up efficiently the platform manager. Moreover, increasing the number of management applications above a limit causes a bottleneck effect on the platform, thus decreasing performance (yielding higher response time). Distributed approaches, like (b), (d), (c) offer easier scaleability and better control over multiple domain networks. In order to achieve high scaleability without sacrificing the flexibility of the platform approach, we have proposed[19] an architecture based on multiple managers (domain managers, MOMs, etc.), each having the form of a management platform. This platform manager-entity model is well suited for implementing manager-to-manager communications. Each manager offers a set of services (management primitives) that can be used both by applications and other managers. Thus, we can identify two entities in such an architecture:

(a) The centralized architecture[3][17] is the most commonly used. A single manager handles all agents in a centralized manner, provides centralized decision support and control and maintains a management repository. A variation of this architecture is the platform approach[9] where the manager splits into two parts: the management platform and the management applications. The platform handles low level management functions (information collection, monitor and control services, simple calculations like throughput and utilization, etc.) which are offered to the management applications through a common API. The applications operate in the second data processing level, handling decision support and higher functions than information gathering and simple calculations. Such an approach (both variations) exhibits all the advantages and disadvantages of a centralized system. The main deficiency is the inability to easily scale up when the network expands in size or complexity. However, in many cases centralized control is preferred.

(a)

(b) The distributed architecture[11] is associated with the management domain concept[18]. Multiple managers operate on a peer-system basis, each responsible for a managed domain. When information for another domain is needed, the manager communicates with its peer systems to retrieve it. Scaleability is the main advantage of this approach since 2

the manager entity may be a domain manager, a manager of managers (MOM) or an integrated manager. A domain manager provides detailed and summary information and is responsible for a specific domain. A MOM manages a group of other managers and provides summary information for them. An integrated manager is responsible for a domain that includes other managers and

provides detailed and summary information for the multiple, simultaneous users. All management services and domain and summary information for the information handled by the manager are mapped on the objects of this repository. The Kernel module is responsible managers. for updating the repository objects and interacts with the (b) the application entity may be a local application or network agents for control and information retrieval. an integrated application. A local application is All communication with the managed network elements built on top of a single manager (of any type) whereas a integrated application is using the is performed through the Management Protocol and Network Interface (MPNI) module which, depending on the services of more than one managers. network configuration, supports the required (possibly A typical scenario is demonstrated in Figure 1. For the multiple) network and management protocols (e.g. ICMP, manager-to-manager associations, the arrows point from the SNMP-SNMPv2, CMIP). service user to the service provider. Managers 1 and 2 are The Application / Manager Interface (AMI) module domain managers, responsible for network domains 1 and 2 respectively. Manager 4 is a MOM, responsible for handles all communication with the applications or other managers 2 and 3 and makes use of their services. Finally, managers utilizing the provided management services, manager 3 is an integrated manager that handles domain 1 through an application protocol (in [19] we propose the use and manager 2. Several local applications operate on top of of an SNMP or CMIP interface to the manager services and each manager. A single integrated application uses the present a specially designed MIB, the “Manager MIB”). This module translates requests to the native Storage services of managers 1 and 2. System interface, i.e. interacts with it through the its Data Application Application Manipulation and Data Definition Languages (DML, DDL). Furthermore, as it will be demonstrated bellow, this module Application handles the updating logic of the Manager Repository by Manager 4 (platform) driving the Kernel. Application Application or other Manager

Manager 3 (platform) Application

Operator / Administrator

Application Application

Application Protocol

Application

DML & DDL

Manager 2 (platform)

Application/Manager Interface

Manager 1 (platform)

Storage System Manager Repository

Kernel Application

Management Protocol and Network Interface Managed Domain 1

Managed Domain 2 Management & Network Protocols

Figure 1: Example scenario

SNMP/SNMPv2 Agents

III. MANAGER OVERVIEW

CMIP Agents

other...

Figure 2: Manager-entity structure

A. Manager Structure

The client-entities (applications or other managers) access the manager services through the AMI module and the supported software interface. The manager operator / administrator, however, has the additional choice of accessing the system through its native DML, DDL, playing the role of the database administrator (DBA) for performing extensions of the system, adding new objects and services, etc.

The proposed structure of the manager-entity is outlined in Figure 2. The manager structure is built around two core modules: the Storage System and the Kernel. The Storage System module maintains the Manager Repository and may be a Relational DBMS, an Object-Oriented DBMS or any other system with data (or object) management capabilities allowing large quantities of persistent data to be shared by 3

• Objects that need to be updated regardless of client requests. In this case, the object is associated with some contiguous action like monitoring of a throughput, an alarm, etc. This is the main reason for supporting both methods.

B. Storage, Access and Update Model According to their dependencies, data stored in the Manager Repository may be classified in two categories: •

Data with a short-term dependence on network objects. Information of this kind is directly or indirectly dependent on managed objects (e.g. MIB variables, network delays) and requires updating through network access in short periods. For example, a packet-in counter and a link utilization are directly and indirectly (respectively) dependent on MIB variables and need frequent updating in order to be considered valid.

•

Data with a long-term dependence on network objects. Data of this kind can be considered valid even after long periods without updating. For example, routing table entries need not be updated as frequently as throughput values and counters.

•

Data with no dependence on network objects. Data of this kind is independent of network objects after creation (like log entries and other static information) and do not require any updating..

• Critical objects that must be known if they are no more accessible. The polling method ensures that losing access to the polled object because of a fault will be discovered with a mean delay equal to T/2 (where T is the polling interval). Method (iii) and even method (ii), on the other hand, will not detect the error if no requests are issued after the fault. • Objects that need to be retrieved with minimal delay even in congested networks. The polling method will offer instances of network objects with approximately constant mean age, equal to T/2. If the object is not frequently accessed (inter-arrival time > T), application of method (iii) yields a mean value higher than T/2. Thus, the polling method requires less network accesses per request, resulting in lower response time (but higher network overhead). Even, in the case of frequent accesses, method (i) exhibits better performance with respect to response time. Both methods produce the same mean time of network accesses per request, but the polling method lacks the latency checking overhead (timestamping, etc.).

This classification, naturally, is not restricted to these three categories. Different temporal tolerances are associated with the objects stored in the Manager Repository ranging from none (the object is not considered In order to implement update method (iii) timestamping valid if not up-to-date) to complete tolerance (static is necessary, i.e. every object being updated according to information). method (iii) is associated with a timestamp stating the last Depending on this update latency and the expected access update (the value of the system timer at that time). The patterns we define three update strategies for the objects object is updated when it is accessed and (system_timerstored in the Manager Repository: object.timestamp) > object.tolerance. The timestamp is (i) Periodical update. This is the usual polling method updated with every object modification. with a given interval. The object is polled Objects stored into the Manager Repository should have periodically regardless of access to the repository. an additional attribute specifying their update method. Most products and manager implementations apply Objects with polling update method need one more attribute this method. (the polling interval), whereas objects with method (iii) (ii) Lazy update. This is the “update on demand” require two additional attributes: the timestamp and the strategy, where no update is performed until the temporal interval. Notice, however, that such an object is accessed. If more than one requests are implementation will introduce a significant storage queued before the value is returned from the network, overhead, especially if objects are of small sizes. For they are all served and no subsequent requests are example, for a 32-bit counter being updated with method (iii) the additional overhead of the timestamp and tolerance sent. might exceed its size. This overhead is minimized if update (iii) Lazy update with latency. The object is updated only classes are introduced and the stored objects carry only one if accessed and the period since last update exceeds a additional attribute: their update class identifier. Update pre-defined temporal tolerance. In that case the classes are stored in the Manager Repository including Manager Repository acts as a cached view of the method (ii), method (i) with multiple polling interval values distributed (conceptual) database of the managed and method (iii) with different temporal tolerances. For N network MIBs. classes only log2N bits are needed in every object for The periodical update method (i) is similar to method (iii) specifying the update method parameters. Storage since polling an object with a polling interval T has the requirements may be further decreased if grouping is same effect as updating on demand with latency T. applied: groups of objects are updated as a whole and only Nevertheless, method (i) is preferred in the following cases: one update class identifier is stored. Groupings may be 4

are taken. The appropriate data are returned to the client entity through the API. Polling is performed by the Kernel module, which maintains information for all repository objects of this type.

defined so that a beneficial side-effect takes place. By identifying sets of objects that are requested as a group in short periods, grouping can be used to provide a “prefetching” technique. Requesting and forcing an update for one object of the group results in updating the whole group, thus replacing multiple small-size network accesses with a single large-size access, minimizing overall network overhead. On the other hand, careful fine-tuning is needed since incorrectly pre-determined groups can significantly reduce performance by increasing network access size without taking of advantage of any reference locality.

(b) The update on demand method is applied. Data retrieved are assumed out-of-date and the update procedure is initiated for the object by sending the appropriate request to the Kernel module. The Kernel retrieves the appropriate data from the network through the MPNI module by generating a set of requests for specific MIB objects and/or a set network access actions (e.g. a ping - ICMP echo to one or mode nodes). Possible calculations are performed and an update request is issued to the Storage System module. The calculated object instance is returned to the AMI for completing processing of the requested service.

The maximal update latency allowed for every object is determined by the type of application that uses it and the amount and type of information needed. For example, a procedure analyzing the long term behavior of the managed network, aiming to produce overall statistics and estimate future requirements does not demand fast updating information; only sample data over a long period of time is needed. On the other hand a fault management or performance monitoring application exhibits higher requirements for timely information. Thus, the temporal tolerances must be resolved by considering all applications served by the specific manager. This fine-tuning operation as well as the estimation of access patterns and determination of update strategies is the responsibility of the manager administrator. The administrator accesses directly the Storage System through its native DDL and DML and defines or modifies update strategies, tolerances and possible groupings of objects according to access and usage profiles.

(c) The update on demand with a temporal tolerance method is applied. The object (or the object group) timestamp is checked. If the object instance age is within the pre-set tolerance, the system proceeds as in (a). If , however, the instance has “expired” an update request is generated as in (b). (d) No update method is applied, since the object is static. The retrieved information is returned to the cliententity.

IV. MAPPING OF MANAGEMENT SERVICES In this section we describe a set of management services that we use as a model for presenting the mapping on objects stored in the Manager Repository (within the operation framework discussed in the previous section). The selected services cover most OSI System Management Services (SMFs)[13][18] and a table associating these services with the SMFs is given after the service definition. First, we demonstrate their mapping on generic, abstract objects. Then, we consider two data models (relational and object model) and discuss the specific mappings and associated system architectures.

C. Manager Repository and Storage System Operation

The Storage System module maintains the Manager Repository, offering data (and possibly object) management services, ensuring consistency, constraint conformance, etc. The AMI module interfaces the applications and other managers to the manager services through a common API and implements the logic necessary for enforcing the update methods discussed above. The Kernel module drives the MPNI module for accessing the network, handles repository object updates (network access, value calculation and update request to the Storage System) and is responsible for A. Management Services polling scheduling. Both modules act as clients of the A brief description of the selected set of reference services Storage System and are the readers and writers of the follows: Manager Repository. Typical operation examples for object accesses of the three update methods follow. • Logging services. These are services for maintaining, When a client entity (application or manager) requests a updating and offering access to the system logs (event log, manager service through the API, the AMI translates the alarm log, configuration changes log, etc.). Physically the request to one or more accesses to the Manager Repository. logs are stored in the Manager Repository. Services include Objects are retrieved accordingly by accessing the Storage adding entries to a log, clearing and reading the log with System. For every object retrieved one of the following temporal and subject search criteria. • Alarm services. These are services for defining and (a) The polling update method is applied. In this case the disabling alarms given a threshold, monitoring intervals data retrieved is assumed valid and no more actions and objects to monitor (MIB variable, throughput, error

cases apply:

5

throughputs calculated by the platform, etc. The objects, the statistics required and the time interval for the calculations are defined by the client entity. - Reports of sets of objects. Objects, or part of their attributes, representing resources (e.g. Configuration Base Objects) or log records can be reported on particular times. Filters can be defined so that specific retrieval patterns are applied. The client entity defines the set of objects (or attributes of objects), the time interval for the information gathering and optionally a filter. - Alarms and Events. Threshold alarms can be set on the statistic objects. The client entity links the statistics object to the alarm, defines the threshold and the monitoring interval and sets the event that will handle the alarm activation. Events are triggered by reports and alarms. For reports an asynchronous report notification is generated and sent to the defined destination. For an alarm activation an alarm notification is sent, or the event is logged in the Manager-to-Manager Services Log (M2M Log), or both. The client element defines the course of action when an event is triggered. - Manager-to-Manager Logging. This service handles access to the M2M Log which is stored in the Manager Repository. Log reports can be defined by the client element and scheduled through the report scheduling service.

rate, etc.). The client entity must also define an event (through the Event/Trap Handling services described bellow) that handles alarm activation. • Event/Trap services. These services are responsible for handling the asynchronous notifications (traps) received from the agents and the events generated by the manager (e.g. notification that a host is unreachable by the manager site) and for managing alarm-associated event definition. Services for setting up event filters are supported. When an event/trap is collected by the manager the client entities are notified according to these filters, and an event log entry is generated. In addition, the client entity may define events that will be triggered by alarms. Such an event will generate an asynchronous notification to the client entity and/or a log entry to the alarm log. • Configuration services. These services are associated with the resource, topological and configuration management of the network. They monitor the network for configuration changes, update the appropriate log and maintain two data structures: the Configuration Base (CB) and the Network Class Library (NCL). The NCL keeps information about the different network object classes. Instances of these classes compose the configuration description stored in the CB. Both structures are stored in the Manager Repository. Services are offered for reading and modifying the CB, adding and deriving network object classes in the NCL, etc.

The following table associates these services with the OSI • Monitoring services. These services perform all MIB SMFs: variable monitoring and retrieving, calculate throughputs, error rates, utilization factors, etc. Services are offered for Services Associated OSI SMFs retrieving single object values (MIB variables, tables and Logging Log Control objects or calculated entities like throughputs, rates, etc.) or Alarm Alarm Reporting, Workload Monitoring setting a continues monitoring procedure. (partly)

• State monitoring services. These are tightly associated with the configuration services, and they are responsible for monitoring the states and possible state changes of the managed network elements. In a TCP/IP network, for example, they may use the ICMP protocol for checking the up/down state of network entities.

Configuration

Object Management, Relationship Management, State Management (partly), Event-Report Management (partly)

• Manager-to-Manager communication services. These are responsible for manager to manager communication. They apply concepts from the OSI Summarization SMF[20] and the Manager-to-Manager MIB[2]. They use all the previously described services for offering summarization reports about the manager domain, and allow the definition of alarms and events. The services offered include: - Summary report scheduling. This service offers the means for scheduling the time and the intervals between the report notifications. It is used in conjunction with the other services discussed below, for scheduling reports. - Statistics reporting for metric objects. The client entity (manager) may request statistics (mean/time average, variance, min-max, percentages, etc.) for metric objects of the Manager Repository, like MIB metric variables,

MIB Monitoring

Workload Monitoring

Event-Trap Handling

Event-Report Management

State Monitoring

State Management

Manager-to-Manager

Summarization, Alarm Reporting (partly),

Communication

Event-Report management (partly)

B. Generic Object Mapping In this subsection the management services, defined above, are mapped on a generic object model, so that on the next two subsections it can be extended to include both the relational and the OMG OMA concrete object model (see bellow). The adopted model is a simplified version of the classical object model including attributes but excluding 6

these filters and notifies client entities accordingly. Client entities with no filters defined receive all traps/events. The event/trap filter object has the following attributes: the client entity id, booleans for every trap and manager event. Since only static information is stored in both object types, no update method is meaningful.

methods and object active functionality. Since the object in this model do not have any functionality, polling and other actions (asynchronous or not) that cannot be triggered by a repository access, have to be performed by the Kernel module. • Logging services. Each system log (alarm log, configuration changes log, etc.) is mapped on an object container, the log object container, consisting of log entry objects. The log entry object has the following attributes: date and time of logging, log descriptive text, client entity owner identification. Adding, deleting entries and clearing the logs is straightforward: objects are added, deleted and log containers are cleared. Filtered searches are performed by simple queries. Logs are static objects with no direct dependence on network object, thus no update method is needed. Log contents are read-only.

• Configuration services. The Network Class Library (NCL) is a container of network class definition objects. The network class definition object has the following attributes: a derive-from attribute pointing to another object in the container (or empty), a variable number of the following attribute couple (attributen name, attributen value type) and an update class identifier. The client entity may add entries to the container with the appropriate attribute definitions, in order to define network element classes. For example an generic link class definition might look like this:

• Alarm services. Alarms are mapped on alarm entity objects held in object containers, one container for every client entity. The alarm entity has the following attributes: the object to be monitored (pointer to a Monitoring services object), the network element that the monitored object belongs to (pointer to a CB object), rising and falling thresholds, a sampling interval, rising and falling events (pointers to an Event/Trap service objects) and current value. Defining an alarm is accomplished by defining at least one -rising or falling- event (see bellow), defining if necessary a monitoring object (see bellow) and adding an alarm object with valid (according to reasonable constraints) attributes. Deleting an alarm is as simple as removing an alarm entity object from the container. In addition, a client entity may choose to retrieve the current value of the monitored object by reading the current value attribute. Obviously, the polling update method is applied for the alarm entity objects, with a polling interval equal1 to the polling interval attribute.

derived-from: NULL attribute1-name: LINK-SPEED attribute1-value-type: INTEGER attribute2-name: LINK-TYPE attribute2-value-type: ENUMERATED update-class-id: 25

If the derive-from attribute is not empty, the represented class inherits all attributes from the class definition pointed to. For example, a router definition may be used to derive a specific vendor router with additional attributes. Class definition objects may be viewed, modified or appended by the client entities. The update class id attribute defines the update method that should be used for the class instances. Notice that the update method depends on the class attribute semantics. It is defined at creation time by the client entity through a specific ‘class registration’ service. The Configuration Base (CB) is modeled by a second object container consisting of network objects. These objects model the managed network elements, i.e. they are the NCL instances. Their attributes are: a pointer to a class definition object, values for every attribute described in the class definition. The update method used is inherited by the class definition. The client entity may read, update or append the CB. All configuration services accessible to the client entities through the manager API, translates to adding to, deleting, modifying or accessing objects of these two containers.

• Event/Trap services. Two types of objects are required for these services. The event entity objects represent the events that will be triggered by an alarm activation, and they have the following attributes: the client entity to notify, a notification code (set by the client entity), an object list containing the objects whose instances will be included in the notification and a textual description for logging purposes. If the client entity attribute is empty no notification is performed, and likewise, if the logging text is empty logging is disabled. For an event entity to be valid, at least one of these two attributes must be non empty. The event/trap filter object defines the notification options for a specific client entity. When a trap is intercepted by the MPNI module, or an event is generated by the manager (like the host-down event), the Kernel module consults

• Monitoring services. These services are based on the monitored object. Its attributes are: the MIB object id to be monitored, a second MIB object id (used only for rates), the address of the MIB (network address and other access information like the SNMPv2 party name), the monitoring type (simple monitoring, throughput, rate, etc.), the calculation window size (if 0 instant values are monitored), 1 A heavy loaded manager or long delays may yield a higher actual the sampling interval, the current value, a notify entity id, polling interval. Moreover, if the number of update classes (if update method, update tolerance or polling interval. The used) is restricted, the actual polling interval will be matched to client entity is free to choose any update method of the the nearest value of an already defined class.

7

to tuples with relation attributes being the object attributes. The mapping is simple and utilizes the full power of setoriented languages like SQL for retrieving and updating data, implementing various search criteria, etc.

three. Optimization methods may be used so that polling intervals are normalized and more than one objects of the same variables are condensed to one. The monitored objects may be accessed explicitly (reading the ‘current value’ attribute), connected to an alarm, or asynchronously notify the client entity, if the ‘notify entity id’ is not empty.

Figure 3 outlines the structure of the manager modules (see Figure 2) and their inter-dependencies for a relational • State monitoring services. The state object models the Storage System implementation. state of a network element and has the following attributes: The AMI consists of the following sub-modules: The API a network object (pointer to a CB object), the sampling Implementation sub-module implements the API offered to interval and the current value (up, down, unknown). A client entities and intercepts service requests by the clientpolling procedure that checks the specified network element entities. The API Object/Relation Conversion sub-module is state with the set sampling interval is associated with each responsible for decoding the API objects into actual state object, i.e. the polling update method is applied for relations stored in the Manager Repository. The Manager these objects. Repository is accessed through the RDBMS Client sub• Manager-to-Manager communication services. These module. If the data retrieved are invalid (update on demand is used or the temporal tolerance is exceeded) an object services are built around various containers: - Summary report scheduling. The reports container update is issued requests to the Kernel module. maintains all the report configuration and scheduling Communicating with the Kernel module is also needed for information. The container consists of report entity scheduling polling procedures (when a requested service of objects with the following attributes: the manager id this type is accessed by a client-entity. Interaction with the (address of manager to report), the reporting interval, a Kernel is handled by the Control Logic sub-module. pointer to a statistics report object (see bellow) - which Application / Manager Interface may be empty - and a pointer to an object set report API Implementation object (see bellow) - which may also be empty. At least one pointer must be non empty for the report object to be API object / relation valid. conversion Control data Logic - Statistics reporting for metric objects. The statistics RDBMS Client report object is a container of statistics report entity RDBMS objects. These objects have the following attributes: a queries metric object (pointer to a monitored object - see Monitoring services), the report type (min-max, mean, update or polling update data request variance, etc.), the time period and the sampling interval. - Reports of objects sets. The object set report is a data Manager RDBMS Client Repository container of summary objects. A summary object has the following attributes: a Manager Repository object Control Management Function Kernel Calculation Logic (pointer), the start time, the end time and a sampling interval. Polling Object

Scheduling - Alarms and Events. The alarm entity and event entity objects are similar in concept with the ones presented in Data Network access request the Alarm and Event/Trap Handling services. Management Protocol and Network - Manager-to-Manager Logging. The M2M Log is a Interface container of two object types. The alarm log entry objects Figure 3: Relational Implementation Architecture are identical to the log entries described in the Logging services. The report log entry is similar, but instead of a The Kernel module is composed of the following subtextual description, the whole report is stored. This is modules: The Control Logic and the RDBMS Client subuseful if the client manager does not want to be notified, modules are similar to the corresponding sub-modules of but instead, retrieve a report log (historical data) at a the AMI module. They handle interaction with the AMI later time. module and the RDBMS, respectively. The Management Funtion Calculation sub-module processes network data for C. Relational Data Model producing the actual instances stored in the Manager Mapping the generic objects described in the previous Repository (e.g. calculates a throughput using a window of subsection into the relational model is easy: Object polled values). The Polling Object Scheduling sub-module containers are converted to relations and contained objects is responsible for setting up monitoring and updating

8

procedures. When an update request is issued by the AMI, and request updating or initiation of a polling procedure by this sub-module retrieves the network data (through the the Kernel module. MPNI module), uses the Management Function Calculation Application / Manager services to create the new instance (if needed), sends an Interface update to the Manager Repository and returns the new API Implementation instance to the AMI. objects

Both modules (Kernel and AMI) act as RDBMS clients and can be implemented in any procedural language (like C and C++) with embedded SQL statements. Notice that, since the “objects” maintained by the RDBMS do not have any functionality attached, all actions (like calculations, update checking and polling) are performed by these clients.

Manager Repository

API object / ORB object conversion

Object Storage System Implementation

CORBA Interface

CORBA Interface access request update data

CORBA Interface

D. Object Data Model

Polling Object Scheduling

Different object technologies and various object storage system implementations exist. In this paper we adopt the concrete object model defined by the Object Management Group (OMG) Object Management Architecture (OMA)[14] documents. This specification is prescriptive in defining concepts meaningful to clients and client-server interfacing, but allows maximal freedom for different object implementation technologies and object services by being merely suggestive in implementation issues. The Common Object Request Broker Architecture (CORBA)[15] is based on this object model and it is structured to allow integration of a wide variety of object systems. The CORBA framework defines how the object storage system provides services to clients based on the concept of the Object Request Broker (ORB). A key component of the architecture is the Interface Definition Language (IDL) used to describe object interfaces and specify the provided services. Converting the generic object mappings on this model is straightforward since the generic object model is a subset of the OMA model.

Data

Kernel

Network access request

Management Protocol and Network Interface

Figure 4: Object Implementation Architecture

As in the relational architecture, the Kernel and MPNT modules are implemented in a procedural language, preferably with inherent object features (like C++), and they implement a CORBA compatible interface. CORBA IDL language mapping for C has been completed and a C++ mapping is under standardization (a non standard mapping is presented in [24]).

V. SYNOPSIS - FUTURE WORK We have presented a multiple manager architecture for hierarchical management of large multiple domain networks with a manager element based on a database core module, assuming a MIB-based management framework (TCP/IP framework - SNMP/SNMPv2, OSI framework CMIP). We have defined key management services, demonstrated their mapping on database objects, and proposed their implementation with a conventional RDBMS or an object storage/management system with a CORBA interface. We intend to further work on mapping management functions on the OMA concrete object model and implement a CORBA-based prototype. We have already implemented a platform-based manager supporting part of the proposed services and we intend to expand it in order to support an SNMPv2 API and integrate a Storage System module.

The proposed CORBA-based architecture is presented in Figure 4.

Any object storage & management system may be used to implement the Storage System of the proposed architecture. The only constraint is the ability to implement a CORBA interface. The Kernel and AMI modules use similar CORBA interfaces to access the Storage System and the object services. Their structure is similar to the ones presented in Figure 3 (RDBMS case). Notice, however, that in the object implementation the Kernel does not have a Management Function Calculation sub-module and no interaction between the Kernel and the MPNI exists. Both differences are resulting from the fact that, in the adopted model, objects may have methods and encapsulated functionality. Thus, every object is capable of “reREFERENCES calculating itself” and update its instance when new network values are provided (through calling the appropriate method). Furthermore, another method may be [1] Ball L., “Cost Effective Network Management”, New York: McGraw-Hill, 1992. defined for accessing the objects, that will check validity 9

[2] Case J., McCloghrie K., Rose M., Waldbusser S., “Managerto-Manager Management Information Base”, RFC 1451, April 1993.

Function - International Organization for Standardization Draft International Standard 10164-13 - September 1993.

[21] [3] Cassel L.N., Patridge G., and Westcott J., “Network Management Architectures and Protocols : Problems and Approaches”, IEEE Journal on Selected Areas in [22] Communications, Vol. 7, no. 7, Sept. 89. [4] Cohrs D.L., Miller B.P., “Specification and verification of network managers for large internets”, ACM Sigcomm, 1989. [5] Open Software Foundation, “OSF Distributed Management Environment (DME)”, DATAPRO International, 1993.

Wasson L., Schwab B., Scholberg J., “Database management for an integrated network management system”, Network Management and Control, 1990. Wolfson O., Sengupta S., Yemini Y., “Managing Communication Networks by Monitoring Databases”, IEEE Transactions on Software Engineering, 17(9), 1991.

[23] Valta R., “Design concepts for a global network management database”, Integrated Network Management II, North Holland, 1991.

[6] Dupuy A., Sengupta S., Wolfson O., Yemini Y., “Design of [24] Vinoski S., “Mapping CORBA IDL into C++”, C++ the Netmate Network Management System”, Integrated REPORT magazine, 6(7), September 1994. Network Management, Elsevier Science-North Holland, 1991. [25] Yemini Y., Yemini S., “Modeling Management Semantics”, [7] Digital Equipment Corp., “Enterprise Management Second IEEE Network Management and Control Workshop, Architecture”, DATAPRO International, 1992. New York, September 1993. [8] Haritsa J.R., Ball M.O., Roussopoulos N., Datta A., Baras J.S., “MANDATE: Managing Networks Using Database Technology”, IEEE Journal on Selected Areas in Communications, 11(9), 1993. [9] Herman J., “Enterprise Management Vendors Shoot It Out”, Data Communications International, November 1990. [10] Hong J.W., Bauer M.A., Marshall A.D., “Distributed Information Repository for Supporting Integrated Network Management”, Second IEEE Network Management and Control Workshop, New York, September 1993. [11] Leinwand A., Fang K., Network Management: A Practical Perspective, Addison Wesley, 1993. [12] Muralidhar K.H., “Knowledge-based Network Management”, Telecommunications Network Management into the 21st Century, IEEE Press, 1994. [13] Network Management Information Service, “OSI-Based Network Management”, DATAPRO International, 1991. [14] Object Management Group, Inc., “Object Management Architecture Guide 1.0”, Chapter 4, OMG TC Document 90.9.1, November 1990. [15] Object Management Group, Inc., “The Common Object Request Broker: Architecture and Specification”, OMG TC Document 93.12.43, December 1993. [16] Rabie S., “Integrated Network Management: Technologies and Implementation Experience”, Infocom '92, IEEE, 1992. [17] Rose Marshall T., The Simple Book: An Introduction to Internet Management, 2nd edition, Prentice-Hall, 1994. [18] Information processing systems - Open Systems Interconnection - Systems Management Overview International Organization for Standardization - International Standard 10040 - November 1992. [19] Stamatelopoulos F., Chiotis T., Maglaris B., “A Scaleable, Platform-Based Architecture for Multiple Domain Network Management”, submitted to IEEE/ICC ‘95, 1995. [20] Information processing systems - Open System Interconnection - Systems Management: Summarization

10