Department of Electrical and Computer Engineering. National Technical ... management services to applications and other managers (higher in the hierarchy).
A Scaleable, Platform-Based Architecture for Multiple Domain Network Management F.Stamatelopoulos, T.Chiotis, B.Maglaris NETwork Management and Optimal DEsign (NEWODE) Group Department of Electrical and Computer Engineering National Technical University of Athens Abstract
-
One of the main deficiencies of platform-based network management systems is their inability to scale up efficiently. However, the platformlapplication approach presents an attractive model with many advantages like software maintainability and expandability, low management traffic overhead, reduced cost due to its centralized nature, etc. We present a platform-based architecture for managing large multiple domain (and possibly multi-vendor) networks through a scaleable, hierarchical scheme. Our proposed network management system consists of a network of element-managers, each responsible for a different domain (of managed objects and possibly other managers). Each element behaves as a platform offering a set of management services to applications and other managers (higher in the hierarchy). We propose a MIB ( S ” v 2 or CMIP) interface and a mapping of all management services onto a “Manager M I B . We outline the proposed MIB structure and define objects responsible for some key management services and manager-to-managercommunication.
architecture, the network of managers, combines features from (b) and (c). The systems mainly differ in the number of managers useld and their degree of interaction and independence. The centralized architecture [2][8] is the most commonly used one and consists of a single manager responsible for the management of the whole network. The manager handles the communication with the agents of the managed network elements, provides centralized decision support and control and maintains a manager repository. Such an approach 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. The architecture is outlined in figure l(a).
@
0 Manager
---
@
Common API
I. INTRODUCTION Efficient network management is important in any networking environment, and becomes more significant and vital to the orderly operation in large, multiple domain networks. Different solutions are proposed based mainly on distributed, multiple manager schemes. The need for scaleability leads to less centralized management architectures [13]. In this paper we present a scaleable, platform-based architecture for management of such large, multiple domain and possibly multi-vendor networks. The system consists of multiple manager/platform entities and client applications, arranged in a network preserving a hierarchical organization. Every manager entity supports a set of management services, offered to client applications and other managers. The manager/platform handles information gathering and simple data processing (throughput and rate calculations, etc.) whereas the client applications handle higher operations like decision making, planning, etc. Both entity types view the services through a common interface based on the MIB paradigm. We define key management services and present an outline of the Manager MIB structure. A generic representation is used so that a CMIP or S N M P Manager MIB can be designed based on the proposed structure.
11. BACKGROUNDSURVEY Different approaches and architectures for management systems are currently being used or proposed. Three approaches seem to prevail [4][5]: (a) the centralized, (b) the distributed (peer systems) and (c) the hierarchical architectures. A fourth 0-7803-2486-2195 $4.00 0 1995 IEEE
“9 nodB
(a 1
(b)
Figure 1: (a) Centralized manager and (b) Platform approach
A variation of the centralized architecture is the platform approach [4] (figure l(b)). The single manager splits into two parts: the management platform and the management applications. The platform offers a first stage of processing of the management data, being concemed mainly with information collection, provides key management services like monitoring and control, throughput calculation etc., and hides the underlying management protocols offering an abstract view to the applications. The applications operate in the second data processing level, handling decision support and higher functions than information gathering and simple calculations. The two parts communicate through a common application programming interface (API). This architecture offers easier maintenance and expandability and simplifies development of integrated applications in heterogeneous, multi-vendor, multi(management)protocoI environments. Heterogeneity and protocol complexity is handled once in the platform level, not in every application. However, the limited scaleability is
1453
inherent in the centralized structure. In addition, the platform proves to be a serious bottleneck when the number of applications increases. The distributed approach[5] is associated with the management domain concept[9] and utilizes more than one peer managers. It is well suited for multiple domain networks since it is based on a manager per domain philosophy (different domains are defined for geographical, organizational, or other reasons). 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. Higher performance requirements or possible expansions of the managed network are satisfied by creating more domains and adding a respective number of managers. The architecture is sketched in figure 2. The hierarchical architecture (figure 3) [4][7][5] also applies the manager per domain paradigm, and further introduces the concept “manager of managers” (MOM). Each domain manager is solely responsible for the management of its domain and is unaware of the rest of the network. The MOM
Manager n
Figure 2: Distributed (peer-manager)
architecture operates on a higher hierarchical level, requesting information from the domain managers. Unlike the previous architecture, the domain managers do not communicate. The architecture can easily scale up and more Manager of Managers than one MOMs can be (MOM) added. 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 Figure 3: Hierarchical architecture heterogeneous) domains.
A combination of the distributed and hierarchical architectures, the network architecture[4] is sketched in figure 4. Both the manager per domain (element managers) and manager of managers (integrated managers) concepts are amlied. Instead of a purely peersystems or hierarchical Manager 2 structure, the managers are organized in network scheme. This approach combines features and advantages Figure 4: Network architecture from both architectures, preserves the scaleability and exhibits better functionality and adaptation in diverse, non-canonical environments. I 1
111. SCALINGUP THE PLATFORM When the network grows (in size, traffic or both) it is impossible to scale up efficiently a platform based management system. The response time of the platform-manager increases proportionally to the managed network growth. Furthermore, increasing the number of applications operating on top of the platform above a limit (depending on the platform processing power) causes a bottleneck effect, thus decreasing performance (higher response time). In order to achieve high scaleability without sacrificing the flexibility of the platform approach, we propose an architecture based on multiple managers (domain managers, MOMs, etc.), each having the form of a management platform. This platform-server 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 manager enfifycan be a domain manager, a manager of managers (MOA$ 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 domain and summary information for the managers. (b) the application entity can be a local application or an integrated application. A local application is built on top of a single manager (of any type) whereas a integrated application is using the services of more than one managers.
1454
An typical scenario is demonstrated in figure 5. For the manager-to-manager associations, the arrows point from the service user to the service provider. Managers 1 and 2 are
IApplipatlon_)
j y - )
1
i
j/
;
(platform)
Manager 1
/
:
i
:,
i
(Application)
1 : .
...______. i I n
;
.......................
~pplication
.
Domain 1
The Kernel module implements “housekeeping” operations and the management services. It uses the services of the lower layer to retrieve m;anagementinformation from the network and offers services to the applications and other managers through the higher layer. The internals of this module are discussed further in the text. Finally, the Application/Manager Interface module handles all communications with the applications and managers that use the platform services. In effect, this module implements an agent with the proposed Manager MEI interface for the platform service users. A structural decomposition of the module into three layers is presented in figure 7 . The core layer is the Storage System that maintains the Manager Repository. The kernel functions retrieve information from and update the manager repository, through the Kernel-Storage System Interface layer. Finally, the upper layer (SNMpv2/CMP Agent) offers a MIB interface (SNMPv2 or CMIP) to the applications
Domain 2 ApplicationlManaget Interface
ir‘l+si
Figure 5: Typical scenario
domain managers, responsible for network domains 1 and 2 rcspectivcly. Manager 4 is a MOM, responsible for managers 2 and 3 and makes use of their services. Finally, manager 3 is an integrated manager that handles domain 1 and manager 2. Several local applications operate on top of each manager. A single integrated application uses the services of managers I and 2. Management Applications
r]rl _
__
SNMPv2ICMIP Agent
I
Reposito
I
Storage System
I
I I I
I
other Managers
_
L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ~
’ Management Platform/Sewer
ApplicationlManager Interface
Figure 7: Applicatiodmanager interface module
I I I
I I I
Kernel \
I
L - - _ _ - - _ _ _ _ - _ - - _ - _ I
SNMPv2 agents
Management Protocols
manager
Figure 6: Manager structure
Iv. PROPOSED MANAGER ARCHITECTURE OVERVIEW In this chapter we present a structural overview of the proposed manager-platform (figure 6) and describe some management services that we use to design the Manager MIB presented. In figure 6 the manager is decomposed into three mo dules/layers. The Management Protocol and Network Interface module handles all communication with other management elements lower in the hierarchy. These may include SNMY, SNMPv2, CMIP, other proprietary agents, or other management platforms. This module may, also, offer an interface to other network protocols and services (ICMP, for example, can be used in a TCP/IP network for monitoring the state of elements).
and other managers. All management services offered by the platform are mapped physically on the manager repository and conceptually on the Manager MIB. We are currently working on defining the service mappings, access methods and data model and implementing the storage system using a DBMS[1I]. Figure 8 sketches a possible structure of the kernel module. Some key management functions/modules are: Log Manager. This module maintains, updates and offers access to the system logs (event log, aim-log, security and access log, configuration changes log, etc.). Physically the logs are stored in the Manager Repository and are accessed by the log manager through the Kernel-Storage System Interface. Its services include adding entries to the log, clearing the log and reading the log with temporal and subject search crlteria. Alarm Manager. This module defines and removes alarms given a threshold, monitoring intervals and objects to monitor (MU3 variable, throughput, error rate, etc.). The client entity must also define an event (through the Event/Trap Handler) that handles alarm activations. Security and Accounting Manager. This module monitors the managed network for security and accounting purposes. It monitors network access and can selectively log access 1455
information (specific entry points, users, resource usage, etc.). Furthermore, alarms can be set for security or accounting violations. The implementation of this module assumes that appropriate objects exist in the managed element MIBs. No such MIB is defined yet ( S W framework), even though the Host Resources MIB gathers information about users and processes[3][14]. We are currently working on defining a SNMPv2 MIB that will maintain information specifically for security and accounting
Figure 8: Kernel module 0
*
Network Object Manager. This module is responsible for the resource, topological and configuration management of the network. It monitors the network for configuration changes, updates the appropriate log and maintains two data structures: the Con3guration Base (CB) and the Class Library (CL). The CL keeps information about the different network object classes and instances of these classes compose the configuration description stored in the CB. Both structures are stored in the Manager Repository and are maintained by the Network Object Manager module. Services are offered for reading and modifying the CB, adding and deriving object classes, etc. M B Monitoring Services. This module performs all MIB variable monitoring and retrieving and calculates throughputs, error rates, utilization factors, etc. It offers services for retrieving single object values (MIB variables, tables and objects or calculated entities like throughputs, rates, etc ) or setting a continues monitoring procedure.
Event/Trap Handler. This module is 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) and for managing alarm-associated event definition. Services for setting up evcnt filters are supported. When an eyenutrap is collected by the module the client entities are notified according to these filters, and an event log entry is generated. In addition, the module allows to the client entity to define events that will be triggered by alarms. Such an event will generate an asynchronous notification (Manager M B trap) to the client entity and/or a log entry to the alarm log. * State Monitoring Services. This module is tightly associated to the Network Object Manager module, and is responsible for monitoring the states and possible state
changes of the managed network elements. In a TCP/IP network, for example, it could use the ICMP protocol for checking the upldown state of nodes. 0 Manager-to-Manager Services. This module handles manager to manager communication. It applies concepts from the OS1 Summarization System Management Function[121 and the Manager-to-Manager MIB[l]. It uses the services of all the previously described modules for offering summarization reports about its managed domain, and allows the definition of alarms and events. The services offered include: (a) Summary report scheduling. This service offers the means for scheduling the time and the intervals between the report notifications. This service is used in conjunction with the other services discussed below, for scheduling reports. (b) Statistics report for metric objects. The client entity (manager) may request statistics (meadtime average, variance, min-max, percentages, etc.) for metric objects of the Manager Repository, like MIB metric variables, throughputs calculated by the platform, etc. The objects, the statistics required and the time interval for the calculations are defined by the client entity. (c) Report of sets of objects or object attributesCfiltered or non $ltered). 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 ob-jects), the time interval for the information gathering and possibly a filter. (d) Alarm services. Threshold alarms can be set on the statistic objects discussed in (b). 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. (e) Event services. 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, a notification is sent, 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. (d) Logging and log access. This service handles all accesses to the Manager-to-Manager Log (M2M Log) which is stored in the Manager Repository. M2M Log reports can be defined by the client element and scheduled through service (a). Although these services aim to be used by other managers, there is nothing restricting their use by applications. Table 1 associates the kernel functions/modules discussed above, to the OS1 SMF[6][9].
1456
Kernel Function-Module Log Manager Alarm Manager Security and Accounting Manager Network Object Manager
MIB Monitoring Services Event-Trap Handler State Monitoring Services Manager-to-Manager Services
r-q
Associated OS1 SMFs
Manager
Log Control Alarm Reporting, Workload Monitoring (Partly1 Security Audit Trail, Security Alarm Reporting, Access Control (partly), Accounting Meter Object Management, Relationship Management, State Management (partly), Event-Report Management (partly) Workload Monitoring Event-Report Management State Management Summarization, Alarm Reporting (partly), Event-Report management (partly)
EvenVTrap setvices
entity
Management
event/ trap finer
V. MANAGER MIB We outline the proposed MIB structure and define the objects in a generic, abstract representation so that both SNMP/S"v2 and CMIP implementations can be designed and developed. The MIB object definition is an abstract form describing the general structure and functionality of the object, not the exact representation in a specific protocol. The MIB presented is not complete and only a few objects (for key Kernel services) are presented. The purpose of this presentation is to define the general structure of the Manager MIB and the mapping of the platform services on its objects. The MIB structure is outlined in figure 9. Objects are presented for Alarm Services, MIB Monitoring Services, Log Management Services, Event/Trap Handler and Manager-to-Manager Services. The attributes of these objects are given bellow. alarm entity. An instance is created for every alarm set by a client entity (application or manager). Its attributes are: Attribute alarm id oid net-object id
Type object id object id object id
rising threshold falling threshold interval delta
float float int boolean
rising event
object id
falling event
object id
current value
float
e
Descriution The object id of the instance The id of the object to be monitored The id of the node whose MIB is being monitored. If it is 0 then the oid attribute refers to a Manager MIB object The rising threshold The falling threshold The sampling interval in seconds If true then the difference is compared to the threshold The event entity id associated with the rising alarm The event entity id associated with the falling alarm The sample of current interval
Object
variance
Figure 9: Manager MIB structure outline
event/trai)Jilter. Attribute notify
Type object id net address int
notification id data
object list
logging
boolean
log text
text
I
Tvue net address boolean
eventhap 1 ....
eventitrap n
I
Description The network address of the client entity setting the filter. Filter flag
I Filter flag
boolean
alarm (event, etc.) log entry entity. Attribute
Description Entry time Textual description of entry
description
M E variable entity, throughput entity, rate enti@, etc.
7I e
evententity Attribute event id notify
--
Descriution The object id ofthe instance The network address of the client entity to be notified. If it is 0 no notification is sent The notification code (set by the client entity)
oid net-object id event id
Type object id object id object id object id
window size interval
int int
1
Description The object id ofthe instance The idof the object to be monitored The id of the node whose MIB is being monitored The event entity that will be sent to the client entity. The value is stored in the data attribute The calculation window in seconds The sampling interval in seconds. if it is 0 only one value is sent
report entity. Attribute event id
Any data sent to the client-entity are stored here If true a log entry for the Alarm Log is generated Textual description for log entry
1457
-
Type -object id
interval object set id
int object id
stat report id
object id
Description The object id of the event that will be used to send the report The interval in seconds between reports The object id of the associated object set entity (may be empty) The object id of the associated stat report entity (may be empty)
alarm entity (Manager-to-Manager Services). Its attributes are almost identical to the alarm entity presented above. The only difference is that no net-object id is needed and the oid attribute is valid only when refemng to a Metric Object Statistics entity. event entity (Manager-to-Manager Services). Its attributes are almost identical to the event entity presented above. The only difference is that logging is performed in the M2M Log. stat report entity. Every instance of this object contains a set of min-max, mean, etc. entities consisting a statistics report. min-max enti@, mean entity, variance entity. Its attributes are identical to those of the MIB variable, rate, etc. entities. object set entity. Every instance of this object contains a set of summary objects consisting a object set report. summary object.
Attribute date time report
Type date time report entity
Description Entry date Entry time report entity object
[2] Lillian N.Casse1, Graig Patridge, and Jil Westcott. “Network Management Architectures and Protocols : Problems and Approaches”, IEEE JSAC, Vol. 7, no. 7 , Sept. 89. [3] Grillo P., Waldbusser S., “Host Resources M B ” , RFC 1514, September 1993. [4] James Herman, “Enterprise Manage-ment Vendors Shoot It Out”, Data Communications International, November 1990. [5] Allan Leinwand, Karen Fang. “Network Management ; A Practical Perspective ”, Addison Wesley, 1993. [6] Network Management Iuformation Service, “OSI-Based Network Management”, DATAPRO International, 1991. [7] Sameh Rabie. “Integrated Network Management : Technologies and Implementation Experience”, Infocom ‘92, IEEE, 1992. [SI Rose Marshall T., “The Simple Book: An Introduction Internet Management”, 2nd edition, Prentice-Hall, 1994. [9] Information processing systems - Open Systems Interconnection - Systems Management Overview International Organization for Standardization - International Standard 10040 - November 1992. [lo] Stamatelopoulos F., Stathatos K., Karounos T., Maglaris B., ”Cerberus Network Management System”, ERSIM International Workshop, Crete, Greece, 1992 [ l l ] StamatelopoulosF., Roussopoulos N., “Using a DBMS for Hierarchical Network Management”, accepted for presentation at the Engineer Conference NETWORLD+INTEROP ‘95, March 1995. [12] Information processing systems - Open System Interconnection - Systems Management: Summarization Function - International Organization for Standardization Draji International Standard 10164-13 September 1993. [ 131 Waldbusser S.L., “The Trend Towards Hierarchical Network Management”, The Simple Times, The Bi-Monthly Newsletter of S N M P Technology, Comment, and Events, Volume 2, Number 6, NovemberDecember 1993. [14] Waldbusser S.L., “A Look at the Host Resources MIB”, The Simple Times, The Bi-Monthly Newsletter of S N M P Technology, Comment, and Events, Volume 2, Number 3, MayiJune 1993.
-
CONCLUSIONS AND IMPLEMENTATION ISSUES We presented a hierarchical, platform-based network management architecture for resolving problems of scaleability and management efficiency in large, multiple domain networks. The notion of the Manager ME3 (presented in a generic, non protocol-specific structure) allows for platform-based architectures in hierarchical configurations. It resolves manager-to-manager communications in a standardized form, unifying management applications and managers via the single interface of the platform. The basic concepts of platform-based managers have been demonstrated in an early prototype [STAM92]. The proposed manager architecture is being developed as a S ” V 2 Manager MIB. In parallel, we are working towards simulation models (source and traffic models) for’setting and running simulations For comparing the different architectures in terms of efficiency and performance. REFERENCES [l] Case J., McCloghrie K., Rose M., Waldbusser S., “Manager-to-Manager Management Information Base”, RFC 1451, April 1993.
1458
