Transcript Agent for Remote Maintenance

Mobile Agents and Network
Management
Project By: Cheryl Schramm
Motivations 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 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
Models
•
A network model is one view of the
network.
Component-Based View
•
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.
Model := All workstations
PC1
PC2
Server1
•
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.
Status-Based View
Model := All devices
with utilization > 90%
PC1
Server1
Server1
Util=93%
PC2
Util = 45%
PC1
Util=93%
Printer1
Util = 24%
Network 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.
Network Browser
PC 1
Laptop 1
Server1
PC2
Printer 1
Workstation
?
Selective Network Model
•
Agents can be equipped with “selection
criteria”.
Yes
Hostbrowser
•
Only those components that meet the
selection criteria are reported to the
browser applet for display
-
PC 1
PC21
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)
Selection Criteria:
Find all PCs
Yes
No
Dynamic Network Model
•
A network model must reflect changes in
topology or in status.
Hostbrowser
PC 1
Printer 1
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.
NC 1
Deglet : Report periodic
updates to mgmt applet
Problem 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.
Summary
•
•
•
•
•
•
•
•
•
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
Mobile Agents
Project By: George Sugar/Xuong Tran
Information Model
AGENT
creates
NETWORK
MODEL
displays
GRAPHICAL
NETWORK
BROWSER
GATEWAY
consist-of
consist-of
FORE
SWITCH
NETWORK
NODE
connected-by
NETWORK LINK
has (2)
provides
NEWBRIDGE
SWITCH
DAEMON
PROPERTIES
TERMINATION
POINT
SERVICES
has
PORTS
Network Model
Creation
Injected
Mobile Code
NC 2
NC 1
MCD
NMCP
MCD
VMC
NM
NM
JVM
JVM
ConfigurationAgent
DiscoveryAgent
VENDER
SERVER
VMC
MCD
VMC
Model Agent
JVM
Types of Mobile Agent
•
Discovery Agent
–
–
–
•
Configuration 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.
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 Browser
MODEL
AGENT
CREATES
Agent for Remote Maintenance
(ARM) System
Project By: David Mennie
Overview
•
•
•
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
•
–
autonomous, mobile code agents
•
•
–
infrastructure to allow the injection and migration of mobile code, uniform access to managed
resources, and inter-agent communication
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
Design
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 Servers
Project By: Gang Ao
The Static Server Problem
client
client
request
NC
request
client
request
Server
Server
busy!!!
busy!!!
request
client
idle
NC
idle
client
client
NC
Bottleneck problem - device on which server executes may be overutilized while other network
components are (near) idle.
Lack of configurability - difficult to upgrade services or available resources.
Objectives
•
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 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 Agents
Utilization
agent
JVM
NC
MCD
Utilization
agent
JVM
NC
MCD
SF
Utilization
agent
MF
CF
MCD
JVM
NC
VMC
SNMP
agent
Kernel
NC - Network Component
JVM - Java Virtual Machine
MCD - Mobile Code Daemon
MF - Migration Facility
CF - Communication Facility
SF - Security Facility
Mobile Communication Server
JVM
NC
MCD
Communication
Migration
agent
MCD
SF
CF
Communication
Migration
agent
MF
JVM
NC
MCD
JVM
NC
VMC
SNMP
agent
Kernel
NC - Network Component
JVM - Java Virtual Machine
MCD - Mobile Code Daemon
MF - Migration Facility
CF - Communication Facility
SF - Security Facility
Plug and Play Networks
Project By: Syed Kamran Raza
The 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 Devices
“ A Plug-n-Play device is the one that is capable of configuring itself and
other 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
Printer
4
Setup
New device
2
Discover
3
1
Request
Register
Internet
Vendor Repository
Mobility Framework
Components
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 :
Mobile Agents :
• Printer VMC
• Registry Deglet
• Register VMC
• Discovery Deglet
• System VMC
• Request Deglet
• Driver VMC
• Setup Deglet
• Setup VMC
• Discovery Netlet
• Notification Deglet
General Setup: VMCs and
Agents
PC
System
VMC
Printer
VMC
Setup
VMC
.....
Sun WS
System
VMC
Setup
VMC
Internet
Register
VMC
Driver
VMC
Printer
: Mobile
Agent
Vendor
Sequence 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 Transactions
Node 1
(PC)
Printer
....
Node n
(Sun)
Vendor
Register VMC
Registry Deglet
Printer VMC
System VMC
Discovery Deglet
System VMC
Discovery Deglet
Printer VMC
Discovery Deglet
Driver VMC
Request Deglet
Printer VMC
Setup VMC
Setup Deglet
Discovery Netlet
Printer VMC
Printer VMC
Notification Deglet
Implementation:
Assumptions and Issues
• 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.
•
•
Summary: Plug and Play
Devices
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...
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