i JAVA-BASED INTELLIGENT NETWORK MONITORING by Haifeng Xi Thesis submitted to the Faculty of the Graduate School of the University of Maryland at College Park in partial fulfillment of the requirements for the degree of Master of Science 2000 Advisory Committee: Professor John S. Baras, Chair Professor Mark Austin Professor Nick Roussopoulos
105
Embed
JAVA-BASED INTELLIGENT NETWORK MONITORING by Haifeng …
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
i
JAVA-BASED INTELLIGENT NETWORK MONITORING
by
Haifeng Xi
Thesis submitted to the Faculty of the Graduate School of the University of Maryland at College Park in partial fulfillment
of the requirements for the degree of Master of Science
2000
Advisory Committee:
Professor John S. Baras, Chair Professor Mark Austin Professor Nick Roussopoulos
ii
Copyright by
Haifeng Xi
2000
iii
ABSTRACT
Title of Thesis: JAVA-BASED INTELLIGENT NETWORK
MONITORING
Degree Candidate: Haifeng Xi
Degree and year: Master of Science, 2000
Thesis directed by: Professor John S. Baras Department of Electrical and Computer Engineering
The increasing complexity and importance of communication networks
have given rise to a steadily high demand for advanced network
management tools. Network Management in general consists of two
activities: monitoring and controlling. The monitoring part concerns
observing and analyzing the status and behavior of the managed networks,
and is therefore fundamental for network management. Unfortunately the
existing network monitoring paradigms have some drawbacks that prevent it
from satisfactory performance. One related problem is that these approaches
are characterized by high centralization which puts almost all the
computational burden on the management station. As a result, a huge
amount of raw data have to be transferred from network elements to the
central management station for further processing, causing heavy traffic,
manager overload and long operations delay. Another issue that becomes
increasingly noticeable is the absence of a mechanism for dynamic
extensions to agent functionality.
In this work we take advantage of some unique features of the Java
technology and present a framework for distributed and dynamic network
iv
monitoring. Specialized Java objects known as Intelligent Monitoring
Objects, are delegated to a Java-based Extensible Management Server
(JEMS), where they carry out encapsulated monitoring functionality upon
management information collected locally from the underlying network
device. We have built a proof-of-concept prototype system using the JEMS
architecture and validated its effectiveness and flexibility compared with the
traditional centralized network management systems.
v
ACKNOWLEDGEMENTS
I would like to express my deep regard for Dr. John S. Baras to whom I am extremely grateful. He allowed me the liberty of exploring my areas of interest, and the flexibility of writing the thesis off-campus. He provided me with the valuable opportunity to work on real-world problems with smart people from both his Center for Satellite and Hybrid Communication Networks and the industry.
I would like to thank Dr. Mark Austin and Dr. Nick Roussopoulos for consenting to be on my thesis committee while they are on very tight schedules.
I feel extremely indebted to Mr. Hongjun Li, my best friend, who was always available to discuss research issues, and to seek help on administrative stuffs while I am away from campus. I would also like to express my gratitude to Dr. George Mykoniatis for his advice and insights on object-oriented design.
This work was funded through NASA Cooperative Agreement NCC3-528, the Advanced Telecommunications/Information Distribution Research Program (ATIRP) Consortium sponsored by the U.S. Army Research Laboratory under the Federated Laboratory Program, Cooperative Agreement DAAL01-96-2-0002, National Science Foundation, Hughes Network Systems, and Northrop Grumman.
Most of all I would like to thank my wife without whom the completion of this work would not have been possible. She has been a source of continuous support and encouragement. Finally I would like to thank all my friends.
vi
TABLE OF CONTENTS
List of Tables v List of Figures vi Chapter 1 Introduction 1 Chapter Organization 2 1.1 Network Management and Monitoring 3 1.1.1 Components of Network Management System 3 1.1.2 Limitations of Current Systems 4 1.2 Contributions 5 1.3 Intelligent Network Monitoring 6 1.3.1 Advantages over Current Systems 7 1.4 Related Work 8 1.4.1 Management by Delegation 8 1.4.2 Mobile Agents 9 1.4.3 Web-based Network Management 10 1.5 Thesis Roadmap 11 Chapter 2 Network Monitoring 12 Chapter Organization 12 2.1 Network Management Systems Architecture 13 2.2 Simple Network Management Protocol 13 2.3 Network Management Functions 15 2.3.1 Network Management Functional Areas 16 2.3.2 Network Monitoring and Control 19 2.4 Network Monitoring Functions 20 2.4.1 Network Observation 21 2.4.2 Network Analysis 24 Chapter 3 Java-based Extensible Management Server 26 Chapter Organization 26 3.1 Remote Delegation Interface 27 3.1.1 Formal Definition 27 3.1.2 A Closer Look 29 3.2 Why Java? 32 3.2.1 The Language and Platform 33 3.2.2 Classes and Interfaces 35 3.2.3 Remote Method Invocation 37 3.2.4 Dynamic Class Loading 39 3.3 The JEMS Architecture 40
vii
3.3.1 Management Information Tree 41 3.3.2 Delegation Service Provider 46 3.3.3 Class Loader 48 3.3.4 MIB Accessor 49 Chapter 4 Intelligent Monitoring Objects 51 Chapter Organization 51 4.1 Design Analysis 52 4.2 The Monitor Class 53 4.2.1 Operands-Operator Paradigm 53 4.2.2 Object Initialization 56 4.2.3 Benefits of Our Design 60 4.3 Observers 62 4.4 Analyzers 64 Chapter 5 Prototype JEMS System 69 Chapter Organization 69 5.1 Prototype JEMS System 70 5.1.1 System Configuration 70 5.1.2 Managed Objects Deployment 73 5.1.3 System Startup Procedure 75 5.2 JEMS vs. Centralized Monitoring 76 5.2.1 Scalability 77 5.2.2 Performance 78 5.2.3 Extensibility 81 5.3 Conclusions 82 Chapter 6 Conclusions 83 Chapter Organization 83 6.1 Summary 84 6.1.1 Intelligent Network Monitoring 84 6.1.2 Intelligent Monitoring via JEMS 85 6.1.3 Intelligent Monitoring Validated 86 6.2 Future Work 86 6.2.1 User Authentication, Access Control and Privacy 86 6.2.2 Manager-side APIs and Tools 87 6.2.3 Intelligent Network Control 88 6.2.4 Autonomous Management Domain with Jini 88 6.2.5 Hierarchical Intelligent Network Management System 89 Appendices 90 References 93
viii
LIST OF TABLES
1 Indicator and Statistic Types 22 2 Remote Delegation Interface 29 3 Observer Contexts for different Operators 62 4 Initialization Parameters for the OpRatio Class 63 5 Initialization Parameters for the OpThreshold Class 66 6 Analyzer Context for the OpThreshold Class 67 7 Configuration of the Bytecode Server 71 8 Configuration of the Proxy Machine 72 9 Configuration of the JEMS Server 72 10 Configuration of the Management Station 72 11 Port-related SNMP Variables 90 12 Signaling-related SNMP Variables 91 13 Incoming Path-related SNMP Variables 91 14 Outgoing Path-related SNMP Variables 92
ix
LIST OF FIGURES
1 Components of typical Network Management Systems 3 2 IMOs delegated to JEMS 6 3 RDI Operations illustrated 29 4 Life-cycle of a delegated Object 31 5 The Java Platform 34 6 Rumbaugh Notation for depicting a Class 37 7 Rumbaugh Notation for depicting Inheritance 37 8 Remote Method Invocation 39 9 The JEMS Architecture 40 10 The MInfoTree Class 41 11 Inheritance Tree of Managed Objects 42 12 The Attribute Class 43 13 The SNMPAccessor Class 50 14 Inheritance Tree of the Monitor Class 53 15 Operands-Operator Paradigm 54 16 The abstract Operator Class 55 17 Threshold Comparing in Alarm Generation 64 18 The Inheritance Tree of Event Classes 65 19 The IfListenter Remote Interface 66 20 Prototype JEMS System 70
x
21 Inheritance Tree of INFO Classes 73 22 Containment Subtree of INFOs in the MIT 74
1
Chapter 1 Introduction This thesis introduces Java-based Intelligent Network Monitoring, an
efficient approach to monitoring networked systems using the proposed Java-based
extensible management server and various intelligent monitoring objects.
The increasing importance of communication networks has given rise to a
high demand for advanced network management. A network management system
handles problems related to the configurability, reliability, efficiency, security and
accountability of the managed distributed computing environments. It is concerned
with monitoring, analysis and control of network behaviors to ensure smooth
network operations. Accurate and effective monitoring is fundamental and critical
for network management, and is the focus of our work presented in this thesis.
In the mainstream network monitoring system, operational data are collected
by hardwired instrumentation in network elements and stored in Management
Information Bases (MIBs). For example, the MIB in an ATM switch can include
predefined counters and gauges about various traffic statistics for virtual circuits,
virtual paths and switch ports. This operational data is gathered, usually remotely
over a network, by a central Network Management Station (NMS) using a network
management protocol. The NMS presents the data to operations staff who are
responsible for monitoring, analyzing and controlling the network. This centralized
and static management paradigm does not scale for the size and complexity of
emerging heterogeneous broadband networks, neither does it adapt to unforeseen
management requirements. Therefore, new technologies are needed to decentralize
2
management functions in a dynamic way.
Intelligent monitoring is the conception brought forward in this thesis to
address the aforementioned problems. Management applications distribute or
delegate monitoring objects to Java-based extensible management servers (JEMS)
running at network elements. These objects will automate the monitoring and
analysis of corresponding network devices. For example, a delegated object can
monitor a MIB variable and compare its value against some pre-set thresholds to
detect potential operations problems. Monitoring intelligence and responsibilities
can thus be decentralized. Furthermore, when creating and manipulating a delegated
object, the JEMS takes advantage of Java’s dynamic class loading feature to
download code over the network, which results in a highly adaptable monitoring
server structure whose functionality can be dynamically extended.
Chapter Organization
Section 1.1 outlines network management/monitoring, and limitations of current
network monitoring systems.
Section 1.2 summarizes the contributions of this thesis.
Section 1.3 briefly introduces intelligent network monitoring and its benefits.
Section 1.4 looks into several research efforts that related to our work.
Section 1.5 presents a roadmap of the remaining chapters in this thesis.
3
1.1 Network Management and Monitoring
Network management systems handle problems related to the configurability,
reliability, efficiency, security and accountability of the managed distributed
computing environments, and are concerned with monitoring and control of network
behaviors to ensure smooth network operations. The network monitoring portion of
network management is concerned with observing and analyzing the status and
behavior of the managed network devices.
1.1.1 Components of Network Management System
A conventional network management system consists of two classes of
components: managers and element agents. Figure 1 depicts a diagram of the
Management Station
GUI
manager
. . . . . .
LAN
element agents
Network Elements
Figure 1: Components of typical Network Management Systems
4
organization of a typical network management system. Applications in the central
management station assume the manager role, and execute with a GUI for human
managers to perform certain monitoring functions. Element agents are server
processes running in each involved manageable network entity. These agents collect
device data, stores them in the Management Information Bases (MIBs), and support
a management protocol, e.g., Simple Network Management Protocol (SNMP) [1,2].
Manager applications retrieve data from element agents by sending corresponding
requests over the management protocol.
For example, the SNMP agent in an ATM switch collects information about
the signaling protocol, the traffic status of virtual circuits etc. and stores it in a
predefined MIB. A management application retrieves this data using the SNMP
GetRequest command, processes and analyzes them, and then displays the result
graphically.
1.1.2 Limitations of Current Systems
Current network monitoring/management systems favor a centralized
framework where most of the monitoring intelligence and computation burdens are
allocated to the manager applications executing at the central station. This
establishes several barriers to effective network monitoring, especially for emerging
high-speed networks. Several major problems are outlined in the following
paragraphs.
Given the centralized allocation of management responsibilities, all the
monitoring interactions and processing have to go through the management station,
5
which becomes the bottleneck and single point of failure. This leads to a system that
hardly scales up to large and complex networks.
Since manager applications can only interact with the network elements
through low-level general-purpose interfaces, any non-trivial monitoring task
requires huge volume of “raw” SNMP variables being transferred to the management
station, which is known as the micro-management problem. Micro-management
results in high communication overheads, and significant operation delays if the
managed network is wireless or satellite-based.
The set of services offered by the element agents is fixed, strictly defined by
standards, and is accessible through interfaces that are statically defined and
implemented. This service set cannot be modified or extended on the fly without the
recompilation, reinstallation, and reinstantiation of the server process. This rigid and
static agent structure hinders the development of effective monitoring systems in two
ways: (1) improvement of the agent usually involves high-cost activities and may
harm system availability; (2) it does not provide any mechanism to differentiate
between and take advantage of the capabilities of different types of devices.
1.2 Contributions
The major contributions presented in this thesis include:
Java-based Extensible Management Server (JEMS). A model that supports
intelligent, i.e., distributed and dynamic, network monitoring. JEMS runs as a server
process in the managed network element and consists of: (1) the Remote Delegation
Interface (RDI) through which management applications can remotely delegate Java
6
objects, exchange information with these objects and control their execution; (2) a
runtime environment that implements the RDI.
Intelligent Monitoring Objects (IMOs). Specialized Java objects that perform
network monitoring functions. IMOs are distributed to JEMS at the network devices
where the managed resources are located. We have categorized common monitoring
functions and encapsulated them into corresponding IMOs. IMOs are implemented
in such a way that they work closely with the underlying JEMS to provide for an
intelligent monitoring system.
1.3 Intelligent Network Monitoring
The approach of intelligent network monitoring is to dynamically distribute
monitoring functionality, in the form of IMOs, to JEMS at the devices where the
managed resources are located. Specifically speaking, intelligent monitoring means
two things:
First, manager applications can distribute monitoring intelligence to the
managed network element. Instead of bringing data from the devices to the
central station, parts of the monitoring applications themselves, encapsulated in
IMOs remote manager
RD
I
J E M S
managed device
Figure 2: IMOs delegated to JEMS
7
various IMOs, are actually running in the managed devices (Figure 2). The manager
host and the network as a whole can then be relieved from the bottleneck and the
micro-management problems.
Secondly, the network element’s agent functionality can be dynamically
modified or extended. Through the remote delegation interface (RDI), manager
applications can choose to distribute/delete whatever IMOs to/from the device, at
whatever time they like. Furthermore, the code of a Java class need not be available
beforehand to the JEMS when a corresponding object is instantiated upon a
delegation request from the manager. JEMS can download class code over the
network and link it to the runtime system on demand, which makes it truly
dynamically extensible.
1.3.1 Advantages over Current Systems
Intelligent network monitoring allows for dynamic extensions to monitoring
functionality as the network evolves. For instance, if a new monitoring requirement
is identified after the system is up and running, we can create a corresponding IMO
that encapsulates the functionality and delegate it to the JEMS, without having to
bring the system offline.
By recognizing and taking advantage of the difference in resource availability
of various network devices, manager applications can have flexible and efficient
usage of these resources. For devices with a lot of resources (e.g., memory and CPU
processing power), the manager can delegate large numbers of IMOs to them,
making full use of local computing to reduce management traffic overhead and
8
delay. This is a great advantage over traditional static systems, where the size and
funtionality of network agents are fixed once they start running, and extra device
resources can not be used to improve the efficiency of network monitoring. For
devices with relatively few resources, the manager can always switch back to the
traditional polling-based paradigm.
Similarly, remote managers can dynamically adapt to changes in the
availability of network and computing resources. For example, when the network is
overloaded, manager applications can encapsulate related monitoring functions in
some IMOs that are distributed to the JEMS and analyze data locally at the devices,
relieving the network from the traffic overloading that frequent polling would
otherwise have worsened.
1.4 Related Work
There are several research efforts that are related to our work in one way or
another. We will try to identify the strength and weakness of each of them and to
spell out their distinctions from our system.
1.4.1 Management by Delegation
Management by Delegation (MbD) [19] is one of the earliest efforts towards
decentralization and increased flexibility of management functionality, and is
probably the most successful one. Its management architecture includes a
management protocol, device agents, and an elastic process run-time support on each
device. Instead of exchanging basic client-server messages, the management station
can specify a task by packing into a program a set of agent commands and sending it
9
to the devices involved, thus delegating to them the actual execution of the task.
Such execution is completely asynchronous, enabling the management station to
perform other tasks in the mean time and introducing a higher degree of parallelism
in the whole management architecture. MbD greatly influenced later research and
exploration along this direction [12,13,14].
However, there are two disadvantages with MbD that probably have affected
its application: (1) Since the work was done before 1996, when the Java platform
was not so widely recognized and deployed by industry as it is today, the proof-of-
concept MbD system was implemented with a proprietary server environment
written in the C programming language – we hardly see any working systems that
are built upon this proprietary environment. (2) The MbD server environment is so
comprehensive and complicated that it can turn out to be an “overkill” in most real-
world applications.
Still, we must give credit to MbD because it can be considered a precursor of
the ideas discussed here. The major difference is that we have adopted the standard
Java platform and, from the very beginning, aimed to build a portable, simple, yet
powerful framework that can be easily understood, implemented and enhanced.
Because of the wide installation base and intrinsic portability of the Java platform,
we expect to see quick adoption of our system (or a derived version of it) in some
relevant real-world applications.
1.4.2 Mobile Agents
Using mobile agents in decentralized and intelligent network management
10
[13] is a great leap from client-server based management pattern. The proposal is
that an intelligent agent containing management code can traverse in the managed
network from node to node, autonomously retaining the state of its computation
whenever it moved to a different node.
There are two potential problems with this method: (1) It proposed a change
to network management paradigm that is so radical that even the authors themselves
realized that “further validation with quantitative data” would be necessary to prove
its effectiveness. (2) Their proposed agents were written in specialized agent-
oriented scripting languages such as Telescript [22] and Agent Tcl [23], which are
not available or supported on many platforms, posing serious portability problems.
In contrast, our system still retains a client-server architecture, and assumes a
management server in each device concerned. Therefore, while IMOs provide
similar intelligent monitoring functions as their mobile agent counterparts, their
behaviors are much easier to understand and anticipate, making them more
straightforward to integrate and co-exist with traditional systems.
1.4.3 Web-based Network Management
We are by no means the first people thinking of using Java technology in
network management [14,15,16]. But so far we have only seen efforts focused on
so-called Web-based Network Management, which addresses the problem of
integrating manager applications with the Web using Java applets. This is a well-
justified idea that attempts to provide a cost effective way of providing uniform
management services to managers and potential customers through such common
11
client-side interface as Web browsers.
Instead, we have used Java for a totally different purpose, which is not to
facilitate client-side presentation or Web integration, but to use Java’s native support
for distributed computing, remote class downloading and object serialization to
implement dynamic and intelligent network monitoring. However, it makes perfect
sense to consider including Web-based front-ends into our future enhanced systems.
1.5 Thesis Roadmap
We will begin each chapter with a brief discussion of the main challenges and
solutions presented in the chapter, followed by an outline of the organization of
sections in the chapter.
Chapter 2 introduces network management and network monitoring. It
illustrates the structure of conventional systems and points out its limitations. It also
summarizes the most commonly used monitoring functions.
Chapter 3 presents the JEMS architecture. It defines the RDI, explains why
Java is chosen as the foundation technology, and then examines the design and
implementation of the JEMS.
Chapter 4 describes intelligent monitoring objects. It explains the design of
different types of objects, and shows, via examples, how they work within the JEMS
framework to provide for an intelligent monitoring system.
Chapter 5 evaluates intelligent monitoring and demonstrates its merits. It
contrasts intelligent monitoring with centralized monitoring approaches within some
simple but typical scenarios.
12
Chapter 6 draws conclusions and points out several future work directions.
13
Chapter 2 Network Monitoring
The main goal of network management systems is to ensure the quality of
services (QoS) that the network provides. To achieve this, network managers must
monitor and control the connected elements in the network.
The network monitoring portion of network management is concerned with
observing and analyzing the status and behavior of the network devices that make up
the configuration to be managed. Accurate and effective monitoring is therefore
fundamental and critical for the implementation of various network management
functions.
Chapter Organization
Section 2.1 outlines the architecture of current network management systems.
Section 2.2 examines SNMP, the dominating network management protocol.
its location in the tree structure. This name is given when the object is initially
created and remains immutable throughout its lifetime. “enabled” is a flag variable
used to control and indicate whether the the managed object is activated or not.
MO has two very important subclasses: MgmtInfo and Monitor, which
represent physical/logical network resources and network monitoring functions
respectively.
Before looking into details of these two classes, we would like to point out
that managed object classes are formally specified using the Guidelines for the
Definition of Managed Objects (GDMO) [1], which is an object-oriented information
specification language with management orientation. However, since GDMO
definitions are text files that are difficult to read and interpret, we have taken
advantage of Rumbaugh notation to visualize class specifications instead of bringing
out GDMO files directly, and will continue doing so throughout the thesis. It is also
relieving to know that there have been successful research efforts to translate GDMO
definitions to Java objects [6], which provides automated tools to help with Java
implementation of GDMO-specified MOs.
The MgmtInfo Class
All the INFOs are instantiated from proper subclasses of the MgmtInfo class,
an object-oriented modeling of network management information. The values of
interesting MIB variables are obtained through the MIB accessor and represented by
corresponding attributes in a certain INFO. For example, for every incoming virtual
path in any active port of a Fore ATM switch, the SNMP agent keeps track of the
46
values of a collection of MIB counter variables such as pathUsedBandwidth,
pathCells, pathUptime, and pathRejectedCells, just to name a few. Therefore, an
INFO that models this virtual path will have in its attribute hashtable a list of
attribute objects that correspond to these MIB variables. These attributes are added
to the hashtable by invoking the addAttr method in the INFO’s constructor function:
// inheritance from MgmtInfo class InVirtualPath extends MgmtInfo {
// constructor InVirtualPath (String name) {
addAttr( new AttrInt(“pathUsedBandwidth”) ); addAttr( new AttrInt(“pathCells”) ); addAttr( new AttrInt(“pathRejectedCells”) ); . . . // assign the name to this object this.name = name;
} . . .
} Therefore, creation of an incoming-virtual-path INFO looks like this:
InVirtualPath p2 = new InVirtualPath(“system:port.1:inPath.2”); mit.addObject( p2.getName(), p2 ); The first Java statement instantiates a new INFO of the type InVirtualPath
(p2) and gives it a unique name system:port.1:inPath.2. The second statement inserts
p2 into the MIT at the desired location implied by its name.
All the INFOs of interest to network monitoring are instantiated and added to
the MIT automatically when the JEMS starts up; they use the MIB accessor to
periodically retrieve data from the underlying device agent, e.g., an SNMP agent,
and use the acquired data to update the values of their attributes.
47
The Monitor Class
IMOs are instantiated from corresponding subclasses of the Monitor class.
They are delegated to the JEMS by remote manager applications, and perform
network monitoring functions by processing management information retrieved
locally from relevant INFOs and/or other IMOs. Please refer to Chapter 4 for a
dedicated discussion of the Monitor class and various IMOs instantiated from it.
3.3.2 Delegation Service Provider
The Delegation Service Provider (DSP) is an RMI server object instantiated
from the DSProvider class, an implementation of the Java remote interface IfRDI
which is actually the RDI specified in the Java language. The DSProvider class
implements the IfRDI methods (or RDI operations) as follows:
doOperation() – Perform the desired monitoring operation based on the valid
operands and operation parameters; specific to operator implementation.
Any IMO has, in its attribute list, an attribute named operator whose value is
the class name of the Operator to be used by the IMO. This attribute is not read-
only, and whenever it is set to a new value, a corresponding Operator object will be
instantiated using the generic class loader.
Also related to the Operator object is the attribute named opParams. It
represents a hashtable of parameters, in name/value pairs, that are interpreted by the
Operator to adjust its operation. The usage of opParams will be discussed in more
detail later in this chapter where most appropriate.
The result/listener Attribute
For an Observer, the output from the Operator object is stored in an attribute
named result. This attribute can be retrieved by remote managers, or even taken as
an operand by other IMOs. An Analyzer, instead, has a listener attribute whose
value is the name of a remote listener object; the Operator object invokes a method
on the stub of this remote listener to send an alarm back to the manager whenever an
abnormal condition is detected. A better study of these two attributes will be given
in Section 4.3 and 4.4 repectively.
4.2.2 Object Initialization
The correct and efficient initialization of IMOs is an integral part of the
overall design, therefore we are devoting a separate subsection to this topic. There
58
are two steps involved here: invocation of the object’s constructor and initialize
method by the create operation of the DSP (review Section 3.3.2).
The Constructor Method
A IMO’s constructor is automatically invoked immediately after the object is
instantiated by the DSP. What the constructor does is to correctly set up the object’s
attribute list by adding appropriate attributes into the hashtable, and to initialize its
stub_DSP property (see Figure 14, 15). To make this process clearer, we list in the
following paragraphs partial codes of the related constructor methods, with easy-to-
understand comments.
// the abstract Monitor class abstract class Monitor extends MO {
// constructor Monitor() {
// find the DSP on the localhost and store its stub // object into the variable “stub_DSP” stub_DSP = (IfRDI) Naming.lookup(“//localhost/DSP”); // add the read-only “operands” attribute addAttr(new Attribute(“operands”)); // add the read-write “operator” attribute addAttr(new Attribute(“operator”, false)); // add the read-write “opParams” attribute addAttr(new Attribute(“opParams”, false)); // add the read-write “interval” attribute // refer to Section 4.3 and 4.4 for details addAttr(new Attribute(“interval”, false));
} . . . }
// the Observer class class Observer extends Monitor {
// constructor Observer() { // call the constructor of the parent class – Monitor
super();
59
// add the read-only “result” attribute addAttr(new Attribute(“result”));
} . . .
}
// the Analyzer class class Analyzer extends Monitor {
// constructor Analyzer() {
// call the parent class’ constructor super(); // add the read-write “listener” attribute addAttr(new Attribute(“listener”, false));
} . . .
}
The initialize Method
An IMO’s initialize method is called immediately after the constructor, and it
aims at correctly initializing the values of the those attributes added to the attribute
list by the constructor.
// the abstract Monitor class abstract class Monitor extends MO {
// initialize “operands” with the corresponding value in // the hashtable “params”, which is passed as the last // argument to the DSP’s create() method (Section 3.3.2) updateAttr( “operands”, params.get(“operands”) ); updateAttr( “opParams”, params.get(“opParams”) ); updateAttr( “interval”, params.get(“interval”) ); updateAttr( “operator”, params.get(“operator”) );
} . . .
} // the Observer class class Observer externds Monitor {
// assign the value to “operator” findAttr(“operator”).setValue((String)value); // load the operator class Class c = GenericLoader.loadClass((String)value); // instantiate the Operator object op = (Operator) (c.newInstance()); // set the Operator’s owner to be this IMO op.setOwner(this); // check the context of this IMO op.checkContext(); if (findAttr(“interval”).getValue() > 0) {
// create and start a thread that calls // op.doOperation() periodically
} }
4.2.3 Benefits of Our Design
The operands/operator paradigm has the following benefits.
Operator Reusability
A specific monitoring function can be abstracted and represented by a proper
subclass of the Operator class, and then be embedded into different IMOs in the form
of the operator attribute. In this way, we can bind one operator with many different
sets of operands to form different IMO instances.
On-line Change and Extension
Flexible and powerful on-line extension to IMOs and the underlying JEMS
62
can be achieved. Specifically speaking, there are three levels of on-line changes that
can be made, with increasing degree of extensibility.
(1) Parameter Customization. Because the opParams is a read-write attribute,
remote managers can modify its value via RDI calls, thus dynamically changing the
manner in which the Operator object works.
(2) Operator Re-assignment. Since the Operator itself is associated to the
read-write operator attribute, managers can change a IMO’s monitoring behavior
even more by assigning a new, hopefully more powerful, Operator to it. Note that
the Operator object is instantiated by way of the generic class loader which can
download Java classes from the bytecode server, the JEMS does not need to have
any prior knowledge or storage of the new operator class. Therefore, the extension
takes place in a completely on-line and dynamic fashion.
(3) New Monitor Types. The most significant benefit comes from both the
operands/operator paradigm and the overall JEMS design, i.e., it is quite easy and
convenient to write new Monitor subclasses and to delegate their instances to the
JEMS.
Independent Manager-side Development
To write and compile the Monitor class and its subclasses, we need:
Interfaces/classes: IfRDI, IfListener, Operator, Attribute To write and compile the Operator class and its subclasses, we need:
Interfaces/classes: IfRDI, IfListener, Monitor, Attribute To deploy/delegate IMOs to the JEMS, we also need to have access to related
63
Operator implementations, IfListener implementations, and absolute attribute names
from available INFOs.
Except for IfRDI and absolute attribute names, all of the above-mentioned
components are written and available at the manager side. IfRDI is the remote
interface to the JEMS and, according to the purpose and nature of an interface,
should remain independent of its implementation. As for the absolute attribute
names, as long as the managed device is determined and a mapping from its MIB to
corresponding INFOs is done, the available attribute names are fixed and become
irrelevant to the JEMS implementation. Therefore, our design allows for
independent manager-side IMO programming and deployment.
4.3 Observers
Observers are IMOs instantiated from the Observer class. They perform the
observation part of network monitoring. An Observer is characterized by the
Operator object in it, therefore we will center our discussion around related Operator
objects. The following table lists the correct context for different Operators:
Let’s take a look at how a ratio-oriented indicator is implemented by creating
Context Observer type
Operator class interval (ms) operands
number type opParams
rate OpRate ≥ 1 = 1 Integer or Float n/a
ratio OpRatio ≥ 1 ≥ 2 Integer or Float n/a
average OpAvg = 1 variance OpVar = 1 covariance OpCovar
≥ 1 = 2
Integer or Float
sampleSize ≥ 2
Table 3: Observer Contexts for different Operators
64
an Observer using the OpRatio class. Other indicators can be implemented similarly.
The manager creates an initialization parameter list:
The manager delegates an Observer to the JEMS (at rrocoto.cshcn.umd.edu): IfRDI jems = (IfRDI)Naming.lookup(“//rrocoto.cshcn.umd.edu/DSP”); jems.create(“jems.monitor.Observer”, “system:observer#58”, initParams); The DSP instantiates an Observer, initializes its attribute list using the
provided parameters, and adds the Observer into the MIT. When the operator
attribute is being initialized, the Operator checks the owning Observer against the
ratio context listed in Table 3 to make sure that the Observer has a compatible
context for the Operator to correctly perform its function in.
The monitoring funtion of this Observer, i.e., to calculate the (cell rejection)
ratio based on the two variables specified in the operands attribute, is implemented
// get the value of the “operands” by calling: // owner.findAttr(“operands”); // parse the names of the operands and get the attribute // names and object names separately, i.e.: // attrName1 = “pathRejectionCells” // objName1 = “system:port.1:inPath.2” // attrName2 = “pathCells” // objName2 = “system:port.1:inPath.2”
Table 4: Initialization Parameters for the OpRatio Class
65
// get the attribute values via two RDI calls: // curr_1 = (owner.stub_DSP).get(objName1, attrName1); // curr_2 = (owner.stub_DSP).get(objName2, attrName2); // calculate the difference from the latest values: // delta_1 = curr_1 – last_1; // delta_2 = curr_2 – last_2; // calculate the ratio by: // ratio = delta_1 / (delta_1 + delta_2); // store the ratio to the “result” attribute: // owner.findAttr(“result”).setValue(ratio); // last_1 = curr_1; // last_2 = curr_2;
}
4.4 Analyzers
Analyzers are IMOs instantiated from the Analyzer class. They perform the
analysis part of network monitoring as was defined in Section 2.3.2. In this thesis
work, we only look into the simplest form of Analyzer, which compares the value of
the monitored indicator (its operand) with a set of pre-specified thresholds, and
generates corresponding alarms when certain thresholds are crossed. The
comparison is done by the Analyzer’s Operator object which is instantiated from the
OpThreshold class. Other types of operator classes can be developed similarly.
Figure 17 shows the threshold comparing model used by an Analyzer. There
high alarm cleared
time
high gauge
high-clear
low gauge
low-clear
high alarm
low alarm
low alarm cleared
Figure 17: Threshold Comparing in Alarm Generation
66
are two levels of thresholds: high and low, and in each level there are two gauges
defined. For the high-level thresholds, when the value of the monitored indicator
exceeds the high gauge, a “high alarm” is fired and remains valid until the value
drops below the high-clear gauge, when a “high alarm cleared” message will be
emitted. Between the firing of an alarm and its clearance message, no other alarms
should be fired. The “low alarm” and its associated “low alarm cleared” message
work in a similar way. An even more generic model would allow for multiple levels
of thresholds.
Alarms and their clearance messages are represented by objects instantiated
from the Alarm and AlarmCleared classes respectively. Both these classes are
subclasses of the Event class (Figure 18). Each generated event object is
automatically assigned a unique ID, and contains properties that have the
following meaning:
origin name of the IMO that generates this event desc brief description of the nature of this event time time stamp marking when the event was created data detailed information about the agent-side situations that triggered the
The manager delegates an Analyzer to the JEMS (at rrocoto.cshcn.umd.edu):
IfRDI jems = (IfRDI)Naming.lookup(“//rrocoto.cshcn.umd.edu/DSP”); jems.create(“jems.monitor.Analyzer”, “system:analyzer#16”, initParams); The DSP instantiates an Analyzer, initializes its attribute list using the
interface IfListener
receive(Event evt)
Figure 19: The IfListenter Remote Interface
Table 5: Initialization Parameters for the OpThreshold Class
68
provided parameters, and adds the Analyzer into the MIT. When the DSP initializes
the listener attribute, in addition to the actual assignment of the URL to the attribute,
the helper method updateListener also downloads a copy of the associated remote
stub object and keeps it in the Analyzer’s lstner property.
// assign the value to “listener” findAttr(“listener”).setValue(value); // locates the remote stub of the “EventListener” lstner = (IfListener)Naming.lookup((String)value);
} When the operator attribute is being initialized, the Operator checks the
owning Analyzer against the context shown in Table 6 to make sure that the
Analyzer has a compatible context for the Operator to correctly perform its function:
Context Analyzer Type
Operator class interval operands# type opParams listener
Thre
shol
d C
heck
ing
OpT
hres
hold
≥ 1 = 1 Integer
or Float
high_gauge > high_clear > low_clear > low_gauge
(not
nul
l)
The monitoring funtion of this Analyzer is accomplished by the Operator’s
// get the value of the “operands” by calling: // owner.findAttr(“operands”); // parse the name of the operand and get the attribute name // and object name separately, i.e.: // attrName = “result” // objName = “system:observer#58”
Table 6: Analyzer Context for the OpThreshold Class
69
// get the value of the attribute via an RDI call: // value = (owner.stub_DSP).get(objName, attrName); // get the value of the “opParams” and the gauges // contained in it: // owner.findAttr(“opParams”); . . . // use the threshold model shown in Figure 4.12 and // compare “value” with different gauges to decide if // an Alarm or AlarmCleared object should be created; // if so, create one and initialize it accordingly // alarm = new Alarm(); // alarm.setID(); alarm.setOrigin(owner.getName()); // alarm.setDescription(“…”); . . . // send the alarm back to the manager: // lstner.receive(alarm);
} The remote listener object acts as an event dispatcher at the manager side and
re-directs the received events to their proper handlers.
70
Chapter 5 Prototype JEMS System
Based on the JEMS architecture proposed in previous chapters, we have built
a proof-of-concept prototype system, and done some experiment and comparison
against the centralized monitoring system. The results have verified the advantages
of intelligent monitoring over traditional network monitoring schemes.
Chapter Organization
Section 5.1 introduces the configuration and implementation of the prototype
system.
Section 5.2 compares the prototype system with the traditional central monitoring
system through some simple experiment and analysis.
Section 5.3 draws approriate conclusions.
71
5.1 Prototype JEMS System
The prototype JEMS system (Figure 20) is introduced in the following
sections: system configuration in Section 5.1.1, objects deployment in Section 5.1.2,
and system startup procedure in Section 5.1.3.
5.1.1 System Configuration
Bytecode Server and RMI Registry Service
Actually, the bytecode server and the RMI registry service can be running on
any IP host on the Internet. We happen to choose the following setup, shown in
Table 7, for them.
Figure 20: Prototype JEMS System
.cshcn.umd.edu
Internet
roccoto (JEMS server)
ux7 (bytecode server)
.sp.cs.cmu.edu .isr.umd.edu
hera (management station)
bigbang (ATM switch)
72
Machine’s DNS name ux7.sp.cs.cmu.edu Hardware platform Sun Workstation Operating System Solaris 2.5 Java platform JDK 1.1.5 for Solaris URL of RMI registry rmi://ux7.sp.cs.cmu.edu:5001/ URL of HTTP server http://ux7.sp.cs.cmu.edu:2001/
Classes served jems.monitor.* jems.operator.*
jems.monitor is the name of the Java package that contains all the Monitor
classes, i.e., Monitor, Observer and Analyzer. jems.operator is the name of the Java
package that contains all the Operator classes, i.e., OpRate, OpRatio, OpAvg,
OpVar, OpCovar and OpThreshold.
Managed Device and JEMS Server
The managed device is a Fore ATM switch located in the Center for Satellite
and Hybrid Communication Networks (CSHCN). The switch is connected to the
CSHCN LAN and has the DNS name bigbang.cshcn.umd.edu. It has a built-in
SNMP agent that serves requests for variables defined in two MIB files: RFC1213
for IP management, and Fore-Switch-MIB for ATM-switch-specific management.
According to the proposed architecture, a JEMS server should be running in
the switch for its intelligent monitoring. However, since there is no JVM ported to
the Fore ATM switch yet, we have to run a JEMS server in a workstation which is
equipped with a JVM and acts as a proxy for the ATM switch. The configuration of
this proxy machine is listed below in Table 8.
Table 7: Configuration of the Bytecode Server
73
Machine’s DNS name rrocoto.cshcn.umd.edu Hardware platform HP Workstation Operating System HP UX Java platform JDK 1.1.6 for Solaris
The configuration of the JEMS server in the proxy machine is listed below:
MIT naming convention as specified in Section 3.3.1
Name of DSP’s stub object registered in the RMI registry
DSP (i.e., remote managers use the URL rmi://ux7.sp.cs.cmu.edu:5001/DSP to look up DSP’s stub object)
SNMP agent accessed by the SNMP Accessor
bigbang.cshcn.umd.edu
Management Station
Any IP host on the Internet can play the role of a management station. We
have randomly picked a Sun workstation in ISR’s SEIL lab with the following setup:
Machine’s DNS name hera.isr.umd.edu Hardware platform Sun Workstation Operating System Solaris 2.5 Java platform JDK 1.1.6 for Solaris
Name of event listener’s stub object registered in the RMI registry
EventListener (i.e., Analyzers in the JEMS use the URL rmi://ux7.sp.cs.cmu.edu:5001/EventListener to look up the event listener’s stub)
Table 8: Configuration of the Proxy Machine
Table 9: Configuration of the JEMS Server
Table 10: Configuration of the Management Station
74
5.1.2 Managed Objects Deployment
Information Objects
Since the major interest of this research is in performance monitoring, we did
not map the whole Fore-Switch-MIB to INFOs. Instead, we have selected a list of
SNMP variables related to the performance of the ATM switch (see Appendices),
and mapped them to various INFOs. Specifically, all port-related variables (Table
11) are mapped to corresponding attributes in the Port class, all signaling-related
variables (Table 12) are mapped to corresponding attributes in the SigPath class, all
incoming path-related variables (Table 13) are mapped to corresponding attributes in
the InVirtualPath class, and all outgoing path-related variables (Table 14) are
mapped to corresponding attributes in the OutVirtualPath class. The inheritance tree
of these classes is shown in Figure 21, and their associated containment subtree in
the MIT is shown in Figure 22.
MO MgmtInfo
Port
SigPath
InVirtualPath
OutVirtualPath
Figure 21: Inheritance Tree of INFO Classes
75
Now, the motivation and benefits of introducing a layer of INFOs between
IMOs and underlying device agents are easy to explain and understand.
INFOs present a better view of the available management information. Not
all the variables in the MIB are useful for network management, actually only a
small fraction of them prove to be helpful for performance monitoring. To make
things worse, these variables are often scattered in different MIB tables, which
makes their direct access very difficult and confusing. By mapping only those
useful and functionally related variables from different locations in the MIB to
attributes in a few compact INFOs, we hide the complexity of direct MIB access
from end users (e.g. IMOs), and instead provide them with an efficient, focused and
simpler access interface.
INFOs help with easy programming of reusable IMOs. Instead of talking
directly to the device agent, IMOs acquire information from various INFOs by
invoking proper RDI operations. Since MIB access details and complexity are
encapsulated in the implementation of INFOs and the MIB accessor, IMOs are
system
port.1 port.2 . . . port.n
sigPath.1 inPath.1 inPath.k . . .
IMOs
outPath.1 . . . outPath.k
Figure 22: Containment Subtree of INFOs in the MIT
76
independent of agent types and are therefore reusable. For example, if we have an
ATM switch with a CMIP agent, all that needs to be done is to write a CMIP
accessor and change the implementation of INFOs so that they update their attribute
values by way of the CMIP accessor.
Monitoring Objects
Two Java packages, namely, jems.monitor.* and jems.operator.*, are
deployed to the bytecode server. When the remote manager attempts to delegate a
IMO to the JEMS server, it invokes the RDI create method with three arguments:
class name, object name and initialization parameter list. The Monitor class
specified by the class name is downloaded from the bytecode server to the JEMS
server, a IMO is then instantiated from the class, and gets initialized using the
parameters provided.
5.1.3. System Startup Procedure
The prototype system starts up in the following sequential steps:
Bytecode Server and RMI Registry Startup
The HTTP server is started on port 2001, with its document root pointing to
where the two Java packages are installed. Monitor and Operator classes are now
ready for download from the URL http://ux7.sp.cs.cmu.edu:2001/.
The RMI registry is started on port 5001.
JEMS Server Startup
The SNMP Accessor is created and initialized. It loads the Fore-Switch-MIB
file, sets the SNMP protocol version to v1, and sets the SNMP agent’s Internet
77
address to bigbang.cshcn.umd.edu.
The Management Information Tree is created and initialized. First, the
subtree shown in Figure 22 is automatically added into it; during this process, switch
information is obtained via the SNMP Accessor to decide which ports are active and
what virtual paths there are in each active ports, so that the subtree can be built to
reflect the working condition of the ATM switch. Secondly, special-purpose objects
are initialized and added into the MIT; for example, the classLoaderConfig object
(see Section 3.3.3) will be added to the MIT with its attribute urls set to
http://ux7.sp.cs.cmu.edu:2001/.
The Class Loader is created and initialized.
The Delegation Service Provider is created; its stub object is registered in the
RMI registry under the name DSP, and therefore becomes available for lookup and
download at the URL rmi://ux7.sp.cs.cmu.edu:5001/DSP.
Management Station Startup
A manager application starts up and immediately registers the stub object of
an event listener to the RMI registry under the name EventListener. Now the startup
process of the whole system is complete, and the manager application can start
delegating Observers, Analyzers and possibly other types of IMOs to the JEMS
server.
5.2 JEMS vs. Centralized Monitoring
This section compares the intelligent monitoring paradigm of JEMS and
those of centralized SNMP-based approaches. It examines some typical performance
78
issues involved in network monitoring systems. We compare the performance of our
prototype system and applications using SNMP. The comparisons, which focus on
scalability, performance, and online extensibility, are illustrated by simple examples
or analysis.
5.2.1 Scalability
Polling-based network management systems do not scale up to large
networks, because the interaction of the central management station with SNMP
agents has two patterns: (1) it involves the management station into a huge amount
of communication, and (2) it concentrates most processing into the central station. A
network system becomes unmanageable when there is an increase in the number of
managed devices or when there is an increase in the number of variables to be
monitored.
Consider an SNMP-based application executing on hera, responsible for
performance monitoring of the ATM switch bigbang. To undertake any non-trivial
monitoring task, be it observation or analysis, the application needs to keep an array
of indicators – rates, ratios and statistics – based upon the variables listed in
Appendix. To provide a given level of measurement precision, the values of these
indicators have to be updated at a reasonable frequency, say, every T seconds. If we
assume the time required for a single polling request is tP, then the maximum number
of variables that can be handled by hera is bound by PtTN /≤ . Monitoring an
operating broadband ATM switch usually requires a high precision or a short T; and
if the management station and managed device communicate over a Wide Area
79
Network (implying a large delay tP), then the maximum number of variables or
SNMP devices that can be handled by one central management station could drop
one to two orders of magnitude. This poses a serious scalability problem. A smiliar
example is discussed in much more detail in [26].
Now, even if the management station is so powerful as to be able to handle
all the devices, the polling scheme is still very inefficient, since the network traffic
caused by the polling behavior is a constant independent of the actual frequency of
information access or alarm generation. For example, in order to promptly detect a
rare yet important alarm situation, a high polling frequency needs to be maintained,
even though most of the polling requests will prove to be irrelevant.
Contrary to what a traditional polling-based system does, a JEMS-based
system delegates intelligent monitoring objects to network devices, so that various
indicators are maintained (and network analysis is performed) right in the devices or
in a local proxy as in our prototype system. Manager-to-agent traffic occurs only
when the central station has the actual need for information, or when alarms are fired
upon detection of associated abnormal situations. This significantly reduces the
unnecessary management traffic and the load on central stations, thus reducing the
scalability barrier.
5.2.2 Performance
We illustrate the performance characteristics of JEMS by comparing the
performance of a monitoring application using SNMP to that of an application that
has the same functionality but was implemented on our prototype system.
80
Consider an SNMP-based monitoring application that involves n MIB
variables. The cost function of the overall response time of this application can be
approximated by
MIBCDSNMP TmanagerTGetSNMPTnT ++⋅= )()_(
TD(SNMP_Get) represents the delay of each SNMP Get request between the
centralized station and the SNMP agent, TC(manager) represents the computation
time of the application at the management station, and TMIB represents the total time
spent by the SNMP agent in MIB searching during one invocation of the application.
TD(SNMP_Get) depends on the round-trip transmission delay of the SNMP Get/Get-
Response message pair, plus message processing time at both ends.
Consider a JEMS implementation of the same application. The functionality
of the monitoring application can be encapsulated into an Operator object, which is
in turn bound with a IMO delegated to the managed device, and a get operation on
the IMO’s result attribute would return the computation result. After the IMO is
delegated and ready to serve, the typical response time cost function for one get
1996-1999. [12] G. Pavlou et al., “Distributed intelligent monitoring and reporting facilities,”
Distributed Systems Engineering, vol.3, no.2, pp. 124-135. [13] M. Baldi et al., “Exploiting code mobility in decentralized and flexible network
management,” Proceedings of the 1st International Workshop on Mobile Agents (MA’97), pp. 13-26.
95
[14] N. Anerousis, “An information model for generating computed views of management information,” Proceedings of the 9th IFIP/IEEE International Workshop on Distributed Systems: Operations and Management, Newark, DE, October 1998.
[15] N. Anerousis, “An architecture for building scalable, Web-based management
services,” Journal of Network and Systems Management, vol.7, no.1, pp. 73-104.
[16] M. Leppinen et al., “Java- and CORBA-based network management,”
Computer, June 1997, vol.30, no.6, pp. 83-87. [17] Sun Microsystems, “Jini Technology,” http://www.sun.com/jini/, 1998-1999. [18] IETF, “Management Information Base for Network Management of TCP/IP-
based Internets: MIB-II,” ftp://ftp.isi.edu/in-notes/rfc1213.txt/, March 1991. [19] G. Goldszmidt and Y. Yemini, “Distributed management by delegation,”
Proceedings of the 15th International Conference on Distributed Computing, June 1995.
[20] E. H. Mamdani, R. Smith and J. Callaghan, The Management of Telecom-
munication Networks, Ellis Horwood Limited, 1993. [21] S. Yemini, E. Moses, Y. Yemini and D. Ohsie, High speed and robust event
correlation, IEEE Communications Magazine, May 1996. [22] J. E. White, Mobile agents, Software Agents, MIT Press, 1996. [23] R. S. Gray, Agent Tcl: a transportable agent system, Proceedings of the
CIKM’95 Workshop on Intelligent Information Agents. [24] Sun Microsystems, “Java Naming and Directory Interface,”
http://java.sun.com/jndi/, 1999 [25] Sun Microsystems, “Java 2 Platform, Micro Edition,”