An integrated mobile agent framework for distributed network management †

This article was downloaded by: [University of North Texas]On: 21 November 2014, At: 16:16Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

International Journal of Parallel, Emergent andDistributed SystemsPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/gpaa20

An integrated mobile agent framework for distributednetwork management†

Manoj Kumar Kona & Cheng-Zhong Xua Department of Electrical and Computer Engineering , Wayne State University , Detroit, MI,48202, USAPublished online: 19 Aug 2006.

To cite this article: Manoj Kumar Kona & Cheng-Zhong Xu (2005) An integrated mobile agent framework for distributednetwork management† , International Journal of Parallel, Emergent and Distributed Systems, 20:1, 39-55, DOI:10.1080/17445760500033333

To link to this article: http://dx.doi.org/10.1080/17445760500033333

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/loi/gpaa20

http://www.tandfonline.com/action/showCitFormats?doi=10.1080/17445760500033333

http://dx.doi.org/10.1080/17445760500033333

http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/page/terms-and-conditions

An integrated mobile agent framework for distributednetwork management†

MANOJ KUMAR KONA and CHENG-ZHONG XU*

Department of Electrical and Computer Engineering, Wayne State University, Detroit, MI 48202, USA

Conventional network management based on simple network management protocol (SNMP) is often runin a centralized manner. The centralized management approach is limited to small-scale networksbecause it incurs excessive processing load and heavy network traffic in the management station. Forscalability, this paper presents a new management framework that integrates mobile agents with theSNMP protocol. The mobile agent technology provides support for distributed network management. Theintegrated framework allows the network operators to deploy an appropriate management approachaccording to the characteristics of target networks and the nature of management activities. A quantitativelatency model is developed for the mobile agent based approach. We have implemented a prototype of theframework based on an in-house developed Naplet mobile agent docking environment and the AdventNetSNMP package. We have experimented with the system in network interface performance monitoringand fault diagnosis applications. Experimental results demonstrate the advantages and disadvantages ofcentralized and distributed management approaches and the flexibility of the integrated framework andverify the accuracy of the latency model.

Keywords: Mobile agent; Naplet; Network management; SNMP

1. Introduction

Network management essentially involves monitoring and controlling the devices connected

in a network by collecting and analyzing data from the devices. Conventional network

management is mostly based on the simple network management protocol (SNMP) [5] and

often run in a centralized manner. That is, a management station periodically accesses the

data collected by SNMP agents residing on each networked device through the SNMP

protocol. The SNMP-based management systems give network operators the flexibility of

managing the whole network from a single place. It is proved to be efficient on small-scale

networks and for applications with needs for less frequent access to a limited amount of

information. For example, monitoring the states of router and links involves only a few

network parameters and is therefore suitable for a centralized management. However,

functions like network diagnoses often need to analyze a large amount of parameters. For

such high level network management activities on large-scale networks, the SNMP based

The International Journal of Parallel, Emergent and Distributed Systems

ISSN 1744-5760 print/ISSN 1744-5779 online q 2005 Taylor & Francis Ltd

http://www.tandf.co.uk/journals

DOI: 10.1080/17445760500033333

†This research was supported in part by NSF grants ACI-0203592 and CCR-9988266.

*Corresponding author. Email: [email protected]

The International Journal of Parallel, Emergent and Distributed Systems,Vol. 20, No. 1, March 2005, 39–55

Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

systems would produce an excessive processing load and heavy network traffic on the

management station and in turn cause a severe information bottleneck.

There are many efforts towards distributed network management. The SNMPv2 [18]

introduces a concept of proxy agent for hierarchical management. A proxy agent is

responsible for a set of devices, serving as a proxy between the management station and the

devices. SNMPv2 is not as successful as the first version, partly due to some security

concerns.

The latest trend is to deploy mobile agents to manage today’s large heterogeneous

networks. Mobile agents are special software objects that are autonomous and able to migrate

from one machine to another, carrying logic and data, performing actions on behalf of their

owners. Mobile agent based network management is to equip agents with network

management capabilities, as well as allowing them to issue requests to managed devices

(or nodes) after migrating to these nodes.

Mobile agent based network management is run in a fully distributed manner. It

decentralizes the management functions onto the network devices so as to overcome the

limitations of centralized approaches. We summarize its advantages from the perspective of

four major network management functions: performance measurement, configuration,

accounting, and fault diagnosis.

Performance measurement needs to gather statistical data about network traffic and

schemes to condense and present data. In a centralized SNMP-based approach, the network

management station queries the managed nodes for every fixed interval and analyzes the

collected data in a centralized manner. Because of the non-negligible data transmission

delays and potential information-processing bottleneck in the management station, this

centralized approach would lead to an inaccurate measurement on large-scale networks.

By contrast, mobile agent based approaches allow the network administrator to dispatch

performance measurement agents onto the managed nodes so that functions like data

filtering, condensation, and some preliminary analyses can be executed locally.

Configuration management is concerned with network initialization, service installation,

and maintenance. It needs to install software components, setup parameters, and to add and

update relationships among the components and status of components when the network is in

operation. This is a complex process. In a centralized management approach, the network

administrator has to perform all these tasks manually. Mobile agents can help smoothen the

configuration management process. The administrator can equip special configuration agents

with the necessary parameters and software components and dispatch them to the stations

that need attention regarding configuration. This approach is more efficient in the sense that it

helps in disconnected operation between the management station and managed nodes.

Accounting management is the process of gathering statistics about the network resources,

establishing metrics, checking quotas, and determining costs. Like performance

measurement, accounting activities can benefit from mobile-agent based distributed

management approaches as well.

Fault monitoring involves identifying faults in networked devices. Fault detection can be

implemented by the use of mobile agents. The network administrator can program the fault

detection agents with the capabilities of reporting to the management station about the

managed nodes whenever their utilizations surpass a certain threshold. Considering the fact

that there are needs in some situations for low-level SNMP protocols in the process of fault

detection and correction, mobile agents need to be integrated with SNMP based protocol.

M.K. Kona and C.-Z. Xu40

Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

To take advantage of the mobile agent technology for network management and for the

purpose of managing legacy SNMP based systems, this paper presents a flexible architecture

that integrates mobile agents with the SNMP protocol. This mobile agent based network

management (MAN) framework gives network operators flexibilities of using the SNMP

protocol or mobile agents for management according to the characteristics of the target

networks and the nature of the management activities. A quantitative latency model was

developed for the mobile agent based approach. We implemented a prototype of the

framework based on an in-house developed Naplet mobile agent system [10,20–23] and the

AdventNet SNMP package [1]. We have experimented with the system in network interface

performance monitoring and fault diagnosis applications. Experimental results demonstrate

the advantages and disadvantages of centralized and distributed management approaches and

the flexibility of the integrated framework and verify the accuracy of the latency model.

The rest of the paper is organized as follows. Section 2 presents the MAN architecture and

Section 3 describes two principal network management patterns using mobile agents and

demonstrates their usages in network diagnosis. Section 4 gives the implementation details of

the framework. Sections 5 and 6 present a latency model for mobile agent based network

management and experimental results on a cluster of workstations, respectively. Related

work is in section 7. We conclude the paper in section 8 with remarks on future work.

2. MAN: A mobile agent based framework

In the SNMP-based network management framework, SNMP agents running on managed

devices organize the locally collected data in a MIB format. Each SNMP agent is essentially

a daemon process that responds to requests from the management station. SNMP agents can

be organized in different ways in different platforms. In MS Window, SNMP agents are

implemented by an SNMP service (SNMP.EXE). The SNMP manager is typically a third-

party SNMP management console application. By contrast, SUN Solaris supports

a master/subagent model in the management. There is one SNMP master agent and

multiple subagents running on each managed node. The master agent acts as a primary

interface between the network manager and subagents, and serves as a request scheduler and

dispatcher for all subscribed subagents. MIBIISA utility bundled in Solaris is an example of

RFC 1157-compliant SNMP agent. It can work as a master agent or in standalone agent

mode.

The network management station communicates to SNMP agents in managed stations and

accesses to MIB parameters through the following six primitive operations:

(1) Get-Request—Obtain MIB parameters from an agent;

(2) Get-Next Request—Permit the retrieving of the next parameter in the MIB tree;

(3) Set-Request—Change MIB parameter values;

(4) Response—Respond to the Get Request, Get-Next Request and Set Request protocol

data unit (PDU);

(5) Trap— Enables one to report an event to the management station.

As an application level connectionless communication protocol, SNMP is run over user

datagram protocols.

Mobile agent for network management 41

Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

The operation Get-Request was designed to access individual MIB parameters. The

operation Get-Next Request helps access multiple contiguous MIB parameters in an efficient

way. However, they are insufficient for the network management station to access bulk data

belonging to different MIB parameter groups. The MAN framework integrates mobile agents

with SNMP, under which the network administrator can select an appropriate network

management model according to the network characteristics and the management

requirements.

2.1 Architecture and components

Figure 1 shows the integrated management architecture. In this approach, the management

station acts as a client and the managed nodes as servers. The manager creates application-

specific management agents and dispatches to the managed nodes. On receiving a

management agent, the managed node takes SNMP requests from the agent. The

management agent may manipulate the retrieved data locally. Execution of the agents is in a

confined environment mobile agent execution environment (MAEE). When the entire

transaction is completed, the management agent returns to the management station.

The MAN provides Java-compliant interfaces to network management services. The MAN

itself was developed in Java as well because of Java’s write-once-run-everywhere

commitment and its dynamic class loading and object serialization features. The MAN

framework consists of the following major components: management application, MAEE,

mobile agent producer (MAP), mobile agent, and conventional network management

protocol (CNMP).

The management application has a graphical user interface, which coordinates with the

agent applications underneath it. It interacts with a MAP in configuring a mobile agent

with details such as the parameters to be evaluated at the managed node’s site and health

functions [8].

MAEE is an environment for the execution of mobile agents. Network management agents

dispatched by the manager come to the managed nodes, execute their management tasks, and

go back to the manager with their execution results. We experimented with an in-house

Figure 1. Architecture of MAN: Integration of mobile agent with SNMP.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

developed Naplet mobile agent docking system for the MAEE. The Naplet system provides

constructs for agent declaration and dispatch, confined agent execution environment, and

mechanisms for agent monitoring, control and communication. Section 2.3 presents an

overview of the system. Notice that MAEE acts as an interface between mobile agents and

SNMP agent at the managed nodes.

MAP could be characterized as a tool for generating customized mobile agents that are

equipped according to the requirements of the network manager. By using MAP the

functional characteristics of management agents, which roam in the network to collect

information from managed nodes, can be changed dynamically (i.e. at runtime). Dynamic

creation and configuration of mobile agents is achieved using MAP.

A typical mobile agent is autonomous, mobile, persistent, communicative/collaborative,

active/proactive. The ability to travel allows mobile agents to move to the network element

that is to be managed. In other words, the agent mobility could be exploited to transfer the

agents to the managed node and interact locally with the resident SNMP agent on each

managed node. In MAN framework mobile agents are provided with a list of nodes to be

managed, SNMP statistics of interest, and other user-specified management functions.

As mentioned above, conventional SNMP based management is embedded into our

architecture to ensure compatibility with SNMP based systems. This integrated model also

helps keep the advantages of low level network management protocols. To interact with the

SNMP agent we have used AdventNet SNMP [1]. AdventNet SNMP provides a set of Java

tools for creating cross platform Java and Web-based SNMP network management

applications. This package provides a set of classes, which could be used to facilitate

communication between a managed device, and an SNMP manager or management

application.

2.2 MAN over TCP/IP

The MAN architecture demonstrates mobile agents as software entities that roam in the

network over TCP/IP. The operation of MAN over TCP/IP suggests a healthy advantage of

mobile agent based management.

Using conventional management techniques, retrieving large amounts of MIB data

involves a large number of PDU exchanges over network. To improve the above solution,

RFC1187 describes an algorithm that speeds up the retrieval of an entire table in a MIB by

using multiple threads to retrieve the MIB table in parallel [11]. But this algorithm requires

that the manager be running concurrently and it must have a priori knowledge about the

distribution of MIB instance identifiers. The situation could get worse in case packets get

dropped in transmission. Multithreaded MIB retrieval may also cause bursty SNMP traffic in

the managed nodes.

A Get-bulk operation was recently proposed to perform bulk retrieval of MIB data. Since

SNMP works over UDP, the data retrieved by the Get-bulk operation has to fit into a single

UDP packet. Grouping large amounts of MIB data which might be in the order of hundreds of

kilobytes results in a large overall delay, because UDP packets can handle packets of size less

than or equal to 64 kB.

The state carrying and state restoring capability of mobile agents could be exploited to

carry management data. Mobile agents can be configured to procure data from different

tables of MIB that is selective retrieval of MIB parameters, whereas Get-next and Get-bulk


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

operations are supported over well-related subsets of data in MIB. For example Get-next can

be used only to get the next row of the current interaction with MIB table. If management

involves large amounts of data and multiple machines MAN reduces end-to-end latency.

Philippe and Sprinkles mentioned the advantage of adding SNMP over TCP/IP in “Bulk

transfers of MIB data” [17]. They mentioned that the effect of moving from UDP to TCP

removes the limitation of maximum SNMP message size of 64 kB. Mobile agents, which work

over TCP/IP, could be used for network management. “MAN” suggests an architecture in

which mobile agent based management forms as a layer over conventional SNMP based

management. This also ensures that advantages of SNMP based management are not lost.

So the Network Manager can be given the flexibility of selecting UDP or TCP based on the

amount of management data that is involved. When a manager needs a small amount of data

from a small set of managed nodes, UDP is a better choice. When a large amount of MIB data is

to be retrieved from multiple managed nodes, mobile agent based management is desirable.

2.3 Naplet system for MAEE

The Naplet system is an experimental framework developed in house in support of Java-

compliant mobile agent for network-centric distributed applications [10,20,21,23]. Like

other existing systems, it provides constructs for agent declaration, confined agent execution

environments, and mechanisms for agent monitoring, control, and communication. The

Naplet system is built upon two first-class objects: Naplet and NapletServer. The former is an

abstract of agents, which defines hooks for application-specific functions to be performed on

the servers and itineraries to be followed by the agent. The latter is a dock of naplets. It

provides naplets with a protected runtime environment within a Java virtual machine. It also

provides mechanisms to facilitate resource management, naplet migration, and naplet

communication. The NapletServers are running autonomously and they collectively form an

agent flow space for the Naplets.

Figure 2 presents the NapletServer architecture. It comprises seven major components:

Naplet monitor, security manager, resource manager, naplet manager, messenger, navigator,

Figure 2. The NapletServer architecture.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

and locator. The messenger and locator components are used for naplet tracking and

communication. The naplet manager provides local users or application programs with an

interface to launch naplets, monitor their execution states, and control their behaviors. Naplet

launch is actually realized by its home navigator. The launching process is similar to agent

migration. On receiving a request for migration from an agent or the naplet manager, the

navigator consults the security manager for launch permission. Then, it contacts its

counterpart in the destination NapletServer for landing permission. Success of a launch will

release all the resources occupied by the naplet.

On receiving a naplet launch request from a remote navigator, the local navigator consults

the security manager and resource manager to determine if landing permission should be

granted. When the naplet arrives, the navigator reports the arrival event to the naplet manager

and then passes the control over the naplet to the naplet monitor.

A naplet server can be configured with various hardware, software, and data resources.

The services bound to alien naplets can be run in one of the two protection modes:

privileged and non-privileged. Non-privileged services, like routines in math libraries, are

registered in the resource manager as open services and can be called via their handlers.

By contrast, privileged services like getting network parameters must be accessed via

special service channels. The service channels, created by the local resource manager on

request, are communication links between alien naplets and local restricted privileged

services. It passes one endpoint to the requesting naplet and the other endpoint to the

privileged service.

Compared with other existing mobile agent systems, the Naplet system has the following

distinctive features: structured navigation facility [10], reliable inter-agent communication

mechanism [23], open resource management policies, and secure interface between alien

agents and naplet servers. In particular, it implements a unique agent-oriented access control

mechanism by introducing a group of agent-oriented permissions [21]. The mechanism

allows the agents to exercise their privileges based on their own roles in distributed

applications. The Naplet system was successfully applied for mobile parallel computing on

the internet [22]. This paper demonstrates its applicability in distributed network

management.

3. Travel patterns and examples

Given a set of managed nodes, network management agents, generated by MAP, can be

traveling in different ways. Two primary approaches are broadcast model and roaming

model.

3.1 Broadcast travel pattern

In the broadcast scheme, a management agent is dispatched to each managed device and

all the dispatched management agents stay at their respective node for their assigned

tasks for the amount of time specified by the MAP. Each management agent

communicates to its corresponding SNMP agent periodically at an interval specified by

the MAP, performs necessary calculations on obtained management statistics, and

analyzes them by using some functions equipped into the management agent, and finally

returns to the manager.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

An example illustrating the use of the above approach is described as follows. This scheme

could be used to monitor the performance of a set of managed nodes over a particular interval

of time. There are cases that involve a set of management parameters in calculating a

cumulative factor. Such a cumulative is called a health function. It indicates a system state or

efficiency of the node and could be viewed as a way to compress management data and

evaluate the performance of any element.

A performance management application can use MIB parameters ifInOctets and

ifOutOctets of the interfaces group to compute the percentage utilization of an interface over

a time interval. To perform this computation, two different polling intervals are required: one

to find total bytes per second at time x and another to find total bytes per second

at time y. The following equation computes utilization, U(t) for the polling interval x 2 y

seconds [8]:

UðtÞ ¼½ðifInOctetsy 2 ifInOctetsxÞ þ ðifOutOctetsy 2 ifOutOctetsyÞ� £ 8

ðy 2 xÞ £ ifSpeed

where ifSpeed is the bandwidth of the interface, inOctetsx is the bytes received by the

interface at time x, and ifOutOctetsx is the bytes sent by the interface at time x.

By using broadcast scheme we could dispatch management agent to each of the managed

nodes and the agent could calculate the utilization for every polling interval over an extended

period of time. Here the management agents manipulate the data locally at the managed

node. After the time period for which the analysis is required, which is equal to the sum of all

the polling intervals, the agent returns to the management station and the reduced data set

could be displayed in a graph.

In contrast, if conventional client/server architecture is used in calculating utilization at

interfaces of a set of nodes, the following operations are to be performed on each managed

node from the management station. For each of polling interval,

(1) Send Get-request for ifInOctetsx and ifOutOctetsx and receive response from the

managed node.

(2) After polling interval send get-request for ifInOctetsy and ifOutOctetsy and receive

response from the managed node.

(3) Calculate the total bytes per second and utilization at the managed node.

With multiple machines to be monitored, the amount of processing overhead and

information bottleneck at the management station would be high.

3.2 Roaming travel pattern

In the roaming model, a mobile agent visits the set of nodes to be managed sequentially,

as shown in figure 3. The mobile agent is configured with the list of nodes to be visited

during its itinerary and also the SNMP statistics to be analyzed. At each managed node it

obtains the required statistics, and performs necessary calculations in analyzing statistics

(reduces the amount of management data that it would carry) before it visits the next

managed node.

A network management example that is appropriate for the roaming model is fault

monitoring. Fault monitoring is based on a health function to calculate percentages of input


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

and output errors on an interface. It is a cumulative factor of 8 MIB variables [8]:

Percent input errors ¼ ½ðifInErrorsÞ=ðtotal packets receivedÞ� £ 100;

Percent output errors ¼ ½ðifOutErrorsÞ=ðtotal packets sentÞ� £ 100;

where

total packets received ¼ ðifInUcastPkts þ ifInBroadcasts þ ifInMulticastsÞ;

total packets sent ¼ ðifOutUcastPkts þ ifOutBroadcasts þ ifOutMulticastsÞ:

If the interface error rate is more than 1%, then there is a problem with the interface of the

machine. If the error rate is less than 1% and the network shows poor performance, then it

could be deduced that there is a problem with the media.

If monitoring of percentage error rates for interfaces of multiple machines is required, an

itinerary-based mobile agents could be dispatched, which sequentially visits all the

machines. At each managed node it interacts with the SNMP agent, calculates percentage

input and output errors locally on the managed node. After visiting all the nodes it returns

back to the manager. If conventional SNMP based management was used for the calculation

of above health function, it introduces a processing burden at the management station and

causes heavy network traffic.

4. Naplet based network management

In this section, we present the implementation details of the MAN framework by defining the

class of network management agents, NMNaplet, and MIB access proxies via the AdventNet.

4.1 Privileged service for access to MIB

In the MAN framework, the network management station creates naplets and dispatch

naplets to the target devices. The naplets gain access to MIB through local SNMP agents of

the devices. For communication between Java-compliant naplets and SNMP agents, we

deployed an AdventNet SNMP package on each managed device. The AdventNet SNMP

package provides a Java API for network management.

Figure 3. Network management agent roaming travel pattern.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

Following is a NetManagement class extended from a naplet PrivilegedService base class.

It is instantiated by the naplet ResourceManager and associated with a pair of ServiceReader

and ServiceWriter channels: in and out. Through the input channel, the NapletServer gets

input parameters from naplets and re-organizes them into an AdventNet SNMP format (lines

from 6 to 10). It then conducts a sequence of operations, as shown in private method

retrieve(), to communicate with the AdventNet SNMP for required MIB information. The

information is returned to the naplet through the out channel (line 12) The whole process can

be repeated for a number of inquiries from the same naplet or different naplets.

(1) import naplet.*;

(2) import com.adventnet.snmp.beans.*;

(3) public class NetManagement extends naplet.server.PrivilegedService {

(4) public void run() {

(5) for (;;) {

(6) String parameters ¼ in.readLine();

(7) Vector values ¼ new Vector();

(8) StringTokenizer parameterTokenizer ¼ new StringTokenizer(parameters,“;”);

(9) while (parameterTokenizer.hasMoreElements())

(10) values.addElement((String)parameterTokenizer.nextToken());

(11) String result ¼ retrieve(values);

(12) out.writeLine(result);

(13) }

(14) }

(15) private String retrieve(Vector parameters) {

(16) StringBuffer result ¼ new StringBuffer();

(17) String result ¼ null;

(18) SnmpTarget target ¼ new SnmpTarget(); //Create an enquiry SNMP target

(19) target.loadMibs(“RFC1213-MIB”); //Load MIB

(20) target.setTargetHost(InetAddress.getLocalHost()); //Set the SNMP target host

(21) target.setCommunity(“public”);

(22) Enumeration enum ¼ parameters.elements();

(23) while(enum.hasMoreElements()) {

(24) target.setObjectID((String)enum.nextElement() þ “.0”); //set the required

parameter

(25) result ¼ target.snmpGet(); //Issue an SNMP get request on Managed node

(26) }

(27) return result.toString();

(28) }

(29) }

4.2 Naplet for network management

The privileged service NetManagement is dynamically configured during the installation of

NapletServer. It is accessed by incoming naplets through its registered name

“serviceImpl.NetManagement”. Following is a naplet example for network management.

The NMNaplet class is extended from the Naplet base class with name, a list of servers to be


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

visited, and MIB parameters. It is also instantiated with a NapletListener object to receive

information retrieved from the servers. All the information will be stored in a reserved

ProtectedNapletState space. At last, the newly created NMNaplet object is associated with a

custom designed itinerary (lines from 36 to 45).

On arrival at a server, the naplet starts to execute its entry method: onStart(). It gets a

handler to pre-defined NetManagement privileged service. It then sends parameters to

NapletServer through a NapletWriter channel and waits for results from a NapletReader

channel. Notice that NapletWriter and ServiceReader are two endpoints of a data pipe from

naplets to servers. Another pipe links ServiceWriter to NapletReader.

When the naplet finishes its work on a server, it travels to the next stop. At the end of its

itinerary, the naplet executes operate() method to report the results back to its home. Since

NMItinerary defines a broadcast pattern, the naplet will spawn a child naplet for each server.

The spawned naplets will report their results individually.

(1) import naplet.*;

(2) import naplet.itinerary.*;

(3) public class NMNaplet extends Naplet {

(4) private String parameters; //MIB parameters to be accessed

(5) public NMNaplet(String name, String[] servers, String param, NapletListener

listener) throws InvalidNapletException, InvalidItineraryException {

(6) super(name, listener);

(7) parameters ¼ param;

(8) setNapletState(new ProtectedNapletState()); // Set space to keep device

information

(9) getNapletState().set(“DeviceStatus”, new HashTable(servers.length));

(10) setItinerary (new NMItinerary (servers)); //Associate an itinerary with

NMNaplet

(11) }

(12) // Entry point of a naplet at each server

(13) public void onStart() throws InterruptedException {

(14) String serverName ¼ getNapletContext().getServerURN().getHostName();

(15) Vector resultVector ¼ new Vector();

(16) HashMap map ¼ getNapletContext().getServiceChannelList();

(17) ServiceChannel channel ¼ (ServiceChannel)

map.get(“serviceImpl.NetManagement”);

(18) NapletWriter out ¼ channel.getNapletWriter();

(19) out.writeLine(parameters); // Pass parameters to servers

(20) NapletReader in ¼ channel.getNapletReader();

(21) String result ¼ null;

(22) while ((result ¼ in.readLine()) ! ¼ EOF) {

(23) resultVector.addElement(result);

(24) }

(25) Hashtable deviceStatus ¼ (Hashtable) getNapletState().get(“DeviceStatus”);

(26) deviceStatus.put(serverName, resultVector);

(27) getItinerary().travel(this);

(28) }


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

(29) private class ResultReport implements Operable {

(30) public void operate(Naplet nap) {

(31) if (nap.getListener()! ¼ null) {

(32) Hashtable messages ¼ (Hashtable) nap.getNapletState().get(“message”);

(33) nap.getListener().report(deviceStatus);

(34) }

(35) }

(36) private class NMItinerary extends Itinerary { // Parallel Itinerary

(37) public NMtinerary(String[] servers) throws InvalidItineraryException {

(38) Operable act ¼ new ResultReport();

(39) // broadcast

(40) ItineraryPattern[] ip ¼ new ItineraryPattern[servers.length];

(41) for (int i ¼ 0; i , servers.length; iþþ )

(42) ip[i] ¼ new SingletonItinerary(servers[i], act);

(43) setRoute(new ParItinerary(ip));

(44) }

(45) }

(46) }

5. Latency model of management agent

In the MAN approach, the management agent code is transported along with data (parametric

information) and results (network management data). The communication latency involved

in the mobile agent based management approach includes the overhead at the management

station, denoted as TMS, the time taken for local data query and processing, denoted as TMN,

and the transfer time of agent code, MIB parameters, and results, denoted as TNetwork. That is,

Latency ¼ TMS þ TMN þ TNetwork ð1Þ

It is known that

TMS ¼ Tpo þ T seðCþDÞ þ TdseðCþDþRÞ ð2Þ

where Tpo is mobile agent protocol overhead, the Tse(CþD) is the serialization cost for code

and data and Tdse(CþD þ R) is the de-serialization cost for code, data, and results;

TNetwork ¼Scþd

bwþ

Scþd þ Sr

bwð3Þ

where Scþd is the size of agent code plus data volume, Sr is the result size, and bw is the

network bandwidth; and that

TMN ¼ Tpo þ TdseðCþDÞ þ TseðCþDþRÞ þ T re ð4Þ

where Tre refers to the remote job execution time for a specific management task.

Management task might involve fetching MIB parameters and their local processing.

Assume the management agent is required to fetch a total of Q MIB parameters from the

managed node. It follows that

T re ¼ TLoadMIB þ Q £ ðTRequest þ TResponseÞ


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

where TLoadMIB is the time taken to load MIB into application and TRequest þ TResponse is the

average round-trip transmission time for SNMP request and reply.

Denote Tsdo the total serialization and de-serialization overheads associated with a

management agent. From equations (1)–(4), we have that

Latency ¼ 2Tpo þ TseðCþDÞ þ TdseðCþDþRÞ þ ð2 £ Scþd þ SrÞ=bw

þ TdseðCþDÞ þ T seðCþDþRÞ þ T re

¼ 2Tpo þ ½TseðCþDÞ þ TdseðCþDþRÞ þ TdseðCþDÞ þ TseðCþDþRÞ�

þ ð2 £ Scþd þ SrÞ=bw þ T re

¼ 2Tpo þ Tsdo þ ð2 £ Scþd þ SrÞ=bw þ T re: ð5Þ

By applying equation (5) to the broadcast network management scheme, we obtain the

latency model for a total of n managed nodes as

Latency ¼ T sdo þ Maxni¼1½ð2 £ Sciþdi þ SriÞ=bw þ Ti

re� ð6Þ

where Tire refers to the time for remote job execution at the managed device i and Ti

re ¼

TLoadMIB þ ðTRequest þ TResponseÞ:

By applying equation (5) to the roaming management scheme, we obtain the latency

model for a sequential visit of a total of n managed nodes as

Latency ¼Xn

i¼0

½Tpo þ T sdo þ ðSciþdiÞ=bw þXi

j¼0

Srj=bw þ T rei� ð7Þ

where Srj refers to the size of results when the management agent leaves node j. In this model

the mobile agent has to save the network management information collected at each node

it visits.

6. Experimental results

We conducted experiments to evaluate the MAN performance, in comparison with the

conventional SNMP approach, on a set of SUN workstations and servers. The management

station is a Sun 4-way Enterprise E3500 server. It is located in the same LAN as other four

managed workstations. They are connected via a Fast Ethernet. There is one more managed

workstation located in a different LAN.

Figure 4 presents the end-to-end latency for fetching various numbers of MIB parameters

from the five managed nodes, using SNMP and broadcast based mobile agents,

respectively. Results produced through SNMP based polling shows a gradual increase of the

end-to-end latency. The broadcast model shows superior performance as the number of

parameters to be fetched from the managed node increases. The plots are in agreement with

what we argued in section 3.1. That is, when a manager needs small amount data from a

small set of managed nodes, SNMP is a better choice and that when a large amount of MIB

data is to be retrieved from multiple managed nodes, mobile agent based management is

preferred.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

Figure 4 also presents an estimation of the mobile agent based management latency

according to equation (6). On the test environment, it was measured that the average data

transfer rate is 3.28 Mbps; the average round-trip communication cost Trequest þ Tresponse

for an SNMP request is 9.3 ms; the time taken to load MIB into the application TLoadMIB

is 3305 ms; for the amount of code and data we experimented with, the average

serialization and de-serialization overhead Tsdo is 97 ms. Putting all these together, we

obtain an estimated latency, excluding the agent dispatch overhead. From the figure, it

can be seen that the actual and estimated latencies are different by a constant factor due

to agent dispatch. The agreement between the plots verifies the accuracy of the latency

model derived in section 5.

In the last experiment, the manager was run as a single thread. An alternative is a

multithreaded collection of MIB parameters. A multithreaded network management can be

run in a green or native thread model. Application threads in a green model are bound to a

single lightweight process in Solaris. By contrast, application threads in a native thread

model are bound to different lightweight processes. We were running the network

management functions on a 4-way multiprocessor server. Expectedly, the native thread

model would deliver a better performance than the green thread. Figure 5 shows the

performance of mobile agent based network management in comparison with multithreaded

management versions. From the figure, it can be seen that multiprocessing in the

management station would not help boost performance due to the presence of network traffic

hotspots around the management station. From the figure, it can also been seen that as the

number of parameters to be monitored increases, MAN shows superior performance over

multithreaded SNMP management as well.

Figure 6 plots the latency due to the use of itinerary (i.e. roaming) mobile agents for

network management. As expected, the itinerary model leads to a much higher end-to-end

latency in comparison with the SNMP approach. However, it would be efficient in terms of

bandwidth utilization because it eliminates the traffic hotspot around the network

management station. This suggests an integrated mobile agent approach with SNMP for

network management.

Figure 4. Latency due to SNMP versus broadcast MAN.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

7. Related work

While mobile agent technology has long been pursued, its applications in network

management are still rudimentary. There were a number of empirical studies on mobile

agents for distributed network management and information retrieval in general. However,

few of them underwent rigorous assessment in performance. Bieszczad et al. [3,19]

described conceptual views on mobile agents for network management. Since much of the

research was in infancy, the authors reported their experience with the mobile agents in

several areas of network management, without developing many insights into performance

requirements. Sahai et al. [15,16] presented the network management of “Astrolog”. It was a

dynamic and decentralized management system for the management of distributed

heterogeneous systems. The system was based on a MAGENTA that was specially designed

for network administration. Gavalas et al. [6] presented the application of mobile agents in

bulk transfers of network monitoring data, data aggregation and acquiring atomic SNMP

table views. They analyzed the usage of mobile agents in network management with regard

Figure 6. Latency due to SNMP versus sequential itinerary agent.

Figure 5. Latency due to agents versus multithreading.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

to the bandwidth utilization. They addressed the issue of mobile agents for network

monitoring, but did not describe compatibility issues, which are related to managing

conventional SNMP based systems. Pinheiro et al. [13] described a conceptual model that

collected management-related data across a changing set of networked components and

periodically computed aggregated statistics using mobile agents. Their work concentrated on

aggregation of network monitoring data and mechanisms for agent adaptation. Goldszmidt

et al. [7] described a management delegation protocol, which allowed a manager to transfer

programs, create process instances and control their execution. It provided a software

framework that enhanced management of network-connected devices through delegated

scripts that execute asynchronously without managers intervention. Less stress was laid on

the aspect of integrating SNMP based systems.

Puliafito et al. [14] discussed advantages of mobile agent technology for network

management. They prototyped a mobile agent platform called MAP. MAP used CORBA as

underlying communication mechanism for transfer of code and data. But a CORBA based

mechanism for code/data transfer involved much more communication overhead than RMI

based mobile agent systems. The proposed network management system implemented new

functions of representative indicators of managed node status. Users were given the

flexibility of writing their own monitoring functions. Liotta et al. [9] presented an active

distributed monitoring system based on mobile agents. Agents act as monitors not bound to

any particular network node. They move around in response to the changing network

conditions.

Pagurek et al. [12] discussed about the necessity of integrating mobile agents with SNMP.

They exploited existing DPI protocols and proposed an extended RDPI protocol to enhance

the interaction of mobile agents with SNMP. RDPI is a lightweight protocol that would take

the advantage of the co-residency of the mobile and SNMP agents. This design allows the

mobile agent to access kernel services through a virtual managed component (VMC).

In essence the VMCs will communicate with SNMP agents using protocols such as

DPI/RDPI. This framework requires extending the existing management protocols with

lightweight protocols in order to have mobile agents interacting with the resident SNMP

agents. Also, it needs to modify SNMP agent code.

Picco and his colleagues [2,4] described a quantitative model for management related

network traffic and a formal tool for determining the best way to perform management

operations. They provided an extensive quantitative analysis of network traffic models for

client/server, mobile agent, remote evaluation (REV) and code on demand (COD)

approaches. Their models focused on network bandwidth consumptions.

8. Conclusions

We have presented a framework for efficient management of heterogeneous networks. It is

a hybrid model based on mobile agent and SNMP strategies. The framework gives

management stations or network administrators the flexibility of using any approach

according to the characteristics of target networks. To exploit the potential of mobile agent

technology for network management, we have proposed two agent-traveling patterns and

discussed their usages, advantages and disadvantages in the evaluation of network health

functions. We have also presented an accurate latency model for mobile agent based

network management.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

We plan to investigate details related to the management of devices like hubs and

switches, which cannot embed MAEEs. There is also a need for comprehensive

evaluations of the cost effectiveness of SNMP as well as mobile agent based approach on a

large-scale setting.

References

[1] The Advent Net Library. http://www.adventnet.com[2] Baldi, M. and Picco, G., 1998, Evaluating the tradeoffs of mobile code design paradigms in network

management applications. Proceedings of the 20th International Conference on Software Engineering, April.[3] Bieszczad, A., Pagurek, B. and White, T., 1998, Mobile agents for network management, IEEE

Communications Surveys, 1(1), 2–9.[4] Carzaniga, A., Picco, G. and Vigna, G., 1997, Designing distributed applications with mobile code paradigms.

Proceedings of International Conference on Software Engineering (ICSE’ 97), pp. 22–32.[5] Feit, S., 1993, SNMP: A Guide to Network Management (McGraw-Hill).[6] Gavalas, D., Greenwood, D., Ghanbari, M. and Mahogany, M.O., 2000, Advance network-monitoring

applications based on mobile intelligent agent technology, Computer Communications, Special issue on MobileAgents for Telecommunication Applications, 23, (8), 720–730.

[7] Goldszmidt, G., Yemini, Y. and Yemini, S., 1991, Network management by delegation—The MAD approach.Proceedings of the 2nd International Symposium on Integrated Network Management, April.

[8] Lienwand, A. and Conroy, K., 1996, Network Management: A Practical Perspective (Addison Wesley).[9] Liotta, A., Pavlou, G. and Knight, G., 2002, Exploiting agent mobility for large-scale network monitoring,

7–15 IEEE Network, May/June.[10] Lu, S. and Xu, C.-Z., 2003, MAIL: A mobile agent itinerary language and its operational semantics. Tech.

Report, Department of Electrical and Computer Engineering, Wayne State University, May.[11] McCloghrie, K. and Rose, R., Management Information Base for Network Management of TCP/IP based

networks (RFC 1213). http://www.faqs.org/rfcs/rfc1213.html[12] Pagurek, B., Wang, Y. and White, T., 2000, Integration of mobile agents with SNMP: Why and How.

Proceedings of IEEE/IFIP Network Operations and Management Symposium (NOMS), April.[13] Pinheiro, R., Poylisher, A. and Caldwell, H., 1999, Mobile agents for aggregation of network management data.

Proceedings of the First International Symposium on Agent Systems and Applications and the ThirdInternational Symposium on Mobile Agents (ASA/MA’99), October, pp. 130–140.

[14] Puliafito, A. and Tomarchio, O., 2000, Using mobile agents to implement flexible network managementstrategies, Computer Communication Journal, 23(8), 708–719, April.

[15] Sahai, A. and Morin, C., 1998, Towards distributed and dynamic network management. Proceedings ofIEEE/IFIP Network Operations and Management Symposium (NOMS’98) (New Orleans) February.

[16] Sahai, A., Morin, C. and Billiart, S., 1997, Intelligent agents for a mobile network manager. Proceedings of theIFIP/IEEE International Conference on Intelligent Networks and Intelligent Networks (2IN’97) (Paris),September.

[17] Sprenkels, R., Philippe, J. and Flatin, M., 1999, Bulk Transfers of MIB Data, Simple Times, 7(1), March, http://www.simpletimes.org/pub/simple-imes/issues/7-1.html

[18] Stallings, W., 1999, SNMP, SNMPv2 and RMON: Practical Network Management (Addison-Wesley).[19] White, T., Pagurek, B. and Bieszczad, A., 1999, Network modeling for management applications using

intelligent mobile agents, Journal of Network and Systems Management, September.[20] Xu, C.-Z., 2002, Naplet: A flexible mobile agent framework for network-centric applications. Proceedings of

International Parallel and Distributed Symposium (IPDPS’02), April, http://www.ece.eng.wayne.edu/, czxu/software.

[21] Xu, C.-Z. and Fu, S., 2003, Privilege delegation and agant-oriented access control in Naplet. IEEE Proceedingsof International Workshop on Mobile Distributed Computing, May.

[22] Xu, C.-Z. and Wims, B., 2000, Mobile agent based push methodology for global parallel computing, Journal ofConcurrency: Practice and Experience, 14(8), 705–726, July.

[23] Zhong, X. and Xu, C.-Z., 2004, A reliable and secure connection migration mechanism in mobile agentsystems. Proceedings of the International Conference on Parallel Processing (ICPP’04), August.


Dow

nloa

ded

by [

Uni

vers

ity o

f N

orth

Tex

as]

at 1

6:16

21

Nov

embe

r 20

14

Documents

An integrated mobile agent framework for distributed network management †