Managing Communication Resources
________________________________________________________________
Managing Communication
Resources
Mälardalen University
Department of Computer Science and Engineering
Michael Sievert
mst98015@student.mdh.se
Supervised by:
Nisse Rydblom at Citat Solutions
Filip Sebek at Mälardalen University
1
Managing Communication Resources
________________________________________________________________
Abstract
Data Unit Systemkonsult AB, now Citat Solutions, is contracted to develop the
communication system MSBL to the Swedish Defense. MSBL is a system used to send
Command and Combat messages between different military Units within the Swedish Navy.
Depending on how the different Units are connected, the system may communicate over radio
or wire.
In order to make efficient use of the various communication resources at its disposal,
MSBL has to manage transmission devices such as radios and antennas. The transmission
devices are connected to other communication systems. These are in turn connected to
MSBL.
To manage the transmission devices of presently existing and forthcoming systems from
MSBL, a standardized management solution has to be used. This paper examines SNMP,
CMIP, RPC, WBEM, and Mobile Agents for the management needs of MSBL. The solution
that best fits with the needs of MSBL is recommended. Software for simulating the
management aspects of the forthcoming systems is developed and described.
2
Managing Communication Resources
________________________________________________________________
Table of Contents
Managing Communication Resources .................................................................... 1
Abstract ............................................................................................................................................... 2
Table of Contents ................................................................................................................................ 3
Acknowledgements ............................................................................................................................. 5
1
Introduction ....................................................................................................................... 6
2
Background ........................................................................................................................ 8
2.1
MSBL ........................................................................................................................ 8
2.2
Network Management ............................................................................................. 10
2.2.1 General ................................................................................................................................... 10
2.2.2 FCAPS ................................................................................................................................... 11
3
Network Management from MSBL ............................................................................... 13
3.1
Present...................................................................................................................... 13
3.1.1 General ................................................................................................................................... 13
3.1.2 PCMIND ................................................................................................................................ 14
3.1.3 SjöMan ................................................................................................................................... 15
3.2
Future ....................................................................................................................... 16
3.2.1 General ................................................................................................................................... 16
3.2.2 HF2000 and VLF ................................................................................................................... 16
3.2.3 ICS2000 ................................................................................................................................. 17
3.3
Changes Required .................................................................................................... 18
3.3.1 Presently Employed Devices .................................................................................................. 18
3.3.2 Future Devices ....................................................................................................................... 20
4
Network Management options ....................................................................................... 23
4.1
General ..................................................................................................................... 23
4.2
Simple Network Management Protocol................................................................... 24
4.2.1 Background ............................................................................................................................ 24
4.2.2 Description ............................................................................................................................. 25
4.3
Common Management Information Protocol .......................................................... 32
4.3.1 Background ............................................................................................................................ 32
4.3.2 Description ............................................................................................................................. 32
4.4
Remote Procedure Call ............................................................................................ 35
4.4.1 Background ............................................................................................................................ 35
4.4.2 Description ............................................................................................................................. 35
4.5
Web-Based Enterprise Management ....................................................................... 38
4.5.1 Background ............................................................................................................................ 38
4.5.2 Description ............................................................................................................................. 38
4.6
Mobile Agents ......................................................................................................... 42
4.6.1
4.6.2
4.6.3
4.6.4
4.6.5
4.6.6
Background ............................................................................................................................ 42
Description ............................................................................................................................. 43
Agent Mobility ....................................................................................................................... 44
OMG MASIF ......................................................................................................................... 45
Mobile Agents for Managing Networks ................................................................................. 48
Advantages of Mobile Agents ................................................................................................ 49
3
Managing Communication Resources
________________________________________________________________
4.6.7 Problems with Mobile Agents ................................................................................................ 52
4.6.8 Integration with legacy technologies/protocols ...................................................................... 53
4.6.9 Agent Platforms ..................................................................................................................... 55
5
Review/Evaluation........................................................................................................... 56
5.1
General ..................................................................................................................... 56
5.2
SNMP ...................................................................................................................... 57
5.2.1 General ................................................................................................................................... 57
5.2.2 Positive aspects ...................................................................................................................... 57
5.2.3 Negative aspects ..................................................................................................................... 58
5.3
CMIP........................................................................................................................ 59
5.3.1 General ................................................................................................................................... 59
5.3.2 Positive aspects ...................................................................................................................... 59
5.3.3 Negative aspects ..................................................................................................................... 60
5.4
RPC .......................................................................................................................... 61
5.4.1 General ................................................................................................................................... 61
5.4.2 Positive aspects ...................................................................................................................... 61
5.4.3 Negative aspects ..................................................................................................................... 62
5.5
WBEM ..................................................................................................................... 63
5.5.1 General ................................................................................................................................... 63
5.5.2 Positive aspects ...................................................................................................................... 63
5.5.3 Negative aspects ..................................................................................................................... 63
5.6
Mobile Agents ......................................................................................................... 64
5.6.1 General ................................................................................................................................... 64
5.6.2 Positive aspects ...................................................................................................................... 64
5.6.3 Negative aspects ..................................................................................................................... 65
6
7
8
9
Recommendation ............................................................................................................. 66
6.1
General ..................................................................................................................... 66
6.2
Mobile Agents in MSBL ......................................................................................... 67
Proposed solution ............................................................................................................ 69
7.1
General ..................................................................................................................... 69
7.2
Simulator.................................................................................................................. 69
Result ................................................................................................................................ 74
8.1
Analysis ................................................................................................................... 74
8.2
Future Work ............................................................................................................. 75
Conclusions ...................................................................................................................... 76
10 References ........................................................................................................................ 77
4
Managing Communication Resources
________________________________________________________________
Acknowledgements
This paper is intended as a thesis for a Master of Science degree in Computer Science from
Mälardalen University. The work was conducted at Citat Solutions, formerly Data Unit
Systemkonsult, in Stockholm. Sincere thanks and appreciation to all persons involved, in
particular Lennart Bygdeman and Nisse Rydblom at Citat Solutions as well as Filip Sebek at
Mälardalen University.
Great appreciation is also extended to everyone who make publications available online,
especially to the NEC ResearchIndex database (http://citeseer.nj.nec.com), which contains
many of the articles referred in this thesis. On a related note the author would like to point out
his frustration with standards bodies that do not publish their specifications online, and the
ones who do so but charge for the access. Unfortunately it appears as though the openly
published Request For Comments, RFC’s, from the IETF are the exception rather then the
rule. It would be great if other organizations such as ITU, ISO, The Open Group, etc would
follow suite.
5
Managing Communication Resources
________________________________________________________________
1
Introduction
The purpose of this report is to provide a recommendation for a management solution to be
used by a military communication system called MSBL [2.1]. The report explains what
management functionality is and outlines the different requirements the solution needs to
fulfill. The alternatives are described one at a time. They are then looked at for use with
MSBL. The most favorable solution is recommended for use and an implementation of a
simulator using the solution is described. This report is organized as stated below:

Background
The background section provides some general information regarding issues central to
the paper, namely the communications system MSBL and network management in
general. This gives the reader an idea of what MSBL is and lets the reader know the
general concepts of network management. These concepts are reflected throughout the
rest of the paper.

Network Management from MSBL
This part gives information on the systems MSBL will have to manage. It provides an
overview of systems that exist today as well as forthcoming systems. The current
management concept for these systems is explained here as well as any changes required
for the systems to function with MSBL.

Network Management Alternatives
This section outlines the different management solutions considered for MSBL. A
fairly detailed description is given for each of the proposed solutions.

Evaluation
The evaluation section provides an analysis of the pros and cons for each of the
proposed management solutions.
6
Managing Communication Resources
________________________________________________________________

Recommendation
This section recommends and justifies a solution.

Proposed Solution
In this section a solution is proposed based on the recommended solution.

Result
The result of the thesis is analyzed. Some suggestions for further work are also proposed.

Conclusion
This section provides concluding statements about the problem, and how it was solved.
It gives a brief explanation of MSBL and states which management solution was selected
by the author.
7
Managing Communication Resources
________________________________________________________________
2 Background
2.1 MSBL
MSBL, Marin SamBandsLedning, is a communication system used by the Swedish
Defense. The system uses different cryptographic and communication resources to transfer
combat and command messages between military units within the navy. Depending on how
the units are connected the communication can operate over radio or cable.
Presently there are many different communications systems and protocols/formats used
throughout navy units. MSBL is meant to unify the communication by being able to use the
existing systems and convert between their different formats.
8
Managing Communication Resources
________________________________________________________________
Figure 2-1, General Overview
The intention with MSBL is to create a general and platform independent interface towards
the rest of the world for the navy command and control systems. MSBL is designed to
standardize the procedures involved in converting between different formats to facilitate
communication from one type of system to another.
An example is how Combat Control sends combat messages such as target information.
This information is received by MSBL in one format. The destination unit does not
understand this particular format so the data has to be converted. This conversion is hidden
from the Combat Control system. All it has to know is to which unit it wishes to send the
message. MSBL selects the appropriate format and protocol. [3]
9
Managing Communication Resources
________________________________________________________________
The actual transmission of data is handled by a variety of other communication systems.
These in turn directly or indirectly interface with the transmitting or receiving devices. In the
new version of MSBL, these transmission devices have to be manageable from within the
MSBL system. MSBL communicates over a data network. This means MSBL will monitor
and configure devices in a networked data environment. This area is referred to as Network
Management.
It is important to note that MSBL is concerned with managing the actual device stations
but this managing functionality will be facilitated through other systems. MSBL will itself
never have direct contact with the managed devices, such as radios, in these systems.
2.2 Network Management
2.2.1 General
A general description of network management (from Cisco): “Network management is a
service that employs a variety of tools, applications, and devices to assist human network
managers in monitoring and maintaining networks.”[9] Another description might be that
network management is the act of remote monitoring and configuring networked systems
and/or devices.
As computer networks began to grow in size in the early 1980’s they also became much
harder to manage and maintain. This created a need for efficient monitoring and configuration
of network devices from a remote position. The most basic example of this, that is still
presently used, is the remote login programs such as telnet. By using remote login, a network
administrator can configure and monitor network devices located at various geographical
locations without leaving his office. [7] The need for efficient monitoring and configuration is
more evident then ever in the heterogeneous systems present in current network
environments.
10
Managing Communication Resources
________________________________________________________________
2.2.2 FCAPS
In order to provide some kind of general framework over network management
functionality ISO, the International Organization for Standardization, has defined a
conceptual model called FCAPS describing the most important functional areas of network
management. This definition is a part of a standard from the OSI, Open Systems
Interconnection, called the OSI Structure for Management Information. FCAPS is an
acronym for Fault Management, Configuration Management, Accounting, Performance
Management and Security Management. Most network management systems do not however,
fully support all these areas.

Fault Management
Fault management deals with detecting, isolating and correcting problems. This
includes performing diagnostic tests, logging and reporting faults. [6][7][8][9][10]

Configuration Management
Configuration management deals with monitoring the configuration information of the
network. This is perhaps the most important part of network management. Most of the
problems encountered are a direct result of improper configurations. [6][7][8][9][10]

Accounting
This area involves measuring groups and individual users utilization of the network.
This data can then be used to provide billing information or to maintain good network
performance. It often involves finance, often with focus on cost cutting. The data can also
be used as a basis when regulating certain users or groups. [6][7][8][9][10]

Performance Management
Performance management concerns measuring various aspects of a networks
performance. This includes gathering and analyzing various statistical data in order to
maintain the performance at an acceptable level. [6][7][8][9][10]
11
Managing Communication Resources
________________________________________________________________

Security Management
Security management controls access to network resources in order to ensure legitimate
use, maintain confidentiality and data integrity. [6][7][8][9][10]
Though some areas are often thought of as more important then others, together they make
up the criteria to be considered when managing a network. Because not all management
protocols support all the areas, it is important to keep in mind what areas are essential for the
specific network when selecting a network management solution.
12
Managing Communication Resources
________________________________________________________________
3 Network Management from MSBL
3.1 Present
3.1.1 General
Presently there are two different communication systems in use that need to be managed
from MSBL. Both these communication systems currently have their own internal structure
and interfaces. They are managed separately through various means. The goal is to be able to
manage these devices through a single system instead of relying on other methods for separate
management of each system.
The present systems in use are PCMIND and SjöMan. These are independent
communication systems that control their own set of device stations attached (radios,
antennas, etc), which they use to transmit and receive messages. [2]
13
Managing Communication Resources
________________________________________________________________
3.1.2 PCMIND
Figure 3-1
PCMIND is used to send and receive messages. The system is found on board military
vessels and on Swedish Coast Guard and Swedish Navy establishments. The system also
controls a set of communication devices, called device stations, used for transmitting and
receiving messages.
PCMIND consists of three separate PC programs. In short the system functions as follows:
a few user applications, MMI Programs, that communicate with a database, which in turn
talks with a program which handles the communication with the actual device stations. The
operator interfaces with the system through the user applications. All parameters, like send
and receive frequencies, are controlled from the user applications. The management of the
system is considered local. [2][4][5]
14
Managing Communication Resources
________________________________________________________________
3.1.3 SjöMan
Figure 3-2
SjöMan is a communication system for radio used in some of the Swedish Coast Guards
surveillance stations. The system supports a wide array of different radio types. It supports
traffic for speech, data, telegraph, and remote script.
The SjöMan system is maneuvered by an operator from a station referred to as TVAK,
derived from “TeleöverVAKare”. The operator controls the system from a workstation and a
traffic panel. These control a TVAK Unit. This unit controls a TVAK switch that is connected
to the actual communication radios.
The workstation is connected to the TVAK Unit via v24, a standard serial connection, from
one of its COM ports. [83] The workstation is used to handle all radio parameters, lines etc.
15
Managing Communication Resources
________________________________________________________________
The traffic panel is used to select which transmitter will be used for sending and which
receiver will be used for listening. The software for the maneuvering workstation presently
runs on Macintosh machines but a PC port is scheduled for release before this paper is
completed. [2]
3.2 Future
3.2.1 General
MSBL will have to manage three forthcoming systems, HF2000, VLF and ICS2000. None
of these are presently in use. They are still under development. Only one of them has been
prototyped as of this writing. These systems should utilize the same management solution as
the presently deployed systems. [2][5][4]
3.2.2 HF2000 and VLF
16
Managing Communication Resources
________________________________________________________________
Figure 3-3
HF2000 is a communication system currently developed by Marconi. As of this writing, it
has not been prototyped and the particulars of the design are still being worked out. HF2000
will be a communication system that uses HF radio, High Frequency, to transmit messages
from one addressee to one or more addressees. [4][5]
The VLF, Very Low Frequency, system is used to send text messages to submarines. A
prototype does exist at present. This prototype is managed locally and that the system
contains no functionality for being managed remotely. Future versions of VLF will be
manageable via SNMP, Simple Network Management Protocol [4.2]. [2]
3.2.3 ICS2000
Figure 3-4
17
Managing Communication Resources
________________________________________________________________
Developed by INFOCOM, ICS 2000, or Integrated Communication System 2000, will be a
communication system for use on board Navy vessels. The system consists of a control
station and a communication switch called DCS2000. The operator controls the device
stations from a control station. This control station is essentially a workstation running a
management client from INFOCOM. [11] It currently supports remote administration via
RPC, Remote Procedure Call [4.4] as defined by RFC1057. This is how the control station
communicates with the DCS2000 communication switch. The DCS2000 in turn controls the
connected device stations. [2]
3.3 Changes Required
3.3.1 Presently Employed Devices
3.3.1.1 General
The general concept for facilitating the communication between the different interfaces
will be to use a maneuvering client as a proxy between the Control Unit in MSBL, also
referred to as the Transmission manager, and the managed systems. In the managed systems,
a maneuvering server will be used to handle the management communication from the
maneuvering client. The maneuvering server will then interface with the managed system
through whatever means are presently provided for configuration. This could be some obscure
proprietary solution that operates over a serial interface or perhaps it could be an open TCP/IP
based solution.
Security will not be a determining factor in the selection of management interface/protocol
because the network is considered to be secure. In other words it does not contain any hostile
hosts who would attempt to abuse the management privileges. The maneuvering servers may
therefore disregard security precautions normally considered vital. [2]
18
Managing Communication Resources
________________________________________________________________
3.3.1.2 PCMIND and SjöMan
Figure 3-5
A maneuvering server will have to be created for PCMIND. The Database Handler in
PCMIND will see the maneuvering server as a regular client. Thus the maneuvering server
will communicate in the same way an MMI program currently communicates with the
Database Handler. [2] The maneuvering server will also contain proxy functionality to
communicate over the management interface with the maneuvering client in MSBL.
19
Managing Communication Resources
________________________________________________________________
In SjöMan the maneuvering server will function in a similar manner. From the point of
view of the TVAK Unit in SjöMan, the maneuvering server is seen as a regular maneuvering
station, though in reality the server receives the management instructions from MSBL via the
management interface. [2]
3.3.2 Future Devices
3.3.2.1 General
The forthcoming systems will be managed similar to the present ones. They will also use
the same management interface. The major difference between the forthcoming and the
already existing systems is that the management interface has not yet been defined for the
forthcoming systems. During the development process there is a possibility to persuade the
manufacturers to adopt the common management interface selected for MSBL.
20
Managing Communication Resources
________________________________________________________________
3.3.2.2 HF2000, VLF and ICS2000
Figure 3-6
ICS2000 is presently managed using RPC. [2] The new version of VLF, and possibly
HF2000 as well, is currently being designed with the possibility of management using SNMP.
[1] For the maneuvering server in ICS2000, this means that it has to communicate with
DCS2000 using RPC. If MSBL will use RPC as the management interface, the maneuvering
servers proxy capability would be unnecessary since the maneuvering client in MSBL could
communicate directly with the DCS2000 communication switch.
21
Managing Communication Resources
________________________________________________________________
The manufacturers of HF2000 and the new version of VLF will most likely handle the
implementation of the maneuvering server for the respective systems. If this is not the case
there will most likely be an SNMP interface for the maneuvering server to communicate via.
The same thing would then hold true for VLF and HF2000. If SNMP is used as the
management interface, the maneuvering server is no longer a necessity.
Since security will not be a deciding factor in the selection of management
interface/protocol, the maneuvering servers may disregard this aspect just like they would in
the present devices. [2]
22
Managing Communication Resources
________________________________________________________________
4 Network Management options
4.1 General
Although there are plenty of options available to manage networks, the management
solutions chosen below seems to be the some of the most popular in present implementations.
These are also the protocols that have been considered for use with MSBL and is therefore
included in this paper.
SNMP and CMIP, Common Management Information Protocol [4.3], are standardized,
traditional management solutions. They are the most obvious choices to review when
deciding on a network management solution. The other alternatives described below are
probably not as obvious. WBEM, Web-Based Enterprise Management [4.5], is a fairly new
emerging standard. RPC in it self is not a new concept, nor is management via RPC, but
unlike the previous three it is not a specific management protocol.
The final alternative is a little different. Research in network management is mostly
concerned with distributed management. In this area the work is moving toward the use of
mobile agents to manage networks. While real world implementations of this paradigm are
rather scarce at the moment, it is an interesting option and it appears to be in this direction the
network management field is moving.
23
Managing Communication Resources
________________________________________________________________
4.2 Simple Network Management Protocol
4.2.1 Background
The IETF, Internet Engineering Task Force, Management Framework is commonly
referred to as SNMP, or Simple Network Management Protocol. SNMP was originally
designed in the late 1980’s to integrate the management of different types of network devices.
It has evolved to become the present “de facto” standard for network management on the
Internet. [15] SNMP is a part of the Transmission Control Protocol/Internet Protocol (TCP/IP)
protocol suite. [17] Several versions of SNMP coexist in the networked environments today.
The version still most widely deployed is SNMPv1.
Version history

SNMPv1
The first version of SNMP was standardized in 1988. [18]

SNMPv2
After the success of the first version of SNMP, there became an apparent need for new
functionality that was missing from the first version. Primarily a framework designed to
allow distributed management and to provide a security model, something that practically
did not exist in the first version. Around 1993 a standard was proposed for version 2. This
version had a security model based on parties. The four editors however, did not agree on
the security part of the specification and the proposal was rejected. The distributed
management framework was moved to a separate specification called DISMAN [76].
As a result of this the security model was scrapped and a few different new proposals
appeared in 1995. A community based security model was used in the SNMPv2c proposal
24
Managing Communication Resources
________________________________________________________________
while a user based security model was proposed in SNMPv2u. Neither of these was ever
approved as a final SNMPv2 standard. [14]

SNMPv3
In 1997 a new working group was formed with new editors to create a new
standardized version of SNMP containing the desired functionality and security that could
never be agreed on for version 2. [14] The Internet Engineering Steering Group, IESG,
approved SNMPv3 as full Internet Standard in March 2002. [98]
4.2.2 Description
4.2.2.1 General
When describing SNMP it is important to note that there are various versions of the
protocol with the most commonly used still being the oldest, SNMPv1. This paper will
attempt to describe the common characteristics of all versions unless otherwise stated.
SNMP is essentially a request-reply protocol that operates over UDP. A client/server
system is used where the server is referred to as an agent and the client as a manager
(sometimes called NMS, or Network Management Station). The agent can be thought of as a
dumb node that performs get and set operations as directed by the manager. A network
element that contains an SNMP agent is called a managed device. Examples of these can be
routers, switches and bridges, hubs, workstations and servers, or printers. [17]
Each managed device keeps a database of elements representing different characteristics of
the device, called managed objects. The Management Information Base, or MIB, describes
these objects. The MIB is structured as a hierarchical tree where the objects containing the
actual data are the leaves. Each managed object is assigned an Object Identifier, a unique
identification that represents where in the tree the object can be found. [15][16][17]
25
Managing Communication Resources
________________________________________________________________
A typical SNMP scenario would be: A Network Management Station wants to know the
status of a specific printer on the network. The station retrieves the object identifier for the
status field of the printer from the printers MIB. It then issues a get operation to the actual
SNMP agent representing the printer with the Object Identifier as a parameter. The agent
retrieves the value of the printers status object from its database and sends the value as
response to the management station.
The Structure of Management Information, or SMI, defines the rules for describing
management information in SNMP. This means that SMI specifies object name (OID), data
type (integer, string, etc) and encoding (how information is serialized for transmission
between machines). SMI is described with ISO’s standard ASN.1, or Abstract Syntax
Notation 1, format. [13]
As explained earlier the evolution of SNMP has generated several different versions. The
differences of these are outlined below. DISMAN and RMON, Remote MONitoring
[4.2.2.6], are two different standards that have been “born” around SNMP in order to fulfill a
need. They can be thought of as extending the functionality of SNMP in a standardized way.
4.2.2.2 SNMPv1
SNMPv1 is the first implementation of the SNMP protocol and most widely used today.
The almost complete lack of security, only a community name used as password, is one of the
main reasons for criticism of this version. [14][19]
The messages exchanged between agent and manager is called Protocol Data Units or
PDU’s. SNMPv1 uses four different types of PDU’s. Two of these are for reading data, one is
for writing, and the last is the trap, or notification, used by an agent to notify a manager of an
event.
26
Managing Communication Resources
________________________________________________________________
These PDU’s are used for the following operations [16]:

GET - A manager retrieves the value of a specified object from an agent.

GETNEXT - A manager retrieves the value of the next object in a table or list within an
agent.

SET - A manager sets the value of a specified object in an agent.

TRAP - An agent sends a notification to inform a manager of some event.
4.2.2.3 SNMPv2
Since the second version was never fully agreed upon and thus never formally
standardized, several proposed versions appeared. This paper only looks at the most prevalent
of these, namely v2c and v2u. A feature common to both of these is the introduction of TCP
support. The main difference between the two is the security model used.
SNMPv2 introduced two new operations [16]:

GETBULK – Used by a manager to retrieve a bulk of information at once.

INFORM – Enables a manager to send messages to another manager.
The SNMPv2c version uses a community based security model. This is the same security
model used in SNMPv1. Basically a community string is passed along as a common
“password” between the manager and the agent. [14][20]
The SNMPv2u version uses a user based security model. This has been published as an
experimental protocol in the USEC specification. [82] The USEC specification is defined in
two documents known as “An Administrative Infrastructure for SNMPv2” and, “The Userbased Security Model for SNMPv2”. [14][20]
SNMPv2c is more widely supported then SNMPv2u.
27
Managing Communication Resources
________________________________________________________________
4.2.2.4 SNMPv3
SNMPv3 was introduced to solve the security problems of the earlier versions. The
important services that are used to achieve this are authentication, privacy and access control.
This is the most current version of SNMP. It has not been able to gain widespread acceptance
yet.
The authentication is used to verify that a message actually came from the given source.
The privacy is attained through encryption of the SNMP messages. The traffic is encrypted
with DES, Data Encryption Standard. This prevents eavesdropping of messages by
unauthorized hosts. Access control enables an agent to allow different levels of access to
different managers. [18] All these are vital security issues that were missing from the earlier
versions. [21]
4.2.2.5 DISMAN
The name DISMAN comes from DIstributed MANagement. It is an IETF framework that
has origins in the introduction of distributed management in SNMPv2. The DISMAN charter
[76] defines several MIB’s to address the needs of distributed management operations. [52]
They can be grouped into three different approaches to distributed management. [14]

MIB based
This is the standard MIB approach. It resembles the manager-to-manager functionality
introduced in SNMPv2. The approach uses two different MIB’s. The Event MIB and the
Expression MIB. [14]
28
Managing Communication Resources
________________________________________________________________
Figure 4-1 [14]
The Event MIB defines a way to monitor MIB objects, either remotely or locally.
Triggers can be defined to take action when certain changes occur. A notification can then
be generated or a set operation performed. [14][52]
The Expression MIB is intended to move some of the information processing usually
performed by the manager to the agent.[52] The results evaluated expressions are MIB
objects. These custom-defined objects are thus usable anywhere any other MIB object can
be used. They can be utilized by a management application directly or referenced from the
Event MIB. [88]
The Notification Log MIB defines a way to deal with the loss of notifications by
recording each notification data. [52]

Script based
The Script based approach relies on the Schedule MIB and the Script MIB. This
approach allows a distributed manager to store and retrieve scripts making the
functionality definable at run-time. [14][52]
29
Managing Communication Resources
________________________________________________________________
Figure 4-2 [14]
The Script MIB module allows the delegation of management functionality to other
distributed managers. The functionality is defined in scripts. The scripts may be defined in
a scripting language or native code as long as the remote site is able to execute it.
The Schedule MIB allows for the scheduling of periodic or dated actions. The actions
are set operations on local MIB variables. To perform more complex actions a
management script can be triggered. [14][52]

Remote operations based
The Remote Operations MIB defines a standardized way of performing remote
network tests. [52] It allows a remote host to perform the ping, traceroute, and name
lookup commands. [14]
30
Managing Communication Resources
________________________________________________________________
Figure 4-3 [14]
4.2.2.6 RMON
RMON is an acronym for Remote MONitoring. It is a standardized specification for the
exchange of monitoring information. The standard is defined in a SNMP MIB that is
described by RFC 1757 [78]. [77] This RFC has now been made obsolete by RFC 2819 [79].
Usually MIB’s are created to support a specific type of network device whose primary
function is other than management. The RMON MIB however, was created to allow the
management of a network. It is most often used to collect a standard set of SNMP statistics
from network devices. [13]
Traditional SNMP agents are not capable of gathering most RMON data. RMON requires
special probe devices or functionality that can see a whole network segment. These collect
and forward RMON information. Such a probe can reduce network traffic by storing results
locally until they are requested by a management application. [81]
31
Managing Communication Resources
________________________________________________________________
4.3 Common Management Information Protocol
4.3.1 Background
Common Management Information Protocol, CMIP, is part of the X.700 standard of the
OSI Management Framework, also known as ISO/IEC 7498-4. Like most management
protocols it is comprised of a management application and management agents. CMIP has
many similarities with SNMP. It was developed in the late 1980’s with the intention of
replacing SNMP by making up for its deficiencies and shortcomings. Large corporations and
governments provided much of the funding for the work. Despite this, the protocol has never
achieved widespread availability except in the telecom industry. [22][24]
There are several reasons for the lack of acceptance. One is that CMIP was designed to
operate on the OSI protocol stack whereas most network environments today use TCP/IP.
Another reason is that CMIP is rather large and complex and it requires a fairly large amount
of system resources. Because of the complexity, maintaining a CMIP based network
management system often requires personnel with specialized training. This has in turn
resulted in very few implementations of CMIP. [24]
4.3.2 Description
Since CMIP was designed to replace SNMP by making up for its shortcomings, the basic
design is pretty much the same as that of SNMP. The general concept of a manager
communicating with one or more agents holds true for CMIP as well. It is an intelligently
designed protocol that defines the communication between a manager and a managed node in
an object-oriented fashion. [22]
CMIP was designed to run over the OSI protocol stack. The specification for using CMIP
over TCP/IP is called CMOT (CMIP Over TCP/IP). There are, however, few
32
Managing Communication Resources
________________________________________________________________
implementations that run on TCP/IP. This is one of the reasons the protocol has not been
widely used in LAN environments. [24]
Variables, or objects, in CMIP can be seen as complex data structures. Just like in SNMP
there are variable attributes and notifications, but there is also the ability to define variable
behaviors in CMIP. These are actions that are triggered according to the value of a defined
variable attribute. [22]
GDMO, Guidelines for the Definition of Managed Objects, is a standard that is used to
define the managed objects in CMIP based systems. Like in SNMP, the object definitions
make up a management information base, MIB. This MIB is described using GDMO. It can
be compared with the use of SMI in SNMP based systems. GDMO makes use of ASN.1 for
the definition of syntax and attribute encoding rules when defining the objects. [26]
The GDMO specification has to be transformed manually into programming language
implementation. GDMO is by many considered to be a verbose notation. The argument is that
even the simplest specification looks very complicated when defined in GDMO. [27]
The following operations are supported by CMIP [22]:

SET - set a value to a object

GET - retrieve a value

CANCEL_GET - cancel a GET operation

CREATE - create an instance of an object

DELETE - delete an instance of an object

REMOVE - remove data from attributes

ACTION - request that an action defined by an object occur

EVENT_REPORT - an agent notifies a manager of a significant event
The network management application can use the ACTION operation to set conditions
which tell an agent that it wants to be notified when specified conditions are met. The agent
will then respond with an EVENT_REPORT notifying the management application when this
condition is fulfilled. [24]
33
Managing Communication Resources
________________________________________________________________
It is important to note that CMIP does not specify any functional areas of the network
management application. Only the way the information is exchanged between the manager
and the managed objects is defined. [24]
A major shortcoming of early versions of SNMP that has been addressed in CMIP is
security. There are security features in CMIP to support authorization, access control and
security logs. The CMIP model is also object-oriented which is often a preferred model by
developers these days. Another shortcoming of SNMP, that has been addressed, is the ability
of the manager to tell the agent when it wants to be notified. In SNMP this would typically
require the manager to poll the agent periodically to find this out. [22]
On paper CMIP appears solid, however, as often in reality, the truth is another. The major
drawbacks of CMIP is that because of the complexity it requires a lot of resources and is
difficult to program. This has led to very few implementations outside of the
telecommunications market. [24]
34
Managing Communication Resources
________________________________________________________________
4.4 Remote Procedure Call
4.4.1
Background
Remote Procedure Call, or RPC, allows one program to make use of a function from
another program located somewhere else on the network. It is based on a client/server
infrastructure. The RPC concept has been around for a long time. The first implementations
started to appear in the late 1970’s and early 1980’s. Today there are two different RPC
implementations that are in widespread use. [28][35] One of these is the RPC functionality
implemented in the Distributed Computing Environment’s, or DCE. DCE is a set of
distributed computing technologies developed by the Open Software Foundation. [33] The
other prevalent implementation is found within Open Network Computing, also known as
ONC. Work on this implementation was originally initiated by Sun Microsystems in the mid
1980’s and then handed over to the IETF for the purpose of standardization. Implementation
exists for virtually all flavors of the UNIX operating system as well as Microsoft Windows
and others. [29]
4.4.2 Description
RPC uses a client/server model where the client is the program calling the function of the
remote program which is the server. Most available RPC implementations use a synchronous
protocol. What essentially occurs is that the client sends a request to the server, telling it to
perform a certain function. The server performs the function then answers the client program.
While the client is waiting for the server to finish, it is in a blocked state, just like a local
function/procedure call. This can of course be avoided by employing things such as threads
but it does increase the complexity of the application. Asynchronous implementations of RPC
do not block the client after a request has been issued. They are however, very scarce at the
moment. [28][29]
35
Managing Communication Resources
________________________________________________________________
Figure 4-4
The RPC implementation hides the networking details from the application programmer.
To successfully compile a program that uses RPC, a stub is included. This stub appears to the
program as the remote procedure. During execution the program calls the procedure and the
stub receives the request. The stub then sends the request to a client runtime program. This
program knows where and how to communicate with the server on the remote host. Finally
the runtime transmits the request over the network to the remote host. [35][34]
The server includes a runtime program and stub that interface with the remote procedure
itself. Results are returned in a similar fashion. The routing tables used by RPC are static, and
thus cannot be changed after compile time. [34][35]
RPC is the management interface in the Desktop Management Interface, DMI, from
DMTF, Distributed Management Task Force [4.5.1]. This is a standard way to manage
desktop workstations. [89] It is not, however, widely adopted.
36
Managing Communication Resources
________________________________________________________________
CORBA, Component Object Request Broker Architecture from the Object Management
Group, COM+ from Microsoft, and Java RMI from Sun are all examples of Component based
middleware that make use of the RPC paradigm. These are perhaps the more commonly
deployed technologies for remote execution today. CORBA is a platform independent
standard and will be discussed further in the mobile agent section below. COM+ is
Microsoft’s own component based framework and like most other Microsoft technologies it
only runs on their own platforms. Java RMI is the remote execution framework included in
Java. In later versions of Java CORBA is also being supported.
37
Managing Communication Resources
________________________________________________________________
4.5 Web-Based Enterprise Management
4.5.1 Background
Web-Based Enterprise Management, or WBEM, is an industry standard maintained by the
DMTF. DMTF is an industry consortium in charge of development of management standards.
The development of WBEM was originally initiated by a group of companies consisting of
Microsoft, Intel, Compaq, Cisco and BMC with the goal of producing a framework for objectoriented system management over the Internet. In 1998 the companies decided to transfer the
development of WBEM to the Distributed Management Task Force. [42] There have been
concerns about the involvement of Microsoft in the standard since they are known for
defending their own proprietary solutions instead of supporting open standards. [36]
4.5.2 Description
WBEM was designed to prescribe enterprise management standards that work with
existing network management standards like CMIP, SNMP and DMI [40]. A goal of the
project was to provide a common information model for management. This information
model is referred to as the Common Information Model, or CIM. [42][38]
CIM is a conceptual information model. It is comprised of two parts, a specification and a
schema. The CIM Specification refers to the formal definition of the model. This specification
describes the language, naming and mapping techniques used to link CIM with other
management models. The CIM Schema is the actual content. It describes the actual classes
and relationships of the model. [43][37]
The CIM Schema is divided into three layers, the Core Model, the Common Models and
the Extension Models. These models are all defined in UML by the DMTF. [40]
38
Managing Communication Resources
________________________________________________________________
Figure 4-5 [42]
The Core Model represents the notions that are generic to all management environments.
The model is comprised of a small set of classes, associations, and properties that are
common to all managed environments. [40]
Figure 4-6 [90]
39
Managing Communication Resources
________________________________________________________________
Elements that a system consists of can be either logical or physical. Logical elements are
abstractions often used to represent the capability or state of a system. Physical elements are
elements that occupy physical space.
The Common Models are defined to address specific areas. The Common Models are
Systems, Devices, Networks, User, and Applications. These represent the corresponding
devices they are named after. An application is abstracted by an application model and so
forth.
The Extension Models are defined as additions upon the Common Models. These models
are even more specific then the Common Models. They often have close ties to certain
environments, such as operating systems like UNIX or MS Windows. [40]
Figure 4-7 [91]
The transport mechanism used in WBEM is referred to as “CIM Operations over HTTP”
and is specified by the DMTF. This specification maps CIM operations onto the HTTP
protocol. The encoding specification is called xmlCIM. It is used to define XML elements
40
Managing Communication Resources
________________________________________________________________
that represent CIM classes and instances. [37][43] XML stands for eXtensible Markup
Language. It is used to represent structured data in text.
WBEM has potential to unify the network management world under one information
model. It can integrate with existing platforms such as SNMP and CMIP. With companies
such as Cisco and Microsoft pushing for wide implementation it has as good backing as any.
Presently the real world implementations of WBEM are scarce.
41
Managing Communication Resources
________________________________________________________________
4.6 Mobile Agents
4.6.1 Background
A problem with many of the traditional network management solutions in wide spread use
today is their centralized client/server nature. The most popular solution, SNMP, is a very
good example of this paradigm. (Note: with the exception of DISMAN) SNMP agents are
servers from which clients can access specific information defined in MIB’s. These MIB’s,
and other agent services, are defined during the design of the agent. Often the SNMP network
management station, or client, can only invoke agent services defined in general-purpose
interfaces. This leads to a large number of interactions where the manager has to take the
agents through the steps involved in gathering information and taking management action. In
essence the manager is controlling the remote execution every step of the way. This is
referred to as micromanagement. [44]
The type of centralized platform found in SNMP creates a vulnerable network management
system by relying to heavily on the availability of the network management station. If this
station becomes unavailable to the agents, they will be unable to perform recovery operations
because these operations essentially have to be initiated by the network management station.
[44]
As the network grows and more devices need to be managed bandwidth consumption
becomes an increasing problem for the network management station.[62] Increased
bandwidth can cause the network management station to become unavailable for the agent.
This is because the network management station becomes a bottleneck, as all management
information and decisions has to pass through it. As a result, the agent is prevented from
performing recovery operations.
These scalability and flexibility issues have created a demand for decentralized network
management systems. There are many different approaches to the problem. Systems based on
CORBA [73], Active Networks, Intelligent Agents, Mobile Agents, or a combination of these,
42
Managing Communication Resources
________________________________________________________________
are some of the more commonly proposed solutions. [66] A lot of effort has also gone into
trying to decentralize SNMP management. (DISMAN, etc. See SNMP section of this paper)
4.6.2 Description
In order to describe a mobile agent it is a good idea to explain what a software agent is.
This can be a controversial matter. [72] A definition favored by the author is used [68] to
define a software agent, as a computational entity, which acts on behalf of others, is
autonomous, proactive, and reactive, and exhibits capabilities to learn, cooperate and move.
To find out more about the many classifications and definitions of software agents refer to
[56].
Building on the earlier definition of a software agent, a Mobile Agent can be defined as a
software agent that can move between locations. [68] A more generalized description of a
Mobile Agent is: a small software program that is able to migrate between hosting computers
during its execution whilst maintaining across the network. [66]
FIPA and MASIF are the two common standards that exist in the agent field. FIPA stands
for the Foundation for Intelligent Physical Agents. It is actually an organization that produces
standards aimed at interoperability between different software agents. Their work has a strong
focus on intelligent agents rather than mobile agents. MASIF, Mobile Agent System
Interoperability Facility [4.6.4], on the other hand is a standard for mobile agents. It focuses
on interoperability between different mobile agent frameworks. MASIF will be described in
this paper as it deals directly and specifically with mobile agents. The proposals put forth by
FIPA will not be discussed. To read more about FIPA see [87].
43
Managing Communication Resources
________________________________________________________________
4.6.3 Agent Mobility
4.6.3.1 General
The obvious function that separates a mobile agent from a stationary agent is the agent’s
ability to move. A mobile agent can migrate from one node to many others during its lifetime.
During this migration, both the code and the current state of the agent, have to be transferred.
Without both of these, the agent cannot resume execution in the right place once it arrives at
the destination node. The state of an agent can be described as two parts, the data state and the
execution state. The data state is defined as the arbitrary content of the global or instance
variables while the execution state is the content of the local variables, parameters and
execution threads. There are two degrees of mobility. These are referred to as strong and weak
migration. [58]
4.6.3.2 Strong Migration
Strong Migration is the highest degree of mobility. When a mobile agent migrates using
strong migration both the agent code and the entire agent state is transferred to the new
location. The entire agent state is the agent’s data state and execution state. The state of the
agent is then restored once it arrives at the destination. This requires a fair amount of
resources for the agent platform, but makes things simple for agent developers. [58][36]
4.6.3.3 Weak Migration
The Weak Migration scheme differs from the strong migration in that only the agent’s data
state is transferred along with the code. This approach requires fewer resources for the agent
platform than the strong migration scheme. However, it also means that the agent developers
have to save data pertaining to the agents execution state in variables. [58][36]
44
Managing Communication Resources
________________________________________________________________
4.6.4 OMG MASIF
4.6.4.1 Background
MASIF stands for Mobile Agent System Interoperability Facility. It is the first standard
concerning mobile agents and is maintained by the Object Management Group, or OMG. [59]
OMG is the same group that maintains the CORBA standard. [73] The basis for MASIF is to
provide a platform neutral standard for interoperability between mobile agent systems. [68]
When the OMG first requested proposals for a mobile agent framework they outlined
several requirements that had to be met in order for the framework to be accepted:

Marshalling and un-marshalling of agent programs

Encoding of agent containers for transport

Transport of agents from one agent facility to another

Runtime registration and invocation of agent facilities

Runtime query of named agent facility by agents

Runtime security of agents
In 1997, Crystaliz, General Magic, GMD FOKUS, IBM and The Open Group submitted a
joint standard for mobile agents to OMG. This was approved by a vote in 1998. The current
specification is dated 00-01-02.
The concept behind this standard was to achieve some degree of interoperability between
different mobile agent platforms. MASIF was never intended as a basis for a mobile agent
platform. It was designed to provide a specification which existing systems could utilize as an
“add-on” to reach greater interoperability. [57]
MASIF relies heavily on the CORBA. [55] This architecture allows applications to
communicate with each other in a network even if they are from different vendors. CORBA
uses an Object Request Broker, or ORB, to establish client/server interactions. A client may
use an ORB to transparently invoke a method on a server object. This server object can be
located on the same machine or somewhere else on the network. The ORB intercepts the
45
Managing Communication Resources
________________________________________________________________
method call from the client. It locates the server object, calls the method and passes the
parameters to the server object. Finally it relays the results of the method back to the client.
The client does not have to be aware of the location of the server Object, it’s implementation
details such as programming language, operating system or anything else that is not part of
the systems interface. A more detailed description of CORBA is beyond the scope of this
paper. For more detailed information about CORBA and related resources see [73].
4.6.4.2 Description
The model of the distributed agent environment in MASIF consists of agent, agent system,
place, region and finder. An agent is a mobile agent. An agent system is the platform where
the agents execute. A place is a context within an agent system in which an agent is executed.
A finder is a registry for locating agents, places, and agent systems. A region is a set of agent
systems with a finder. [55]
MASIF provides for each mobile agent or group of mobile code to identify itself with
either a language or execution environment requirements. This enables interoperability
between different platforms. [68]
The MASIF standard addresses the following areas of mobile agent technology:

Agent Management
Agent management provides a way for an agent system to control agents from another
agent system. MASIF solves this by relying on interfaces. These interfaces define actions
for suspending, resuming, and terminating agents. [55]

Agent Tracking
Naming Services of different agent systems are utilized to register agents and thus
enabling them to be traced. [55] For this an interface called the MAFFinder interface is
used. This interface provides the ability to register agent systems, places, and agents in a
region registration component. Agencies and places are only registered once. Mobile
46
Managing Communication Resources
________________________________________________________________
agents on the other hand, are de-registered before they migrate then registered again once
they arrive at their new location. Any agent within the region can be located by using
lookup methods provided by the MAFFinder interface. [57]

Agent Transport
MASIF provides methods for receiving agents and fetching their respective classes.
[55] These methods are defined in the MAFAgentSystem interface. [57]

Agent and Agent System Naming
MASIF specifies a standardized syntax and semantics used to name agents and agent
systems. This allows agents and agent systems to identify each other and allows clients to
identify agents and agent systems. [57]

Agent System Type and Location Syntax
The agent system types give information related to specific aspects of agent systems.
An agent has to determine whether or not the agent system that it is about to migrate to
supports the execution of this agent. If it does not, then the agent may not migrate to that
specific destination. The location syntax is also has to be standardized so the agent
systems can locate one another. [57]
47
Managing Communication Resources
________________________________________________________________
Figure 4-8 [57]
The MASIF standard specifies how existing CORBA services can be utilized by
components in agent systems to provide better functionality. The MAFFinder and the
MAFAgentSystem CORBA interfaces make up the core of the MASIF standard. As
mentioned earlier, the MAFFinder interface supports the localization of agents, agencies, and
places that reside within the same region. It is a registered CORBA object so a client can use
the interface methods to locate and communicate with an agent. The MAFAgentSystem
interface provides operations to transfer and manage agents. [68]
For a more detailed description of the interfaces, see the current Mobile Agent Facility
Specification available from the OMG.
4.6.5 Mobile Agents for Managing Networks
4.6.5.1 General
The area attracting the most interest from researchers within the network management field
is management based on some form of strongly distributed paradigm. Goldszmidt [44] laid
48
Managing Communication Resources
________________________________________________________________
down the ground for the research in this area. He proposed a framework called Management
by Delegation. The idea behind this research was simple. As the resources and power of
networked computer systems and devices increased, the processing could be moved out from
the management stations to the agents.
The idea of mobile code for network management was introduced in the Management by
Delegation framework. Mobile agents, in the sense of network management, are in theory
based on the mobile code paradigm. The basic idea behind the mobile code paradigm is that
programs can be dynamically transferred to management agents whom in turn can execute the
programs. [36]
There are currently many different people and places involved with researching Mobil
Agents for Network Management systems, such as the Network Management and Artificial
Intelligence Laboratory in the Department of Systems and Computer Engineering at Carlton
University in Canada. The main idea behind mobile agents in this field is to get the
management intelligence out to where it is needed. This means that instead of a central
manager polling a node for information and deciding what should be done after examining
that information, a mobile agent is dispatched to a node. The agent gathers and examines the
necessary information then decides what should be done. [64]
In SNMP, the MIB structure is implemented by the SNMP agent code. This results in a
“hard coded” agent that cannot be changed at runtime. A mobile agent can be removed and
another agent, with other functionality, can be created and deployed with minimum
interruption, if any, to the rest of the system. This significantly increases the management
flexibility. [48]
4.6.6 Advantages of Mobile Agents
4.6.6.1 General
In order to provide more detailed information about the benefits of using mobile agents to
manage a network, the paradigm can be analyzed for the functional areas described in the OSI
49
Managing Communication Resources
________________________________________________________________
management model. [68] The usage of mobile agents within three of these areas will be
examined here. Accounting Management and Security Management with mobile agents will
not be discussed.
There are many types or classifications of mobile agents. This paper will only discuss two
of them. These are deglets or netlets. Deglets are sent to a remote location with a certain task
to perform. Once the task has been performed and the agent has achieved its objective it
terminates. The name deglet comes from delegation of authority. The name netlets comes
from network agent. Netlets are persistent agents that migrate between network elements and
executes on each of them. [73] They are used to perform delegated tasks of a more permanent
nature. Netlets are considered a part of the network infrastructure. [68]
4.6.6.2 Fault Management
Fault management is an example of a discovery task. The fault has to be located before it
can be recovered. A mobile agent can detect faults by constructing a specialized model of the
network. If a violation of what the agent believes to be normal behavior is detected then the
agent initiates a fault detection function.
Once a fault has been detected the agent may ask for a special network repair agent to
attempt to recover from the fault or it may attempt to perform the recovery operation itself if
possible. If this recovery is unsuccessful or is beyond what the agent can handle, i.e. requires
human involvement, the network manager would be notified.
An example of using mobile agents in the fault management area: A mobile agent can
perform selective discovery of nodes with excessive utilization and use this information to
build a model of over-utilized nodes. [68][54]
50
Managing Communication Resources
________________________________________________________________
4.6.6.3 Configuration Management
Mobile agents are useful in the implementation of plug-and-play network components.
Often a manager has to perform all of the required tasks manually. With mobile agents a
network can get closer to a self-configurable network. Adding a new printer to a network is a
good example. In order to use the printer the workstations on the network have to have the
drivers for the printer. The workstations in the network environment run different operating
systems. A few might be UNIX workstations while others are from Apple, running MacOS,
and some are PC’s running different versions of Microsoft Windows operating system. This
creates a heterogeneous network environment not unlike what exists in many organizations
today. Mobile agents can be used to detect and identify the new printer. They can then
distribute the correct drivers to the appropriate workstations by migrating to them. Lets
assume the network is connected to the Internet. Then the agent could retrieve the correct
driver from the printer manufacturer via the web. [68]
4.6.6.4 Performance Management
In a centralized network management system it is often hard to measure the actual
performance of various aspects of the network. This is an effect of the delays that are present
in the centralized systems. The manager has to poll for the necessary information and then
analyze it. This has an impact on the precision of the measurements. A mobile agent, on the
other hand, can be dispatched to the node to both gather and analyze the information thus
eliminating delay and increasing precision. Using mobile agents to measure network
performance may hamper the actual performance if too many agents are deployed into the
network. It is therefore important that the infrastructure puts reasonable limits on the
deployment of mobile agents as precaution. [68]
51
Managing Communication Resources
________________________________________________________________
4.6.7 Problems with Mobile Agents
4.6.7.1 General
The biggest cause for concern in mobile agent systems is security. [74] Extensive research
is conducted in this area and the subject is too complex for this paper. Simply put: the security
problem can be eliminated if no hostile agents are allowed to enter the network. The second
biggest cause for concern is the danger of agents flooding the network. [74]
4.6.7.2 Agent Flooding
Agent flooding occurs when migrating agents use too much of the networks bandwidth.
One of the causes for this is when agents are allowed to live forever. The agents then roam
around the system often outliving their usefulness. This costs system resources as well as
bandwidth. Another cause for flooding is when agents are allowed to produce child agents.
These child agents can quickly cause flood related problems and heavy resource consumption,
if they behave in the same manner as their parent agent. [96]
In order to prevent flooding a mobile agent system has to guarantee that once an agent has
outlived its usefulness it will return home or die. One way to accomplish this is to give the
agent a time-to-live, similar to the way the IP protocol handles datagrams. The side effect of
this solution is that agent cannot roam around the network forever, which is sometimes
preferable. [97]
The system may also have density checks in place. If too much traffic is detected from a
particular type mobile agent then some of these agents are intercepted and destroyed. If the
density is too low then agents can be injected into the system. [74]
Another solution is to let the originating node decide when an agent has outlived its
usefulness. The down side to this is that it can be difficult for this node to know when to
52
Managing Communication Resources
________________________________________________________________
terminate the agent. It also means that a node has to have knowledge of where the agents
originating from the node are, or at least be able to contact them.
If an agent is allowed to produce child agents then their lifecycle has to be determined as
well. One solution is to let their life be controlled by their parent. When the parent dies so
does the child, or if the parent decides that the child agent has outlived its usefulness then the
parent can terminate the child. This does however imply that the parent is able to locate the
child agent. [96]
4.6.8 Integration with legacy technologies/protocols
4.6.8.1 General
In order for mobile agents to be able to communicate with the managed devices in current
networks they must be able to interface with the devices. The simplest way to do this is to use
one of the legacy protocols that the device already supports. This requires the mobile agent to
be equipped with the functionality to communicate via these legacy protocols.
The two most commonly deployed management protocols in use are SNMP and CMIP.
Since the SNMP protocol is the most commonly used protocol in IP based networks, a mobile
agent that operates in such a network should be able to interface with a traditional SNMP
agent. CMIP implementations are usually limited to telecommunications networks and
therefore this paper will not examine the interoperability between CMIP and mobile agents
any further, but the principles are very similar to the SNMP interoperability.
4.6.8.2 Integration with SNMP
There are three areas where SNMP support can be beneficial to a mobile agent system. The
first area is allowing mobile agents to interact with SNMP agents. This requires some sort of
SNMP manager functionality to reside in an agent system. The second area is being able to
53
Managing Communication Resources
________________________________________________________________
use SNMP manager to communicate with mobile agents, and the third is the ability to
administer the mobile agent platform using SNMP. [84]
The former two areas are important in order to use legacy management systems side-byside with the mobile agent platform. Providing mobile agents access to SNMP agents is
important in order for mobile agents to manage existing devices that currently utilize SNMP
agents. This requires a part of the mobile agent system to act as SNMP manager towards
legacy agents. This information is then relayed to interested mobile agents throughout the
region.
This manager may in it self be a mobile or stationary agent. An agent system might have a
stationary agent that communicates via SNMP with a SNMP agent from a device connected to
the system. This stationary agent could be a mobile agent that has been dispatched to the
agent system but which does not migrate further. A mobile agent could communicate with the
stationary agent using inter agent communication. The stationary agent would then in turn
pass the instructions on to the SNMP agent via SNMP. The SNMP agent would respond to
the stationary agent that would communicate back the results to the interested mobile agent.
If the SNMP agent does not have any defined traps, a stationary agent would not be
required at all. However, in order to receive traps from the SNMP agent, a stationary agent
would be required to stay at the same agent system and listen for incoming notifications.
Mobile agents could then register for traps they are interested in and the stationary agent
could in turn let them know when it has received a trap that interests a particular mobile
agent.
The JAMES mobile agent platform [85][86], developed by the University of Coimbra and
Siemens, use a similar scheme to provide interoperability with legacy SNMP agents. This is
described further in [66] and [84].
54
Managing Communication Resources
________________________________________________________________
4.6.9 Agent Platforms
There are a few commercially available mobile agent platforms on the market today. None
of these are however, primarily focused on network management. Most are java based
because of the many advantages offered to a mobile agent platform by java, in particular
platform independence.
Some of the more prominent platforms are:

Aglets SDK from IBM

Grasshopper from IKV [94]

Jumping Beans [95]

The Voyager System [93]
55
Managing Communication Resources
________________________________________________________________
5 Review/Evaluation
5.1 General
The MSBL communications system has certain needs outlined in above sections. FMV, the
government agency that purchases the equipment and has contracted Data Unit to develop
MSBL, also has some requirements and wishes for the management solution. The
management solution is referred to as “Management interface for MSBL” in the internal
documentation.
FMV have placed the following requirements on the management solution:

The interface should be standardized and well documented as to easily enable further
development and interoperability in the future.

The management solution should consume as few internal project resources as possible.
(Read: should be as cheap for them as possible, the “money vs. all else” argument)

Possible future devices and alternatives should be simple to implement into the system.

The network that handles the management traffic will be secure. This means it is assumed
that the network is free from any hostile party whatsoever.

The interface should fit nicely with the component and object oriented model used in
MSBL.

The resource consumption should be kept at a reasonably low level.
56
Managing Communication Resources
________________________________________________________________
5.2 SNMP
5.2.1 General
When evaluating SNMP for use in any system it is important to take into consideration the
different versions of the framework. While SNMPv3 might seem like the obvious choice that
is not the case. This is because it has not been widely deployed yet. SNMPv1 still holds the
throne as the most popular management solution in IP based networked environments. As a
result of this many applications only contain support for SNMPv1 and perhaps one of the
SNMPv2 versions but SNMPv3 support is still lacking in most places.
MSBL will communicate with the managed systems over a secure network. Secure in the
meaning that there will be no hostile hosts on the network. Since SNMPv3 is basically
SNMPv2 with security and access control and MSBL does not consider management protocol
security a major concern, SNMPv2 and SNMPv3 can be looked upon in an either/or kind of
way.
5.2.2 Positive aspects
SNMP is a widely used standard. Many developers are familiar with how it works and
there are plenty of development resources available. In IP based networks, SNMP is the
“defacto” management standard.
Since it is such a widespread standard, there are many tools available to aid in the
development of SNMP. MIB specifications for the agents are not simple but there are plenty
of tools that simplify the design of these as well. API’s for implementing programs that
communicate over SNMP are available in many different languages and varying price ranges.
This significantly simplifies the development of the maneuvering servers in MSBL.
57
Managing Communication Resources
________________________________________________________________
While not object oriented, SNMP can be made to appear as though it were through the use
of clever development. The functionality of get and set can easily be hidden behind object
method calls. The object/component modularity is a big part of MSBL and therefore SNMP
could be made to fit into the design in a “pretty” fashion.
Some of the systems MSBL will manage are already being developed to use SNMP. This
means a maneuvering server might not be needed for these if the decision to use SNMP is
made. This would require less work, which in turn means less human resources.
One consideration in the protocol decision is the ability to manage the maneuvering servers
from other systems. There are many off-the-shelf management software applications, such as
HP Openview, that support SNMP management.
5.2.3 Negative aspects
MSBL is very much designed as an object oriented and component based system. SNMP,
on the other hand, is not an object-oriented protocol by design. This could lead to an “ugly”
patchwork to an otherwise nicely laid out object-oriented system if proper care is not taken
during the design.
SNMP, especially SNMPv1, is not exactly a bandwidth efficient protocol. MSBL will be
managing all currently planned systems over 10+ Mbit Ethernet connections. This will most
likely be sufficient bandwidth to handle a few maneuver servers but it will not scale as well as
some of the other alternatives. It is also worth noting that if it is decided that MSBL is going
to manage other legacy or future systems that use other interfaces besides Ethernet, one with
lower available bandwidth, then this could turn out to be a bottleneck in the management
system.
58
Managing Communication Resources
________________________________________________________________
5.3 CMIP
5.3.1 General
MSBL is ultimately concerned with managing the radio stations and other devices used to
transmit information. Because the CMIP framework is a telecommunications standard and
widely adopted within the telecommunications industry, some of this equipment might
already be manageable by CMIP. MSBL will never talk to them directly but instead, it will be
communicating with the systems described earlier. None of these presently support CMIP.
This is important to keep in mind when evaluating CMIP for use within MSBL.
5.3.2 Positive aspects
Presently no known apparatus that need to be managed from MSBL communicate by
CMIP, there is always a chance that MSBL will have to be able to manage some devices or
systems in the not-too-distant future that utilize CMIP. The manager within MSBL will run
on a PC with plenty of resources. This means that the manager (maneuvering client) will have
enough resources to run CMIP properly.
The
CMIP
framework
is
standardized
by
ISO
and
the
ITU,
International
Telecommunications Union. This has lead to support in off-the-shelf management software
like HP Openview. This may not seem important since MSBL will be the management
software but this can only be a good thing when considering the management needs might
change in the future. If, or rather when, that happens there will be options available.
The security model in CMIP is strong. Although the security aspects of the management
protocol are not a main concern for MSBL, extra security should always be welcomed.
CMIP is an object-oriented framework. This fits nicely with MSBL since it has been
designed as a component based object-oriented system.
59
Managing Communication Resources
________________________________________________________________
5.3.3 Negative aspects
The resource consumption of CMIP might cause a problem on the maneuvering servers in
MSBL, but most likely not. MSBL will utilize fairly modern PC machines as maneuvering
servers. These are expected to contain enough resources to handle the consumption of CMIP.
In the future, other hardware or devices may be deployed which do not contain the amount of
resources needed to sustain a CMIP based agent.
CMIP is a complex protocol. This makes the implementation of CMIP a complicated
procedure that will in most cases require extensive new skills from the developers and
programmers involved with the project. The current members of the MSBL project group
have little or no knowledge of the CMIP framework. Inevitably this will lead to higher
development costs, which should always be minimized.
Although it is a standard, CMIP is not widely adopted in IP networks. This is not a real big
problem in itself, more of a cause to the small selection of tools available to aid developers.
This in turn could be a major concern.
GDMO is a not an easy notation to understand. Defining the structures required for MSBL
in GDMO and then manually implementing them from the specification is a complex task.
This will consume time. It will also require knowledge that is not present in the current
project group.
60
Managing Communication Resources
________________________________________________________________
5.4 RPC
5.4.1 General
MSBL is going to manage ICS 2000. This system currently uses RPC for remote
management operations. This means RPC will be an issue regardless if it is chosen for the
management framework or not. If it is not choosen, then the maneuvering server for the
ICS2000 will have to proxy between the management protocol and RPC operations.
Other middleware that relies on the RPC paradigm such as CORBA, Java RMI, and
Microsoft’s COM+ architectures can be considered for management operations in MSBL. The
system already relies heavily on COM+ for other functionality.
5.4.2 Positive aspects
ONC RPC is standardized and there are implementations and development tools available
for many different platforms.
Management with RPC is fairly simple to understand in principle. Designing an objectoriented framework for RPC based management functionality doesn’t require knowledge of
MIBs, GDMO, SMI, etc.
COM+ is already used heavily within MSBL. Extending the use of this middleware to
handle the management functionality seems like a logical step from a development
perspective. This would make for a rather natural evolution of functionality that would fit
nicely with the rest of the system.
61
Managing Communication Resources
________________________________________________________________
The CORBA middleware architecture is a commonly recognized standard and not platform
dependant. A defined set of CORBA interfaces can form a definition of the management
functions.
5.4.3 Negative aspects
While RPC is standardized (ONC, RPC), using it to manage devices/systems in a network
is not. In order to gain some sort of conformity, a standard set of procedure calls would have
to be defined. These would have to be well documented for future interoperability.
The above statements are true for CORBA as well. While there are plenty of research and
some implementations using CORBA for management purposes, it is not possible to access
the remote components from a general-purpose manager as is possible with SNMP and CMIP.
A COM+ based solution would be even worse from the interoperability perspective. While
there exists workarounds to get COM+ components running on other operating systems than
Microsoft’s, they are exceptions. Microsoft designed COM+ for use on the different Windows
based systems and platforms. This is fine on the client end where MSBL will run on PC’s
with Microsoft Windows NT 4.0 installed. On the maneuvering servers, however, it is good to
keep as many options of operating systems or even hardware architectures as possible.
62
Managing Communication Resources
________________________________________________________________
5.5 WBEM
5.5.1 General
WBEM is a fairly new concept to many. This makes it hard to determine whether the
protocol will succeed or not. SNMP became popular in large part due to its own simplicity.
WBEM is a more complex solution, yet more modern and supports features missing from the
older management frameworks.
5.5.2 Positive aspects
WBEM is perhaps the most object-oriented solution of all the alternatives. This is ideal for
a system like MSBL that makes heavy use of object oriented and component based design.
With the backing of companies like Cisco and Microsoft it is hard, but not impossible, to
see how WBEM could fail to gain significant “market share”. These companies produce
products that make up a significant amount of many networks. If they implement WBEM in
their own products many other manufacturers would most likely follow suite.
The interoperability with SNMP and CMIP that WBEM attempts to support means legacy
protocols can still be managed with WBEM.
5.5.3 Negative aspects
To be fair, the WBEM framework has great potential. However, presently it lacks the
widespread deployment that SNMP has. It is still unclear whether the standard will actually
succeed in real world implementations.
63
Managing Communication Resources
________________________________________________________________
5.6 Mobile Agents
5.6.1 General
Mobile agents do not really fit into the criteria outlined by FMV. These criteria are
concerned with the interface used for management more then the actual solution. Mobile
agents do not employ the standard client/server relationship that is the basis of the
requirements for MSBL management.
MSBL needs to control specific aspects of specific radio stations and other devices in order
to establish communication channels. A mobile agent can be sent to a system for each active
transmission device in that system.
5.6.2 Positive aspects
Mobile agents place the management functions close to where they are needed. In the case
of MSBL, a mobile agent would migrate to maneuvering servers and communicate with the
transmission devices connected to the system. This would reduce network traffic from MSBL
to the maneuvering servers.
The major benefit of delegating management functionality from MSBL is fault recovery.
The system becomes less reliant on the maneuvering client in MSBL for recovering from
faults in the nodes. Once a mobile agent has migrated to a node it can detect and attempt to
recover from a fault without involving the maneuvering client.
There are commercial implementations of mobile agent platform that can be deployed
rather quickly. The maneuvering servers should be able to handle some of these effectively.
The amount of research concerning mobile agents for network management seems to
indicate that mobile agents have a future in the management field. While blindly following
64
Managing Communication Resources
________________________________________________________________
the latest trend is not be considered wise, supporting a possible, yet unknown, future device
is.
Achieving a high level security on a mobile agent platform can be tedious. Since the
management functions of MSBL operate over a secure network, the security aspects can be
given low priority.
5.6.3 Negative aspects
Mobile agents do not really define a standard interface for management. If the agent
platform is MASIF compliant the managing of agents is standardized via CORBA interfaces
but the actual management performed by the agents would still need to be defined. This is so
the systems, manageable by MSBL, can be managed by other applications without a lot of
extra implementation work.
The current mobile agent platforms are mostly used for research purposes. Actual “realworld” implementations of mobile agent platforms for network management are hard to find,
at least when compared with some of the other alternatives.
The resource consumption for a mobile agent platform is higher then any of the other
solutions. There is a possibility that this may cause a problem.
65
Managing Communication Resources
________________________________________________________________
6 Recommendation
6.1 General
The criteria for the selection of management protocol clearly show that SNMP has been
considered as the management interface by FMV. This gives the whole process a tipped scale
since another protocol essentially have to fill the criteria better a protocol that was considered
when deciding the specific criteria.
A solution based on SNMP is recommended for MSBL because:

Favored by FMV

Already used by some of the equipment/system manufacturers

Widely accepted standard

The network is considered secure, hence security within the protocol is not a major issue
The shortcomings of SNMP, namely the bandwidth usage and lack of security does not
appear to be major concerns for MSBL.
The “defacto” standard factor weighs in really heavily in the selection. If WBEM or CMIP
held this position in IP based networks then they would reap the benefits in terms of
development tools and more widespread knowledge about the respective platforms. This
would tip the scale over in their favor considerably.
Deciding which version of SNMP that should be used is tricky. SNMPv3 provides the
better security with authentication, privacy and access control. These however, are not major
concerns in the MSBL management environment and thus SNMPv2 might as well be used.
CMIP falls on the fact that it has not gained widespread use within IP based network
environments that in turn have lead to fewer development tools.
66
Managing Communication Resources
________________________________________________________________
RPC was a viable option and still is since it is already used in ICS2000. SNMP is favored
over RPC because SNMP allows management via off the shelf products where as RPC
requires a “custom” implementation in order to communicate via RPC.
WBEM has great potential as a management standard. The author got the impression that
WBEM is too complex and thus requires too much human resources. Since the standard has
not reached the acceptability that SNMP presently enjoys in networked environments, it is
hard to find tools that support it.
6.2 Mobile Agents in MSBL
When a transmission device is needed in MSBL, it is allocated on request. A mobile agent
can be used to represent an active device. When MSBL selects a transmission device, a
mobile agent is sent to the maneuvering server in charge of controlling that device. The agent
sits there until the device becomes inactive.
Another type of mobile agent could be used to roam the maneuvering servers testing
transmission devices for failures. When a fault is detected the agent could attempt to fix it. If
this fails it could notify MSBL that a device is not functioning correct.
The recommended SNMP based management system can be extended to use mobile
agents. This can be achieved in a relatively smooth way by setting up a mobile agent platform
that spans the maneuvering servers. The mobile agent would communicate via SNMP with
the stationary SNMP agent that resides on the maneuvering server.
In MSBL the SNMP management services are hidden behind device abstractions. This
means that the end user and higher implementations are only concerned with the device
chosen for transmission, how it is managed is not any of their concern. When the system
selects a device to transmit or receive on it sees this as an object representing for example a
67
Managing Communication Resources
________________________________________________________________
specific radio. It sets the parameters using the objects methods. The SNMP functionality lies
beneath this. This layer could be exchanged with new objects/components that would use the
mobile agent platform instead. MSBL could even manage some devices by SNMP and others
with mobile agents with this approach. This would have minimal impact on the rest of system,
in large part due to the modular design of MSBL.
Instead of using SNMP these objects would use some other interface, such as CORBA
method calls, to access the agent platform. Another way would be too use a proxy for the
SNMP communication from MSBL. MSBL would use SNMP much like it is recommended.
This SNMP communication would be toward a proxy, which in turn handles the mobile agent
communication and deployment. This solution allows MSBL to maintain full SNMP
functionality while also leveraging the advantages of mobile agents.
Presently however, a management system utilizing mobile agents whould be too much for
MSBL. The system operates on a small network closely conencted to the managed nodes.
Thus full-scale mobile agent system is not economically justifiable.
68
Managing Communication Resources
________________________________________________________________
7 Proposed solution
7.1 General
In order to test the desired management solution, a simulator has to be developed. The
simulator will be used to simulate the devices that do not presently exist for MSBL. These are
HF2000, VLF, and ICS2000. The simulator will simulate the maneuvering server and the
management interface will be SNMP.
7.2 Simulator
Some of the general requirements of the simulator are:

The simulator should be configurable to appear as HF2000, VLF, or RaSwitch (another
name for the ICS2000 system).

There should be a graphical MMI for locally controlling the aspects of the simulator.

The above includes setting a base value for a property of a device type and resetting or
assigning a new value to a property of a specific instance of a device.

All the management operations should be logged in a predefined format.
The first aspect involved in designing this simulator is to produce a MIB for the specified
systems. There will only be one MIB representing all the possible communications devices
that are managed by each system.
The MIB will have to contain tables for devices of the following types:

Very Low Frequency Radio (vlfRadio)
69
Managing Communication Resources
________________________________________________________________

High Frequency Radio (hfRadio)

Very High Frequency Radio and Ultra High Frequency Radio (vhfUhfRadio)

Crystal Controlled Radio (xtalRadio)

Antennas (antenna)

Modem (radioModem)

Communications Switch (commSwitch)
The MIB tree containing these device types will be structured under the enterprise node.
MIB’s normally have to be registered but not if they are located under the enterprise node.
The general information about the system will be found in an entry called rrcsIdent. Here
information about who made the system, what name and version it has, what version of
SNMP it uses etc will be found.
The next node is an entry called interface. This node contains an object, ifNumber, which
keeps track of the number of interfaces in the system. It also contains a table named ifTable.
This table contains general object pertaining to the status and type of the interface. It also
contains an index key, ifIndex. From this index and the type found in the table the specific
information contained in other tables can be gathered.
The other tables are grouped under nodes radioInterface and utilityInterface. Under the
first are vlfRadio, hfRadio, vhfUhfRadio, xtalRadio and antenna. Under the later are
radioModem and commSwitch. These tables contain specific information pertaining to that
specific type of device.
There is also another node called notification. Traps can be found under this node. There
are two traps for every device type. One for notifying of failed status and one for notifying
resurrected status.
rrcs
-rrcsIdent
-name
-etc..
70
Managing Communication Resources
________________________________________________________________
-interface
-ifNumber
-ifTable
-index
-type
-etc..
-radioInterface
-vlfRadioTable
-index
-specific property etc..
-hfRadioTable
-index
-specific property etc..
-vhfUhfRadioTable
-index
-specific property etc..
-xtalRadioTable
-index
-specific property etc..
-antennaTable
-index
-specific property etc..
-utilityInterface
-radioModemTable
-index
-specific property etc..
-commSwitchTable
-index
-specific property etc..
-notification
-rrcsIdentFail
-rrcsIdentOk
-vlfRadioFail
71
Managing Communication Resources
________________________________________________________________
-vlfRadioOk
-etc..
The overall structure of the MIB is fairly standard. Most of the SNMP MIB’s for different
equipment and devices available today are structured in a similar manner.
The next step is to find a programming library that can be used in the implementation of
the simulator. It was a requirement that the simulator should be written in C++ and hence a
C++ API is needed. Cost is always an important issue. Because of that, the library should be
as cheap as possible, preferably free. The library selected is SNMP++. It is a free
implementation in C++ originally by HP.
To aid in the simulator development another free library, Agent++, is used. This library
can be used in conjunction with SNMP++ and a utility called AgentGen to generate C++
classes from the MIB file. This significantly reduces the time spent doing mostly copypaste/search-replace related work required when transforming the MIB data to C++ object
structures. These classes make up the core of the simulator.
The simulator consists of two parts. A graphical MMI for controlling the objects locally,
that is without using SNMP, and the actual SNMP agent containing the core classes and the
SNMP communication. The agent part is a COM component written in C++ and the MMI is a
GUI written in C# that controls the agent by using COM methods.
The agent can be loaded with different configuration files depending on which system it
should simulate. This configuration file is modeled as a windows “.ini” file and only
documented through comments inside the file. Through the MMI a user is able to initialize an
agent with a selected configuration file.
72
Managing Communication Resources
________________________________________________________________
Figure 7-1
A command prompt based MMI is also available with the same functionality as the
graphical MMI. This command line based MMI is written in C++ and utilizes the same agent
COM object as the graphical MMI.
73
Managing Communication Resources
________________________________________________________________
8 Result
8.1 Analysis
This paper focuses on which management solution MSBL should use for managing
devices. The criteria provided for the management solution was geared towards the legacy
protocols, such as a SNMP based solution, from the beginning. This makes it hard for some of
the newer technologies like WBEM and mobile agents to meet the requirements. All the
solutions have their advantages and perhaps the added functionality of other simultaneous
management solutions should be considered as well.
The final product is a piece of software that simulates an SNMP agent. At first it might
seem rather trivial, especially since much of the code for this agent was generated using a
utility. However, the agent fully simulates the functionality of the described systems. It should
not do anything fancy that a real SNMP agent placed at a maneuvering server would not do.
In the real systems there will be some communication with other communication channels.
For instance, one of the systems was to receive messages over SMTP. When a message had
arrived, a property in the SNMP agent would be set and the agent would generate a trap. This
functionality is currently missing in the agent. Presently a user has to set the property from the
MMI and then the agent will generate a trap. It was decided that this would be left out due to
lack of time.
The level of detail in the description of the solution based on mobile agents is not that high.
Perhaps this should be a full-blown design of an agent platform that MSBL can utilize. The
WBEM management alternative was also not examined as thorough as the others. This is in
part due to the complexity of the model and the abstract nature of WBEM. Hopefully, in a
few years, more material and implementations supporting WBEM will be readily available.
The amount of detail about the actual simulator and the devices is not very deep either. The
MIB is not provided as a supplement to this paper for instance, and neither is the requirements
74
Managing Communication Resources
________________________________________________________________
specification for the simulator. This is because some of the material is sensitive due to its
military nature. Hopefully the paper provides enough detail for the reader to get an
understanding of the systems and the how the simulator works regardless of that some of the
more technical specifications are left out.
As a final note it should be stated that network management of data networks is presently
totally dominated by SNMP, and probably will be for some time to come. This is why almost
any other solution will have to provide interoperability with SNMP. It is therefore rather
“safe” to go with SNMP, an old inefficient but very well established standard.
8.2 Future Work
Any of the management protocols could still be considered for future use in order to extend
MSBL’s management capabilities. The most lucrative work, from the author’s point of view,
would involve creating a mobile agent based framework that can communicate using SNMP
with both SNMP agents and MSBL. A generalized description of such a system is provided in
this paper but a more detailed design would have to be developed. Even the existing mobile
agent frameworks could be evaluated for use with MSBL.
Future work could also involve producing modules for MSBL that would handle CMIP
management. A WBEM solution could be developed for MSBL. This could be used to
manage existing SNMP agents. Presently the need for such a solution does not exist but if
WBEM is indeed the future management standard then it will become a prioritized item.
The one protocol besides SNMP that is actually in use by some of the devices that MSBL
definitely will be managing is RPC. Because of this FMV has seriously considered producing
modules for MSBL to handle the management of ICS2000 with RPC. Future work could
involve actually developing this functionality instead of relying on a maneuvering server.
75
Managing Communication Resources
________________________________________________________________
9 Conclusions
Data Unit, now Citat Solutions, has been contracted to further develop a communication
system for the Swedish Defense called MSBL. The MSBL communication system is a work
in progress. For the upcoming version there are new requirements. One of these is the ability
to manage various communications resources from within MSBL.
MSBL will operate over data networks. The system needs to utilize a standardized
interface for future interoperability. In the network management field today there are several
solutions for managing data networks. Some of the more popular are SNMP, CMIP, WBEM,
RPC, and Mobile Agents. These are considered for use in MSBL.
Each of the management solutions has both strengths and weaknesses. When lined up
alongside with the requirements of MSBL some of these way heavier then others. The Simple
Network Management Protocol, SNMP, is the most logical choice, in large part due to the
requirements. The other solutions just do not seem to fit as well with these predefined
requirements as SNMP.
Mobile Agents are perhaps in a league of their own. This solution is currently the focus of
many research programs in the network management field. A solution based on mobile agents
could very effectively be utilized on top of the SNMP based framework that is recommended
for MSBL.
76
Managing Communication Resources
________________________________________________________________
10 References
[1]
“Sammanställning funktioner MSBL 2.0”.
[2]
“Beskrivning av MIB för styrning av radiomanöversystem i Marinen”.
[3]
FMV aktuellt, 6/2001, ”Ett projekt i tiden”, sidan 22-23.
[4]
“MSBL version 2 Kravspecifikation - Gränsytelikare funktionskedjor”.
[5]
“MSBL IRS Funktionskedjor – Gränsytespecifikation kommunikationssystem”.
[6]
Douglas W. Stevenson, “Network Management: What it is and what it isn’t”, April
1995, http://netman.cit.buffalo.edu/Papers.html
[7]
Dan Plakosh, “Network Management – An Overview”, Carnegie Mellon Software
Engineering Institute, http://www.sei.cmu.edu/str/descriptions/network_body.html
[8]
Jon Dron, “FCAPS – The ISO Mangement Model”, Notes for the course “ISM05 for
MSc
Information
Systems,
2001-2002”,
University
of
Brighton,
http://edtech.it.bton.ac.uk/ism05-01/fcaps/
[9]
Internetworking Technologies Handbook, Cisco, Chapter 6 “Network Management
Basics”.
[10] Ravi V. Shankar and Ashish K. Chatterjee, “Managing the Management
Communications Network in Optical Transport Systems”, Bell Labs Technical Journal,
October-December
1999,
http://www.lucent.com/minds/techjournal/octdec1999/pdf/paper09.pdf
[11] Infocom Products, ICS2000 http://www.infocom.dk
[12] Dan Plakosh, “Simple Network Management Protocol – Software Technology Review”,
Carnegie
Mellon
Software
Engineering
Institute,
http://www.sei.cmu.edu/str/descriptions/snmp.html
[13] Network
Knowledge,
know.co.uk/netman/snmp.html
SNMP
information,
http://www.net-
[14] University of Twente, The SimpleWeb, http://www.simpleweb.org/
[15] Yoram
Cohen, “SNMP
–
Simple Network
http://www.rad.com/networks/1995/snmp/snmp.htm
[16] “Simple
Network
Management
http://www.cisco.com/warp/public/535/3.html
77
Management
Protocol
Protocol”,
(SNMP)”,
Managing Communication Resources
________________________________________________________________
[17] “Simple Network Management Protocol”, Chapter 56, Internetworking Technologies
Handbook,
Cisco
Systems,
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.pdf
[18] William Stallings, “Security Comes to SNMP: The New SNMPv3 Proposed Internet
Standards“, The Internet Protocol Journal, Volume 1, Number 3, December 1998.
[19] RFC 1157, “A Simple Network Management Protocol (SNMP)”, IETF, May 1990,
http://www.ietf.org/rfc/rfc1157.txt
[20] RFC 1901, “Introduction to Community-based SNMP v2”, IETF, January 1996,
http://www.ietf.org/rfc/rfc1901.txt
[21] RFC 2570, “Introduction to Version 3 of the Internet-standard Network Management
Protocol”, IETF, April 1999, http://www.ietf.org/rfc/rfc2570.txt
[22] Network Knowledge, CMIP information, http://www.net-know.co.uk/netman/cmip.html
[23] RFC 1095, “The Common Management Information Services and Protocol over TCP/IP
(CMOT)”, IETF, April 1989, http://www.ietf.org/rfc/rfc1095.txt
[24] Dan Plakosh, “Common Management Information Protocol – Software Review”,
Carnegie
Mellon
Software
Engineering
Institute,
http://www.sei.cmu.edu/str/descriptions/cmip.html
[25] “CMIP/CMIS
Object
Oriented
http://www.cellsoft.de/telecom/cmip.htm
[26] “GDMO - Guidelines for Definition
http://www.cellsoft.de/telecom/gdmo.htm
Network
of
Management”
Managed
Objects”,
CellSoft,
CellSoft,
[27] “Management Issues for Distributed Services”, Proc. IEEE Second International
Workshop on Services in Distributed and Networked Environments (SDNE
95)Whistler, British Columbia, Canada, 5-6 June 1995, IEEE Computer Society Press,
pp 52-59 , http://www.simpleweb.org/bibliography/articles/general/slo9506.ps
[28] Cory Vondrak, “Remote Procedure Call – Software Technology Review”, Carnegie
Mellon
Software
Engineering
Institute,
http://www.sei.cmu.edu/str/descriptions/rpc_body.html
[29] RFC 1050, “RPC: Remote procedure Call Protocol Specification”, IETF, April 1988,
http://www.ietf.org/rfc/rfc1050.txt
[30] RFC 1831, “RPC: Remote procedure Call Protocol Specification version 2”, IETF,
August 1995, http://www.ietf.org/rfc/rfc1831.txt
[31] RFC 2695, “Authentication Mechanisms for ONC RPC”, IETF, September 1999,
http://www.ietf.org/rfc/rfc2695.txt
[32] ONC Remote Procedure Call (ONCRPC) , http://www.ietf.org/html.charters/oncrpccharter.html
78
Managing Communication Resources
________________________________________________________________
[33] DCE, http://www.opengroup.org/dce/
[34] “AIX Version 4.3 Communications Programming Concepts”, First Edition 1997,
Chapter
8:
Remote
Procedure
Call,
http://www.unet.univie.ac.at/aix/aixprggd/progcomc/toc.htm
[35] NISTIR 5277, “Comparing Remote Procedure Calls”, John Barkley, October 1993
http://hissa.nist.gov/rbac/5277/titlerpc.html
[36] Jean-Philippe Martin-Flatin, Simon Znaty and Jean-Pierre Hubaux, “A Survey of
Distributed Network and Systems Management Paradigms”, Technical Report
SSC/1998/024, version 2, SSC, EPFL, Lausanne, Switzerland, August 1998.
[37] Common Information Model (CIM) Specification Version 2.2, DMTF June 14 1999.
[38] L. D. Weller, “Presentation – DMTF Roadmap to Mangeability”, August 4, 1998.
[39] “White Paper Common Information Model (CIM) Core Model version 2.4”, DMTF,
August 2000.
[40] “DMTF CIM Schema version 2.6”, http://www.dmtf.org
[41] Takeo Hamada, Peter Czezowski, Takafumi Chujo, “Policy-based Management for
Enterprise and Carrier IP Networking”, FUJITSU Sci. Tech. J., 36,2, pp.128-139,
December 2000.
[42] Jose Luis Oliveira and Rui Aguiar, “Internet Management Evolution Views”, (Draft
Version) University of Aveiro, Portugal.
[43] CIM FAQs, DMTF, http://www.dmtf.org/about/faq/cim.php
[44] German Goldszmidt and Yechiam Yemini, “Distributed Management by Delegation”,
In Proceedings of the 15th International Conference on Distributed Computing Systems,
June 1995.
[45] Stephen Corley, Marius Tesselaar, James Cooley, Jens Meinköhn, Fabio Malabocchia,
and Francisco Garijo, “The Application of Intelligent Agents to Network and Service
Management”.
[46] John Sum, Hong Shen, and Gilbert H. Young, “Analysis on a mobile agent based
algorithm for network management”, Proceedings of the 1999 International Conference
on Parallel and Distributed Procedding Techniques and Applications, (PDPTA'99), Las
Vegas, Nevada, USA, June 28 - July 1, 1999.
[47] Antonio Puliafito, Orazio Tomarchio, “Using Mobile Agents to implement flexible
Network Management strategies”, Computer Communication Journal, 23(8):708-719,
April 2000.
[48] Mario Baldi, Silvano Gai, and Gian Pietro Picco, “Exploiting Code Mobility in
Decentralized and Flexible Network Management”, Proceedings of Mobile Agents,
First International Workshop, MA'97, Berlin, Germany, April 7-8, 1997.
79
Managing Communication Resources
________________________________________________________________
[49] David Griffin, George Pavlou, Panos Georgatsos, “Providing Customisable Network
Management Serviced Through Mobile Agents”.
[50] M. Zapf, K. Herrmann, and K. Geihs, “Decentralized SNMP Management with Mobile
Agents”, Proceedings of the Sixth IFIP/IEEE International Symposium on Integrated
Network Management (IM'99), Boston MA/USA, May 24-28, 1999.
[51] Thomas Gschwind, Metin Feridun, and Stefan Pleisch, “ADK – Building Mobile
Agents for Network and Systems Management from Reusable Components”, First
International Symposium on Agent Systems and Applications and Third International
Symposium on Mobile Agents, Palm Springs, California, October 2-5, 1999.
[52] Rui Pedro Lopes and Jose Luis Oliveira, “Distributed Management of Mobile
Components”, Proceedings of the Third Conferencene on Telecommunications,
Figueira de Fez, Portugal, April 23-24, 2001.
[53] Otto Wittner, “Network Management by Knowledge Distribution using Mobile
Agents”.
[54] Otto Wittner, Carsten J.E. Hölper, Bjarne E. Helvik, “Failure Semantics of Mobile
Agent Systems Involved in Network Fault Management”, Proceedings of 2000
IEEE/IFIP Network Operations and Management Symposium (NOMS 2000), Honolulu,
Hawaii, April 10-14, 2000.
[55] “Mobile Agent Facility V1.0”, OMG, January 2000.
[56] Stan Franklin and Art Graesser, “Is it an Agent, or just a Program?: A Taxonomy for
Autonomous Agents”, Proceedings of the Third International Workshop on Agent
Theories, Architectures, and Languages, Springer-Verlag, 1996.
[57] “Chapter 4: OMG MASIF and CORBA – Integrating Mobile Agent Technology and
CORBA”, “Deliverable 7a: Industrial Fora, ACTS chains and Clusters”, DIFFERENCE
Consortium,
September
31,
1998,
http://www.det.ua.pt/Projects/difference/work/Deliverables/d7.pdf
[58] J. Baumann, F. Hohl, K. Rothermel, and M. Strasser, “Mole – Concepts of a Mobile
Agent System”, Univiersität Stuttgart, Fakultät Informatik, August 1997.
[59] Dr.–Ing. Stefan Covaci, “Grasshopper: The First Reference Implementation of the
OMG
MASIF
Mobile
Agent
System
Interoperability
Facility”,
http://www.omg.org/docs/orbos/98-04-05.pdf
[60] “Java Management Extensions Instrumentation and Agent Specification, v1.0”, Sun
Microsystems, July 2000.
[61] “Getting Started with the Java Dynamic Management Kit 4.2”, Sun Microsystems,
December 2000.
[62] Colin Pattinson, “A Study of the Behaviour of the Simple Network Management
Protocol”, 12th International Workshop on Distributed Systems: Operations and
Management DSOM’2001, October 2001.
80
Managing Communication Resources
________________________________________________________________
[63] Franck Barillaud, Luca Deri, and Metin Feridun, “Network Management using Internet
Technologies”, Proceedings of the Fifth IFIP/IEEE International Symposium on
Integrated Network Management (IM'97), San Diego, May 12-16, 1997.
[64] B. Pagurek, Y. Wang, and T. White “Integration of Mobile agents with SNMP: Why
and How”, IEEE, 2000.
[65] Alfredo C. S. C. Brites, Paulo A. F. Simoes, Paulo M. C. Leitao, Edmundo H. S.
Monteiro, and Fernando P. L. Boavida Fernandes, “A High-Level Notation For The
Specification Of Network Management Applications”, Proceedings of INET’94/JENC5,
May 1994.
[66] Paulo Simoes, Rodrigo Reis, Luis M. Silva, and Fernando Boavida, “ENABLING
MOBILE AGENT TECHNOLOGY FOR LEGACY NETWORK MANAGEMENT
FRAMEWORKS”, Proceedings of Softcom '99 - Conference on Software in
Telecommunications and Computer Networks, IEEE Communications Society,
University of Split (Croatia), Split, Rijeka (Croatia), Trieste, Venice (Italy), October
1999.
[67] Danny B. Lange and Mitsuru Oshima, “Seven Good Reasons for mobile Agents”
Communications of the ACM, Vol 42, No 3, March 1999.
[68] Andrzej Bieszczad, Bernard Pagurek, and Tony White, “Mobile Agents for Network
Management”, IEEE Communications Surveys, Vol 1, No 1, Fourth Quarter 1998.
[69] Damianos Gavalas, Dominic Greenwood, Mohammed Ghanbari, and Mike O’Mahony,
“Advanced Network Monitoring Applications Based on Mobile/Intelligent Agent
Technology”, Computer Communications Journal, Vol. 23, No 8, pp. 720-730, April
2000.
[70] Rui Pedro Lopes and Jose Luis Oliveira, “SOFTWARE AGENTS IN NETWORK
MANAGEMENT”, Proceedings of the 1st International Conference on Enterprise
Information Systems, Setubal, Portugal, March 27-30, 1999.
[71] Paulo Simoes, Luis Moura e Silva, and Fernando Boavida Fernandes, “A Generic
Management Model for Mobile Agent Infrastructures”, Submitted to SCI2000.
[72] Nwana, H. S, “Software Agents: An Overview”, Knowledge Engineering Review, Vol
11, No 3, September 1996.
[73] The Object Management Group, http://www.omg.org
[74] Perpetuum Mobile Procura Project Glossary, Network Management and Artificial
Intelligence
Laboratory,
Carlton
University,
http://www.sce.carleton.ca/netmanage/perpetum.shtml
[75] OMG Agent Platform Special Interest Group, http://www.objs.com/agent/index.html
[76] DISMAN Charter, http://www.ietf.org/html.charters/disman-charter.html
81
Managing Communication Resources
________________________________________________________________
[77] Internetworking Technologies Handbook, Chapter 55, “Remote Monitoring”, Cisco
Systems, http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/rmon.pdf
[78] RFC 1757, “Remote Network Monitoring Management Information Base”, IETF,
February 1995, http://www.ietf.org/rfc/rfc1757.txt
[79] RFC 2819, “Remote Network Monitoring Management Information Base”, IETF, May
2000, http://www.ietf.org/rfc/rfc2819.txt
[80] RMON Charter, http://www.ietf.org/html.charters/rmonmib-charter.html
[81] Steve Steinke, “Simple Network Management Protocol – SNMP”, Network Magazine,
02/01/97, http://www.networkmagazine.com/article/NMG20000724S0050
[82] Z. CEKRO, "Simple Network Management Protocol (SNMP) - Current Standards and
Status", Vrije Universiteit Brussel, March 1998. http://sun10.iihe.ac.be/internalreport/stc-98-06.html
[83] Lennart Pettersson, “Kommunikationssystem SjöMan Systembeskrivning”, Telub.
[84] Paulo Simoes, Luis Moura Silva, and Fernando Boavida Fernandes, “Integrating SNMP
into a Mobile Agent Infrastructure”, Proceedings of the 10th IFIP/IEEE International
Workshop on Distributed Systems: Operations Management (DSOM'99), October 1999.
[85] The James Project, http://james.dei.uc.pt
[86] "JAMES: A Platform of Mobile Agents for the Management of Telecommunication
Networks", L. Silva, P. Simões, G. Soares, P. Martins, V. Batista, C. Renato, L.
Almeida, N. Stohr, Proceedings of IATA '99 (3rd International Workshop on Intelligent
Agents for Telecommunication Applications), Stockholm, Sweden, August 1999.
[87] The Foundation for Intelligent Physical Agents, http://www.fipa.org
[88] RFC 2982, “Distributed Management Expression MIB”, IETF, October 2000,
http://www.ietf.org/rfc/rfc2982.txt
[89] “DMI v.2.0 Update”, Desktop Management
http://www.dmtf.org/download/press/dmiupdate.pdf
Task
Force,
July
1996,
Slide
17,
[90] CIM Tutorial, http://www.dmtf.org/education/cimtutorial/using/struc.php
[91] DMTF
Summit
Roadmap
Presentation,
DMTF,
http://www.dmtf.org/download/presentations/summit_roadmap98.pdf
[92] Luís Moura Silva, Guilherme Soares, Paulo Martins, Victor Batista and Luís Santos,
“The Performance of Mobile Agent Systems”, Poster presented at ASA/MA'99, Palm
Springs,
California,
October
1999,
http://james.dei.uc.pt/james2/Papers/james_ma99.pdf
[93] The Voyager System, http://www.recursionsw.com/products/voyager/voyager.asp
82
Managing Communication Resources
________________________________________________________________
[94] Grasshopper, http://www.grasshopper.de
[95] Jumping Beans, http://www.JumpingBeans.com
[96] Oliver Huber, “Management of Mobile Agents in Telecommunication Networks”,
ENST de Bretagne, 1997, Department Reseax et Services Multimedia, France.
[97] Laurent Toutain, Oliver Huber, “Mobile Agents in Active Networks”, ENST de
Bretagne, 1997, Department Reseax et Services Multimedia, France.
[98] The Internet Engineering Steering Group, http://www.ietf.org/iesg.html
83