Mobile Agents and Network Mobile Agents and Network ManagementManagementProject By: Cheryl Schramm

Motivations for Mobile AgentsMotivations for Mobile Agents• Motivation : Network Management systems (NMS) have in large part followed a centralized

approach, based on the manager-agent model of standards like SNMP and CMIP. Data is collected from agents located on the devices and analyzed centrally on the manager. The centralized approach has failed to meet the challenges of today’s networks. It suffers from bottlenecks at the manager, large processing requirements for the management platform, and excessive network traffic between the manager and the numerous agents because all data is brought to the manager, involving many unnecessary transmissions. Also, it lacks the flexibility required by a heterogeneous environment and by the growth of services brought on by ATM and Customer Network Management. Operators are overwhelmed by the amount of data, by the number of alarms and events requiring attention, and by the complications of managing devices from a number of vendors.

• The Promise of Mobile Intelligent Agents : The use of mobile agents affords new opportunities for the distribution of processing and control in network management. Mobile agents are migratory programs that move from one network component to another. Rather than transporting the data to a central location, mobile agents operate in the same locale as the data and return only relevant data or compiled data, thereby reducing the management traffic load on the network. Mobile agents are capable of acting autonomously to perform menial tasks or to provide intelligent support for high level tasks, thus placing the operator into a supervisory role with mobile agents as the operatives. Mobile agents are cooperative, such that agents can be assigned small low-level tasks and yet interact to achieve a higher level goal. Finally, mobility suggests that we can transport device-specific code, leading to opportunities for software version control and service customization.

Mobile Agents as a SolutionMobile Agents as a Solution• The Perpetuum Solution : The research thrust of the Perpetuum project is the use of mobile

intelligent agents for network management. We envision a network manager as a suite of problem-specific applications that launch and/or communicate with autonomous mobile network agents that we call netlets. The intent is to provide an extensible set of tools that shift the operator’s focus from MIB browsing to problem-solving. In this poster, we demonstrate this shift by applying mobile agents to network modeling. A broader definition of network modeling is proposed, and a mobile agent implementation of a Network Model Browser is explained, including innovative extensions that transform this model discovery tool into a problem-browser.

• To explore practical issues in applying mobile agents to network management, the Perpetuum project built an infrastructure for mobile code. The Mobile Code Kit[2] is an agent execution environment, written in Java. Each component to be managed must be Java-enabled and must have running a Mobile Code Daemon (MCD). The MCD is a process that listens on “standardized” TCP and UDP ports to receive Java code from a manager or from another MCD. The MCD is responsible for the authentication and storage of incoming mobile code, the transport of migrating code, as well the link to the component’s managed resources, called the Virtual Managed Component (VMC). The VMC is supplied by the vendor to tailor how the component is to be managed through a standardized agent interface. Minimally, the VMC provides SNMP-like information. More powerful are facilities that allow an agent to characterize “normal” operating conditions, to reboot the device, to run diagnostics, or to even download other methods or software upgrades from a vendor’s central store.

Applications and Network Applications and Network Models Models

• A network model is one view of the network.

• Depending on the application, the view will not only be defined in terms of static components, but also in terms of the dynamic status of these components.

• Application-Oriented Network Models :– Do not always contain complete network

topology– Are small and application-specific– Are dynamic – due to changes in topology

or in the status of a device.

Component-Based View Status-Based View

Model := All worksta tionsPC1PC2Server1

Model := All devices with utilization > 90%PC1Server1

PC1Util=93%

PC2Util = 45%

Printer1Util = 24%

Server1Util=93%

Network Model BrowserNetwork Model Browser

• The Network Browser is a Java applet that displays a network model

• The Browser applet launches Discovery Netlets to discover the network model.

• The Discovery Netlets migrate from one MCD to the next, reporting each discovered component back to the applet

• The Discovery Netlets may use their own migration agenda, or may use the default migration facility offered by the MCD, which migrates the netlet to a known neighbour.

PC 1Laptop 1Server1PC2Printer 1Workstation

Network Browser

?

Selective Network ModelSelective Network Model• Agents can be equipped with “selection

criteria”.

• Only those components that meet the selection criteria are reported to the browser applet for display

- Brings processing to device- Avoids needless traffic to the Browser

applet of unwanted components

Examples :

– All components that support SNMP

– All hosts with CPU utilization > 90%

– All links with latencies exceeding x msecs

– All paths between x and y

– All available paths with a given QoS

– All components that provide a service (eg. ftp, web, database, registry)

PC 1PC21

Host browser

Selection Criteria: Find all PCs

Yes

Yes

No

Dynamic Network ModelDynamic Network Model

• A network model must reflect changes in topology or in status.

Mobile Agent Solutions :

• Autonomous netlets continuously navigate the network, monitoring changes.

• A deglet is a stationary agent that is installed on a discovered network component to serve as a remote extension of the management application on the component side. Deglets remain on the component, reporting any changes in the component (its status or its services) to the Browser applet.

PC 1Prin ter 1

NC 1

Host browser

Deglet : Report periodicupdates to mgmt applet

Problem BrowserProblem Browser

• The Network Browser Evolves into a Problem Browser– In Java, code and data are interchangeable !

– The Customizable Browser : Instead of returning data about the component, the Discovery Netlet can return mobile code and URLs for inclusion in the network model.

– Browsing a component would then run this code or access this URL, producing a customized interaction with a component.

• The Handyman : Instead of simply querying a component for identifying information, the Discovery Netlet can perform actions.

• The Discovery Netlets can be equipped as mini-experts, discovering components with faults and autonomously fixing minor problems, using their own intelligence or by invoking the recovery facilities provided by the VMC (as permitted by the security facilities).

• The Network Browser evolves into a problem-browser, managing netlets that are present in the network and fixing simple faults with minimal involvement of the operator.

SummarySummary• The use of mobile agents suggests a new architecture for network management

systems.• A network manager is seen to be a collection of problem-oriented management

applications.• Each management application is small and focussed.• Each management application will perform its duties by launching and

communicating with mobile intelligent agents.• Mobile agents have the capability to standardize or customize the manager’s

interaction with the network components, and to minimize manager involvement by assuming the authority to autonomously perform jobs.

• The Network Browser is a mobile agent implementation of network model discovery.• The network model is one view of the network, defined in terms of topology or

status.• Discovery netlets compose a network model that is selective, dynamic and

customizable.• When equipped, a Discovery Netlet can act as an autonomous handyman, shifting

the focus of the Network Browser from browsing components to fixing problems.

Network Model Creation With Network Model Creation With Mobile AgentsMobile Agents

Project By: George Sugar/Xuong Tran

Information ModelInformation Model

GRAPHICALNETWORKBROWSER

NETWORK LINK

PORTS

SERVICES

TERMINATIONPOINT

GATEWAY

FORE SWITCH

NEWBRIDGE SWITCH

displays

provides

consist-of

connected-by

creates

DAEMONPROPERTIES

NETWORKNODE

NETWORKMODEL

consist-of

AGENT

has (2)

has

Network Model Network Model CreationCreation

NMCP

JVM

MCD

MCD

VENDERSERVER

NMNM

VMC

JVM

VMC

MCD

JVM

NC 2 NC 1

Discovery Agent Configuration Agent

Model Agent

VMC

Injected Mobile Code

Types of Mobile AgentTypes of Mobile Agent

• Discovery Agent– Visits each node in the network and spawns a Configuration Agent at each node.

– Communicates state information to Configuration agent.

– Circulates constantly within network in order to discover new components as they appear in network.

• Configuration Agent– Queries VMC on NC for specific parameters such as URL of vendor server.

– Migrates to vendor server in order to obtain Java classes for nodal behaviour.

– Spawns Model agent at vendor server.

– Communicates state information to Model Agent.

• Model Agent– Migrates from vendor server to network management platform.

– Communicates with VMC containing network model.

– Creates/updates nodes and links within network model.

– Installs behaviour associated with node.

– Behaviour includes:• communication with actual network component;• multiple views of node.

Graphical Network BrowserGraphical Network Browser

MODEL AGENTCREATES

Agent for Remote Maintenance Agent for Remote Maintenance (ARM) System(ARM) System

Project By: David Mennie

OverviewOverview

• A project investigating problem diagnosis and repair, in a network management context, using mobile code,

• written entirely in Java

• consists of a mobile code infrastructure, mobile agents, and GUIs for the network operator

– uses the Mobile Code Toolkit (MCT) developed as part of the Perpetuum Mobile Procura agent project

• infrastructure to allow the injection and migration of mobile code, uniform access to managed resources, and inter-agent communication

– autonomous, mobile code agents• Diagnostic, query, and repair agents available• agents can perform tests on the installed hardware and software components on a node, query

information on these components, or repair software related problems on the node (software version incompatibilities, software settings problems, etc.)

– GUIs• use widgets from Java Foundation Classes (JFC) or Swing • allow the network operator to interact with mobile agents remotely

DesignDesign

Upon launching the application, the network operator must log into the ARM System. This allows the system to update the Service Request List for all problems assigned to that specific operator. It is also required so the system can log all activities performed by the operator.

After successfully logging in, a network operator is presented with a menu of options. Most often, the operator will select the Browse Service Request List option to get information on the specific problems that he/she has been assigned. Submitting a service request and maintenance history on a network node or customer are available as well.

The Service Request List presents a list of all known problems in the network that match the data filter selected. As default, the filter selects problems assigned to the network operator currently logged in. From here, the operator can select a problem to address. Most often the Diagnose Problem option will be selected since the operator will not generally know the cause of the problem.

The first step in diagnosing the problem is to send a mobile agent to the node under investigation. This is done by presenting the operator with the Agent Deployment Interface. In this scenario, the operator selects a diagnostic agent which is capable of performing tests on the components installed on the node. The agent is sent from the maintenance station to the problem node by pressing the Dispatch Agent button.

Once the compressed mobile agent arrives, it is verified and instantiated by the Mobile Code Daemon on the node. The diagnostic agent can now obtain a list of installed components and available test cases from the Virtual Managed Components (VMCs) associated with each hardware or software device present on the node. This information is sent back to the Agent Control Interface for the review of the network operator.

The operator can expand the tree of components and select individual test cases to perform by adding them to the list on the right. Once the operator is finished, he/she can select Perform Tests to execute the tests on the selected components.

Upon execution of each test, the agent stores the test results internally. Once all of the tests have been successfully executed, the agent relays the results back to operator’s node and displays them in the Data Viewer. Here the operator can decide if further tests are needed or if sufficient information on the cause of the problem is available. The operator can select Repair Node to correct the problem.

If the problem is able to be fixed, the network operator can send a repair agent to the node. Repairs can only be done for software related problems using the ARM System. Alternatively, the operator can contact maintenance personnel so they can go to the customer’s premise to fix difficult software problems or hardware related failures.

Here the network operator dispatches a repair agent containing the correct software fixes to the node with the problem. Status information is sent back by the agent while repairs are carried out.

Thus, an effective problem diagnosis and repair was performed by a remote network operator using the ARM System.

Adaptive Migrating ServersAdaptive Migrating Servers

Project By: Gang Ao

The Static Server ProblemThe Static Server Problem

request

busy!!!busy!!!

Server idleServer

idle

NCrequest

requestrequest

clientclient

client

client

client

clientNC

NC

Bottleneck problem - device on which server executes may be overutilized while other networkcomponents are (near) idle. Lack of configurability - difficult to upgrade services or available resources.

ObjectivesObjectives

• To improve the mobile code infrastructure and demonstrate how it can be used to avoid bottleneck problems and achieve optimal network performance.

• Develop and implement schemes to dynamically obtain network utilization parameters while minimizing the network traffic; so called remote evaluation.

• Advance the development of the mobile tool kit to allow for communication server cloning and migration.

• Ensure that mobile agent communication services will not be interrupted during the communication server migration.

The Solution: Mobile ServersThe Solution: Mobile Servers

• Servers are written in Java:

– write once, run anywhere;

– can migrate to any network component running JVM+MCT.

• Communication server allowed to migrate.

• Utilization netlet circulates through network:

– measures resource consumption on network component;

– interacts with DPI-enabled VMC for resource measurements;

– returns to server component periodically in order to make migration decision.

• Migration infrequent as:

– complex, expensive process;

– want to avoid oscillatory behaviour.

Utilization Sensing AgentsUtilization Sensing Agents

NC - Network Component

NC JVM

JVM - Java Virtual Machine

MCD

MCD - Mobile Code Daemon

MF

MF - Migration Facility

CF

CF - Communication FacilitySF - Security Facility

NC

MCD

JVM

NC

MCD

JVM

Utilizationagent

Utilization agent

VMC

SNMPagent

Kernel

Utilizationagent

SF

Mobile Communication ServerMobile Communication Server

NC - Network Component

NC JVM

JVM - Java Virtual Machine

MCD

MCD - Mobile Code Daemon

MF

MF - Migration Facility

CF

CF - Communication FacilitySF - Security Facility

NC

MCD

JVM

NC

MCD

JVM

Communication Migration

agent

VMC

SNMPagent

Kernel

Communication Migration

agent

SF

Plug and Play NetworksPlug and Play Networks

Project By: Syed Kamran Raza

The ProblemThe Problem• Configuration and setup of a new component difficult in an existing network:

– heterogeneous nature of networks;

– large number of components;

– hardware and software attributes.

• New device (printer) on a network. Configuration steps are:

1. Establishing hardware connection.

2. Configuration of the device itself.

3. Configuration of the network.

4. Setup and activation of the appropriate drivers.

• This leads to:

– effort, fatigue and time consumption on part of the Network Manager;

– user has to wait a long time until complete configuration.

Plug and Play DevicesPlug and Play Devices

“ A Plug-n-Play device is the one that is capable of configuring itself and A Plug-n-Play device is the one that is capable of configuring itself and other network components once plugged-in the existing networkother network components once plugged-in the existing network”

• Windows ‘95 came up with the idea of Plug-n-Play hardware.

• In Network Management, we need to extend the idea because of the constraints like:

– registry of all the network devices is not easy;

– no operating system available on network to handle automatic installation process

Scenario: Plug-n-Play Scenario: Plug-n-Play PrinterPrinter

RegisterRequest

InternetVendor Repository

Discover

Setup

New device

1

2

3

4

Implementation of two major components is required:

1. VMCs at different nodes including Printer and Vendor site.

2. Mobile Agents at Printer to be sent to different network elements.

VMCs :

• Printer VMC

• Register VMC

• System VMC

• Driver VMC

• Setup VMC

Mobile Agents :

• Registry Deglet

• Discovery Deglet

• Request Deglet

• Setup Deglet

• Discovery Netlet

• Notification Deglet

Mobility Framework Mobility Framework ComponentsComponents

General Setup: VMCs and General Setup: VMCs and AgentsAgents

Printer VMC

Printer

Register VMC

Driver VMC

Vendor

PC

System VMC

Setup VMC

. . . . . Sun WS

System VMC

Setup VMC

Internet

Mobile Agent

:

Sequence of OperationsSequence of Operations

• The Printer VMC plays a central role. – It injects all the required mobile agents into the network.

• Steps (after boot-strap of the printer) :– Registration with the vendor: Registry Deglet– Scan of the existing network nodes: Discovery Deglet– Requesting required drivers from the vendor: Request Deglet– Supplying corresponding drivers to the nodes: Setup Deglet– Injecting permanent network scanner: Discovery Netlet – Upgrade notifications sent by vendor: Notification Deglet

Agent TransactionsAgent Transactions

Printer Node 1 (PC)

VendorNode n (Sun). . . .

Registry DegletRegister VMC

Printer VMC

System VMC

Printer VMC

System VMCDiscovery Deglet

Discovery Deglet

Request DegletDriver VMC

Printer VMC

Setup DegletSetup VMC

Notification DegletPrinter VMC

Discovery Netlet

Printer VMC

Discovery Deglet

• Assumptions:– each Network Component is Java-Enabled;– Mobility Framework (MCT) is installed on each Network Component;– required VMCs are provided on the components;– migration patterns are already established among participating nodes;– plug-n-play mobile agents are provided on at least one location.

• Issues:– boot-strap program for Printer;– printer needs an initial IP to communicate over the network;– printer must store some information (IP/URL) about its vendor;– the address of first network component (migration target) required so

that Printer may insert in the network in a linked-list manner.

Implementation: Implementation: Assumptions and IssuesAssumptions and Issues

Summary: Plug and Play Summary: Plug and Play DevicesDevices

• Advantages:

– platform independence;

– automatic discovery of new network components (through Discovery Netlet);

– easy upgrades and modifications;

– network extensibility without traditional operator involvement.

• Disadvantages:

– overhead of the mobility framework on each network component;

– security issues regarding agent-based systems;

– requires a healthy network for migration of agents over TCP.

For More Information...For More Information...

ARM System Home Page

http://www.engsoc.carleton.ca/~dmennie/ARM

Perpetuum Mobile Procura Project Home Page

http://www.sce.carleton.ca/netmanage/perpetuum.shtml