| Perpetuum Mobile Procura Project |
|
|
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:
-
mobile applications
-
mobile servers
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.
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:
-
allowed access methods (system calls)
-
methods defining and testing constraints on the system parameters
-
recovery schema for performing automatic recoveries (self-repairing
networks)
-
provisioning schema for automatic provisioning (plug and
play networks)
-
security schema (access rules)
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:
-
communicate to any concern parties that a new component has been plugged
in (including provisions for the delivery of any required data)
-
obtain any data that are needed on the component/service side to function
properly
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:
-
studies of the behavior of societies of simple ant-like agents that achieve
tasks by very high degree of cooperation,
-
a comparison between carrying out specific tasks by special-purpose vs.
general-purpose societies,
-
an insight into the evolutionary aspects of the behavior of agent communities,
-
generating some ideas on the possible uses of such societies for network
management purposes
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? 
vladimir
Back to the Department
of Systems and Computer Engineering
