Department of Systems and
Computer Engineering

Network Management and
Artificial Intelligence Laboratory


 
Perpetuum Mobile Procura Project
Overview
Glossary
Mobile Code Toolkit
 NM & AI Lab Publications
 

Overview

The overall goal of the Perpetuum Mobile Procura Project is to research the use of mobile code for managing networks. The three words that constitute the name of the project are taken from Latin. Perpetuum stands for continuous, Mobile for mobile and Procura for management. Our flagship goal is a plug-and-play network; i.e., a network that is self-configuring and immune to faults through self-recovery.

The following is the application-based taxonomy of mobile code that we use in the project:

There are a number of supporting areas that are being put in place. They are: Although netlets are the main target of our development efforts, there are other exciting technologies based on mobile code that we are exploring in the context of Network Management: In the nearest future, the research on mobile code will be focused on: The scope of our research has extended as the concepts and ideas proved to be useful in other areas: With the proliferation of terms, we find that a glossary of terms at the end of this page is very handy.

Framework

Code mobility infrastructure

This activity lays solid ground for the actual research on netlets. Java is used to provide a transport layer for mobile code. After considering Java RMI and other systems that are based on RMI, we have come to the conclusion that simpler transport mechanisms are more suitable for Network Management. Our reasoning is similar to the arguments in favor of the use of UDP for SNMP. We provide a Mobile Code Daemon (MCD) that supports both UDP and TCP for transferring Java code between network nodes.

The Mobile Code Daemon (MCD) is a process that runs inside a Java Virtual Machine (JVM) on every network element (NC) and listens on a UDP or TCP port for requests to receive Java code. The code that is transported is tagged as active or passive. If the code is tagged as active, then it is installed and activated by calling its initialization and starting methods. Passive code is just installed; such a code extension can be used later on.

Applets, netlets and deglets are active. Servlets and extlets are passive. Piglets can be either active or passive.

There is a migration layer on top the the transport layer inside the MCD which provides mechanisms for determining when and where a netlet should move. Alternatively, a netlet might be intelligent enough to organize its own migration. This is a part of a research area discussed later.

Network simulator (click for details)

There is not a single operating company that would allow autonomous mobile agents to float inside its network at this moment. To conduct our research, we need a network simulator. From a perspective of an agent, there is no difference between a simulated and a real Network Component (NC) as long as they run a daemon that is able to accept and execute netlet's code. With the simulator we can create SNCs (Simulated NC) and modify their lists of attributes that can be used to simulate behavior of real hardware. The behavior of the SNC will be controlled by a simulated Virtual Managed Component(SVMC). SNCs can be put together with real NCs in one network, but the simulator can only interact with SNCs.

Network manager

Network manager is a suite of simple tools (Java applets) that interact with agents located on NCs (both simulated and real). For example, there will be a component browser, problem viewer, event viewer, etc., as well as other tools used for managing networks. We do not intend to implement a graphical network display, since its value for the research would be minimal and the cost of implementation very high. We implement only these part that are directly related to our research. The tools will be application driven. Each of the tools can be used for actual management of networks.

The data that the browsers will display originates in the network and is communicated by management agents. We will be using Java communication mechanisms, but we also plan to support SNMP and CMIP to talk to legacy agents.

We are exploring SUN's Java Management API which seems to be the most attractive underlying technology for the implementation at this moment.

Research

Delegation techniques

There are situations when the traditional client/server model cannot be used or is not very convenient. For example, in the Network Management domain, the role of a client that the manager plays (with agents being servers) is not perfectly suited. There are usually many agents and few managers while in the client/server models clients are plentiful and servers are few. Servers tend to be centralized and given special care with upgrades, backups, etc. That is not the case with NM agents. In Network Management, the managers are usually centralized and given a treatment reserved for servers in the client/server model.

If a manager wants to perform a task in the network, then it uses a Network Management protocol (e.g., SNMP, CMIP) to send a request to an agent to do the job. This approach requires that the complete repertoire of algorithms to perform any task is available on the agent. A different approach to the problem would be to maintain such a collection on the manager side. Whenever an action is required, an appropriate service routine would be sent to the agent, executed locally and destroyed. That what delegation is. We will call such a mobile routine a deglet.

There are plenty of advantages of providing services by delegation. Instead of installing big agents in every possible location, only 'thin' skeletons able to receive and execute code are required. That approach is very well aligned with an emerging concept of a Network Computer and network computing in general.

Installable/extensible/modifiable services

With the capability to receive code from other parties, any service can be installed and made available for subsequent requests. Since mobile code can be tagged as active, yielding netlets and servlets, or passive, there is an opportunity to install virtually any service by sending code that provides the service. In the extreme case, just an agent skeleton capable of receiving code is run on a device. The manager determines the functionality of such an agent by shipping various software elements that are installed as integral parts of the agent.

New functionality can be added many times, so the spectrum of provided services and the scope of individual services can be increased. On many occasions, instead of extending, the functionality must be altered; for example, when a new version of a service is installed. In such case, the newly received code takes place of the old generation which should be removed to prevent the agent from growing.

Initial research in this area is devoted to extending SNMP agents by downloadable Java subagents. The extensions communicate with the main agent via the DPI protocol. The subagents are naturally extensible by the virtue of being implemented in Java. No special protocol is required for that purpose.

Servlet is an emerging name for an uploadeable entity that is sent to a remote location and stays resident as a server for remote clients. It can be destroyed on request. Extletis an uploadeable or downloadable entity that  expands the functionality of the receiving party, but does not represent an extension to an interface protocol.

Applets are downloadable applications that cane be executed in a secure environment; for example, in a Web browser.

Netlet-to-host communication

Netlets visiting network elements (NCs) have to somehow communicate with the hosting system. In the SNMP world, an SNMP agent serves that purpose. We use Virtual Managed Components (VMCs) for the communication. A VMC is an object that describes: VMCs are supplied by the vendors of network components. Components can represent both hardware or software entities. The internal structure of a VMC can be anything that is suitable to the vendor in providing the interface that encompasses the areas that were specified in the list. The interface, VMC Interface (VMCI) is enforced by providing a VMC abstract class which has to be a superclass of any vendor specific VMC. Netlets visiting the component will be using the VMCI to communicate with the VMC (and the physical component). VMCI is open. The vendor may extend it and provide netlets (or other extensions) that understand the extended protocol. A third party vendor may also extend the VMCI to handle specific aspects of components (hardware or software); for example, a software house may sell printer specific netlets that use the extension of VMCI relevant to printing devices.

Plug and play networks

This goal of this research is to design and implement a scheme for automatic provisioning of components and services. Each VMC contains a provisioning agent that is injected into a network after plugging in the component. The agent is provided by the vendor. Its role is two-folded:

Interface to legacy system

In this activity, we are implementing the DPI protocol in Java. With the use of the DPI, we can extend any SNMP agent by the Java means (downloading classes). No compilation, killing or starting processes is required to extend or upgrade the SNMP agent.

The DPI interface provides also a means to obtain data from systems that run SNMP agents and not Java Virtual Machines with MCDs and VMCs. We are building a VMC which will talk DPI to an SNMP agent on the hosts system. Such SNMP VMC gives us a cheap access to the components that do not have native VMCs (until such VMCs are build).

Fault Management

Fault Management is the main research thrust of the NM/AI lab. There are a number of activities in this area at this moment. In the future, after the suitable framework is completed, almost all activities of the lab will be directly involved in intelligent Fault Management.

Distributed Artificial Intelligence

Fault Management concentrates on preventing or detecting and fixing network problems. We are interested in using methods from Artificial and Computational Intelligence in the context of cooperating netlets. The context places this research in the domain of Distributed AI.

The current activity in this area is concerned with the review of the state-of-art and selecting techniques that look promising in the context of fault management.

Swarm Intelligence for network management

This research involves:

Alarm correlation

Alarm correlation is one of the basic capabilities of network management systems. Expert Systems have been traditionally used for this purpose. In a quest for new ideas, a Ph. D. in Mathematics is looking at the correlation issues from another perspective. We are particularly interested in providing a framework employing the time factor in the process of reasoning.

Problem-oriented management

We intend to use mobile mini-expert systems to detect network problems. Each of such a netlet would deal with a very limited knowledge. As a matter of fact, in one extreme case, a netlet could be just an executor of tests for constraint satisfaction residing on a VMC. The tests and the constraints, and possible recovery routines, would be supplied by the vendors.

Self-repairing networks

The idea is to inject all sorts of netlets into the network that would be intelligent enough to take care of most of the problems by activating recovery routines or by planning other required activities. The intelligence can be build into the netlets and/or come from VMCs provided by vendors.

Migration patterns

Netlets, as mobile agents, have to moved between NCs. There must be a policy in place as to when an agent should migrate and where it should go. The policy might be enforced by the Mobile Code Daemon (MCD) or by the netlet itself. Such issues are the focus of the research on migration patterns.

The Mobile Code Daemon will implement a default migration policies. The policies will be administered by the network manager in a static or dynamic way (for example, they may change depending on the traffic or time of day, etc.). A netlet decides about its migration by asking to be migrated or executing its own migration algorithm. That can be overridden by the MCD under special circumstances; for example, in case of a security violation.

Network security

The most common concern about mobile agents, including our netlets, cruising telecommunication networks is network security. We will address this and similar concerns with a security based on netlet authentication.

We are reviewing the release of Java Development Kit 1.1 which provides for so called trusted mobile code.

Netlet density control

The second most common concern about mobile agents expressed by the industry is a danger of flooding the network by autonomous agents reproducing themselves in the network without any control. We are trying to find ways to control netlet density by self-regulation.

The idea is to enforce certain constraints on density of netlets in the network. Statistics on the frequency of netlet visits will be collected at certain locations (for example by the MCDs). If the density does not satisfy the constraints, then, if the density is too high, some netlets are intercepted and destroyed; if the density is too low, then additional netlets are generated (directly or indirectly by sending requests to netlet generators; for example, managers).

Netlet security

Network security was identified as a major concern of operation companies. A netlet, or agent in general, security is closely related, although evidently neglected.

The goal of this research is to prevent modification of netlets and using them as trojan horses for malignant purposes. A netlet that is not properly secured from intruders may become a piglet. Piglets will look like netlets to the receiving MCDs, so they will be activated possibly causing some damage to the hosting node or through the node to the rest of the network.

Netlet communication

Netlets can vary significantly in their range of capabilities. Some netlets might be completely autonomous, others may perform certain actions on their own while requiring certain degree of cooperation in achieving larger goals. There might also be netlets that are not capable of achieving anything without peers. Communication is critical in achieving goals that require cooperation of netlets. We will attempt to address this issue by examining more traditional AI techniques; for example, blackboard systems.

Adaptable service utility agent

With a limited human resources in operation control, companies that provide services to large number of customers will not be able to service all requests in a reasonable way. Video-on-demand delivery falls into this category. There are many customers using the services at the same time. Many of them will report problems that require operator's attention. It will not be possible to send technicians to all customers due to the large numbers and distance (for example, video can be delivered by satellites). Many of the requests will have similar nature, so it is reasonable to look for an automation of some of them. A service utility agent that uses a learning algorithm can provide a solution. A Neurosolver can be used as the learning component. which can acquire expertise from operators. If a problem is reported for the first time, the operator sends a mobile agent to perform the task. The agent is controlled remotely. Next time a similar problem is reported, the agent will attempt to resolve it without human intervention. Only if new conditions are perceived that make it impossible will the operator be contacted. The agent then can learn new skills from observing the actions of the operator. With time, a library of agents can be built, which will provide service for most common problems.

Automatic setup of ATM PVC's

Setting up a PVC in an ATM network involves several parties: the endpoint switches (the users of the PVC) and the provider of the connecting route (usually, an operating company). Very often, the manager has to deal with heterogeneous equipment and multiple APIs. Setting up a PVC between a Newbridge switch at the Carleton University and a FORE switch at NRC took several phone calls and a lot of time. A specialized mobile agent can perform the same task automatically. The agent visits the involved parties and communicates with them through their VMCs, which understand a common ontology. The ontology is a generalization of the schema that are used for several vendors including Newbridge, FORE, Cisco and Nortel.
 
 

Glossary

agent  a general term for any autonomous entity; the term is overused 
in the Network Management context, agents are used by the network managers to obtain data about the network and its components 
mobile code  code that can be transferred between distant locations 
code extension  mobile code that is sent to a remote location to extend  the capabilities of the receiving entity 
extlet  an uploadeable or downloadable code extension that expands the receiving party, but does not extend its interface protocol 
netlet  persistent mobile code that migrates between network elements and executes on each of them; it is thought to never terminate 
deglet  mobile code sent to a remote location with a certain task to perform; the name comes from delegation of authority; it terminates after achieving its goal 
servlet  an uploadeable code extension that expands the capabilities of a remote server by extending its interface protocol 
applet  mobile code that represents a downloadable application 
piglet  mobile code that has been intercepted and maliciously altered 
extensible agent  agent that can be extended; for example, SNMP agents can be extended through DPI; Java agents can be extended by downloading new classes 
plug-and-play network  network that is a self-configuring and self-reconfiguring and immune to faults through self-recovery 
MCD  Mobile Code Daemon; a process running inside a JVM which receives, transmits and manages chunks of mobile code 
NC  Network Component 
MR  Managed Resource 
SNC  Simulated Network Component 
VMC  Virtual Managed Component is an object that provides a link to the Managed Resources on the hosting system; VMCs are provided by system vendors; vendors implement VMCs by subclassing from VMC abstract class
VMC abstract class  Virtual Managed Component abstract class is a prototype for VMCs; it enforces the use of VMCI by every VMC
VMCI  Virtual Managed Component Interface is a standard way of communicating with the hosting system; every VE has to implement VMCI; in java it is enforced in the VMC abstract class
SNMP VMC  a quasi-VMC that can talk DPI to an SNMP agent; it provides the same functionality as a VMC, but uses the legacy system until a native VMC is provided 

Questions and comments regarding this site? Mail to:vladimir
Back to the Department of Systems and Computer Engineering