Mobile Agents and Network Management Project By Cheryl

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. • 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.

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.

Selective 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 Qo. S – All components that provide a service (eg. ftp, web, database, registry)

Dynamic 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.

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 FORE SWITCH NETWORK NODE connected-by has (2) provides NEWBRIDGE SWITCH DAEMON PROPERTIES NETWORK LINK TERMINATION POINT SERVICES has PORTS

Network Model Creation Injected Mobile Code NC 2 NC 1 MCD NMCP MCD VMC NM NM JVM Configuration. Agent Discovery. Agent VENDER SERVER VMC MCD VMC Model Agent JVM

Types 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 – – – 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 • 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

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 request Server busy!!! client NC request busy!!! client request client idle 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 MCD SF Utilization agent MF CF MCD JVM VMC SNMP agent NC Kernel NC 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 SF CF Communication Migration agent MF VMC Kernel JVM NC MCD JVM SNMP agent MCD Communication Migration agent NC 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” 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 Printer VMC Discovery Deglet Driver VMC Request Deglet Printer VMC Setup Deglet Discovery Netlet 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