9information from varied network devices, notifying administrators, and enabling
timely proactive interaction with the network. The widespread acceptance of the
Internet and the corporate intranet have demonstrated how effective these elec-
tronic channels are for distributing information. Java, which already brings dy-
namic information to Web browsing and the intranet, enables administrators to ac-
cess and work with network management information dynamically as just with
any other type of information on the corporate intranet.
Some management tools offer Web access over the intranet using passive
HTML, CGI, JavaScript, VRML and HTTP. These tools, however, provide access
only to static network information. They do not allow administrators to easily
view dynamic information or perform real-time management functions through
the browser. With Java, network administrators using a simple, Java-capable
browser can access real-time information from managed network devices easily
and quickly.
Similarly, Java Web-based network management gives other people within the
organisation ready access to information otherwise locked in traditional manage-
ment systems. This information includes statistical data, usage statistics, and bill-
ing/accounting information. Through a Java-capable Web browser, this valuable
information is available for planning, cost analysis, and cost allocation in addition
to network management.
Java Web-based management applications enjoy all the benefits of Java itself.
The applications are portable and highly distributable over the network. Since
Java applications run on the client machine, the load is reduced on the manage-
ment application server, increasing the scalability of Java Web-based management
solutions. Based on an object-oriented language all the Java Management Appli-
cations are highly extensible and robust, making it easy to add new managed re-
sources and devices and new management functionality.
Web-based access ensures that network administrators can access management
applications over the intranet from any Java-capable browser and will be able to
perform full management functions. No longer are administrators tied to large,
10
costly, specialised network consoles. This will allow organisations more flexibil-
ity in the deployment of network administrators and ultimately reduce the cost of
network management through better utilisation of the administrators and reduced
reliance of specialised consoles.
As an open, standards-based approach, Java Web-based management will al-
low organisations to leverage their existing investments in hardware and platforms
and associated training while they benefit from freedom of choice in their man-
agement platform and workstation operating system decisions in the future. This
will enable organisations to reduce both hardware and administrative network op-
erations costs.
1.2 Java and Mobile Agents
The computational paradigm of Mobile Agents was introduced some years ago
and deals with small programs that can autonomously roam a network.
Mobile agent-based computing may be viewed as an extension of well-known
methods of remote dispatch of script programs or remote submission of batch
jobs. Though it is not new, today it is being given a great attention since the first
industrial standards are being defined, opening new perspectives in the network
computing framework.
Nowadays the central paradigm that ties all distributed object technologies to-
gether is a synchronous message-passing paradigm whereby all objects are dis-
tributed, but stationary, and interact with each other through message-passing.
This paradigm is incomplete and needs to be enhanced in some fashion with addi-
tional paradigms such as asynchronous message-passing, object mobility, and ac-
tive objects. Mobile agents can provide a single uniform paradigm for distributed
object computing, encompassing synchrony and asynchrony, message-passing and
object-passing, and stationary objects and mobile objects. Mobile agents, like
elementary particles in physics, are fundamental to distributed object computing.
11
1.3 Thesis scope
The purpose of this doctoral thesis is to point out how some network manage-
ment and monitoring tasks can be built with a relatively little effort by means of
the Java programming language.
In particular I tried to evaluate many aspects of the Java paradigm, such as the
use of the Web environment and the mobile agents technology, by designing and
implementing different Network Management and Computer Aided Learning
systems.
Starting from these basis the activity of the doctorate course has been focused
on three main arguments:
• The Java ADministration system (JAD), a Java based software for the
web-based configuration and management of network devices. JAD is a
simple but powerful tool that allows users to manage a network device via
any Java enabled Web browser. It presents HTML documents introducing
the managed device and by means of hypertextual links let users to reach
the control panel interfaces (written in Java) created to read and set device
parameters. The JAD system uses the SNMP protocol to provide its serv-
ices that represent a general application for the configuration of any net-
work device with an SNMP agent embedded in it.
• A network management system based on the Java mobile agent tech-
nology. The main network management approaches proposed in literature
are both characterised by centralisation and a low degree of flexibility and
reconfigurability. These problems are a consequence of the client-server
paradigm adopted in the management architecture. This solution lacks scal-
ability and generates congestion in the network area around the manage-
ment station. The system that we developed uses mobile agents to migrate
from host to host in a network, reaching and investigating the LAN that has
to be managed. When the agent is on the destination it performs manage-
ment tasks by means of the SNMP protocol. This model can be successfully
12
deployed in different types of networks, including Virtual Private Net-
works, since the security support embedded in Java and in the particular
mobile agent framework, allows to safely work through firewalls.
• New approaches for Web-based education systems. Taking advantage
from the World Wide Web, multimedia and Java technologies, a new ap-
proach to develop courseware for instrumentation and communication areas
has been studied. The Real Experiment eXecution (REX) based courseware
consists of lectures and practice activities with a high degree of interaction
obtained through a guided execution of laboratory experiments. The inter-
active components of the courseware are based on real experiments sup-
ported by Java applets. Moreover I studied a web-based didactical envi-
ronment which has the main purpose of building a virtual classroom, where
the students can interact, in a transparent way, with a Campus LAN, in-
specting the real traffic of the network or analysing and elaborating collec-
tions of data by means of off-line exercises.
13
&KDSWHU 7+(+,6725<2)
1(7:25.0$1$*(0(17
Networks are used to interconnect heterogeneous systems and devices.
In the past few years, hardware manufacturers have acknowledged the
need to build software applications able to manage the different network
equipment they produced. Unfortunately the interconnection of devices
from different manufacturers has shown the limitations of ad hoc software
for a specific device and it has been one of the reasons that pushed the
network community towards a standard way to manage networks. For
historical reasons network management is split into two distinct parts: OSI
network management and Internet management. The former deals with
the management of large public telecommunication networks, the latter
with management of devices attached to the Internet. In the past few
years, a new management paradigm defined by OMG and based on
CORBA has been very successful. This is due to its ability both to operate
(e.g. TCP/IP) and manage (e.g. SNMP, CMIP) networks, activities which
instead are separated in OSI and Internet management.
2.1 What is network management?
Management of a system is concerned with supervising and controlling the
system so that it fulfils the requirements of both the owners and users of the sys-
tem. This includes the longer-term planning required for the system to evolve to
14
provide improved performance, incorporate new functionality or new technology.
Management may also involve accounting to make sure that resources are fairly
allocated to users or to actually charge users for use of services. The management
of a system may be performed by a mixture of human or automated components.
The term manager is usually used to refer to any entity, human or automated, that
can perform management activities.
As part of the on-line control of a system, the managers must perform the fol-
lowing activities (see Figure 2.1):
1. Monitor the system to obtain up-to-date status information and to receive
event reports;
2. Interpret the overall policy pertaining to the goals or requirements of the
Management
Policies
Managers
Managers
Managers
Networked System
Monitor
Control
Interpret
Management Information Flow
Monitor status
and receive
event reports
Perform control
operations
Interpret policy
and make
decisions
Management Activity Loop
Figure 2.1: network management architecture
15
organisation that owns the system in order to make decisions about what
behaviour is required from the system;
3. Perform control actions on the system resources to change their behaviour
and implement the management decisions.
2.2 Why do we need network management?
Networks and distributed systems have become critical to the work of many
enterprises. Management is essential to make sure these systems continue to func-
tion to provide the service required of them. It s a matter of fact that no enterprise
remains static, it changes to meet new market needs and new business practices.
The longer-term planning aspects of management are essential to permit the sys-
tems to evolve and adapt to these changing requirements of the enterprise.
This realisation of the strategic importance of network and distributed systems
management has resulted in demand for management facilities which has, to some
extent, outstripped the research and development needed to implement these sys-
tems. The fully integrated management systems which will cope with manage-
ment of large-scale distributed applications and their underlying communication
services are not available commercially. Many of the issues relating to specifying
policy, structuring management and building complex management systems in-
corporating artificial intelligence techniques and graphical user interfaces are still
research topics.
Another reason for the upsurge in interest in automated and integrated man-
agement of networks and distributes systems is that some of the systems already
installed have grown so large and complex that ad hoc, manual management is
not coping. The components to be managed are manufactured by different ven-
dors, and may have proprietary management facilities or none at all; there are
likely to be multiple interconnected networks providing the overall communica-
tion service to a distributed application; the distributed nature of the system results
16
in delays in obtaining status information so it is not easy to get a global view of
the overall state of the system; the system may be constantly changing and deter-
mining the current configuration can be difficult. The two main problems are: the
complexity of management requires automation of many aspects of management,
tools are needed to support human managers in performing their function.
Standardisation of management interactions provides obvious benefits of being
able to manage multi-vendor components from a single management platform.
The Simple Network Management Protocol (SNMP) emerged from the internet
community and is now a de facto standard. This was not considered sophisticated
enough to cope with the future complexities of modern communication systems
and so object-oriented approach was undertaken by the International Standardisa-
tion Organisation (ISO) within the Open System Interconnection (OSI) frame-
work.
2.3 OSI Network Management
The OSI Network Management [JEFFREE][KLERER], defines how manage-
ment information has to be collected, represented and transferred among open
systems. It provides a common terminology necessary to flatten the differences
among different systems and create new management standards. Moreover it
specifies the protocols used to exchange management information, defining the
services and operations relevant for network management. At the end OSI Net-
work Management identifies and defines the tools necessary to monitor, control
and co-ordinate open systems activities.
The OSI Environment is the set of resources that allows open systems to com-
municate according to OSI protocols and services. The OSI Management Envi-
ronment is a subset thread that deals with the tools and services necessary to con-
trol and supervise interconnection activities and the resources relevant for man-
agement. The systems part of OSI Environment can perform management activi-
17
ties themselves or they can co-operate with other open systems for the purpose of
management. In the latter case OSI Management offers tools that:
• Enable system managers to plan, organise and control interconnection
services;
• Help maintain reliable connections among systems;
• Protect management information through the authentication of senders and
receivers of management information being exchanged.
Resources contained in the open systems part of the OSI Management Envi-
ronment are represented by managed objects (MO) and are managed using the
protocols defined by OSI Management. An MO is an abstract representation of a
physical (for instance a bridge or a router) or logical (i.e. a communication proto-
col) entity. It is characterised by some attributes which represent its properties, its
characteristics that need to be visible from the outside, the operations (methods) to
which the MO responds, its behaviour and the events (notifications) the MO emits
asynchronously. For instance a counter can be represented by an MO containing
an attribute which stores the counter s current value and which can be manipu-
lated using the get, set and reset methods. These methods manipulate only the MO
attributes. It is the MO s responsibility to synchronise the modification of the at-
tribute whit the current counter value, which may be stored in a physical network
device. An MO is a member of a certain object class that characterises all the ob-
jects which have the same attributes, support the same operations, and emit the
same notifications. MOs are defined using GDMO [GDMO] notation, defined by
ISO in order to harmonise management information definition. GDMO is a formal
language which allows users to specify MO characteristics, but it is not powerful
enough to specify MO behaviour which is defined in plain English. This limitation
prevents GDMO from being a suitable fully automatic processing because a com-
piler cannot interpret the behaviour clause, thus making management application
toolkits complex and unable to generate applications automatically without hu-
mans to code MO behaviour.
OSI management model defines two hierarchical relations for MOs: inheritance
18
and containment. Inheritance is a relation between hierarchical classes. Each ob-
ject class inherits the characteristics (attributes, operations, notifications) of its su-
perior class adding new characteristics or specialising some of them. For instance
the object class packet switching network is derived from the class network in
the inheritance hierarchy. Containment is applied to single MOs. An MO can
contain other MOs, which can contain further MOs. For instance an MO repre-
senting a router can contain MOs representing the router communication ports,
which can contain MOs representing the devices connected to such ports. Al-
though inheritance is a concept present in object-oriented languages, containment
is a characteristic of OSI management because in object-oriented languages there
is no means of object containment and hierarchy. In conclusion, every resource
relevant to the OSI Management is represented by an MO having some peculiar
characteristics.
MOs can be specified for a single management layer (N-layer MO), for multi-
ple layers or for system management (system MO).
In an open system the information relative to MOs is stored in the Management
Information Base (MIB). Such information can be modified or transferred only by
using OSI Management protocols. A consequence of this is that data contained in
the MIB are logically organised according to the OSI Management specifications.
Nevertheless OSI Management imposes no restrictions on data types, on the stor-
age method (for instance database or flat files), on the abstract syntax, or the se-
mantics used during data exchange. The formal language introduced by OSI to de-
fine abstract syntaxes is ASN.1 (Abstract Syntax Notation One) [ASN.1], which
provides a wide variety of types ranging from simple bit strings to complex
structures.
The OSI Management paradigm is characterised by two processes: managing
process (manager) and agent process (agent). The agent manipulates MOs directly
by performing operations requested by managers. Agents are also responsible for
sending events to managers when a certain situation occurs. An OSI open system
can implement one or more agents or managers.
19
The OSI System Management defines the mechanism used to monitor, control
and co-ordinate MOs contained in an open system. It allows MOs contained in
one or more layers to be managed and it is the only way, within OSI Management,
to operate on different layers. System management communications are performed
by the System Management Application-Entity (SMAE), which define the services
offered by OSI management applications. SMAEs send requests and receive re-
sponses and notifications from/to open systems. They are composed of one or
more Application Service Entity (ASE), namely: SMASE (System Management
Application Service Element), CMISE (Common Management Information Serv-
ice Element), ROSE (Remote Operation Service Element) and ACSE (Association
Control Service Element).
SMASE is responsible for identifying and defining specific management as-
pects concerning the information which has to be exchanged among open systems.
CMISE is composed of CMIS and CMIP, and permits OSI Management sys-
tems to share management information and to handle requests received from other
systems.
CMIS is the general service employed by OSI Management to handle commu-
nications concerning the management of MOs and the transmission of notifica-
tions. It defines a set of service primitives, their parameters and the information
necessary to describe each primitive semantically. The CMIS primitives allow:
• Notifications to be received;
• Attributes to be read and modified;
• MO instances to be created and deleted;
• Operation requests to be sent to another CMISE user.
CMIP [CMIP] specifies the protocol used by CMIS and by N-layer MOs to ex-
change management information. It defines the procedures for exchanging man-
agement information between applications (CMIP abstract syntax), for the correct
information control protocol interpretation and for the conformance tests em-
ployed to validate CMIP implementations.
ROSE allows remote operations to be requested and the corresponding re-
20
sponses to be received. ROSE can be considered the OSI service that corresponds
to the UNIX Remote Procedure Call (RPC). CMIP exploits the ROSE transac-
tional services in order to send requests and receive responses.
ACSE provides services which establish or release in a normal or abnormal
way logical associations between two application entities. It also provides the
means to control an application association, which is a co-operation relationship
between two application entities that communicate using a connection established
in an open system environment.
OSI has identified five functional areas within OSI Management:
• Fault management provides the facilities necessary to:
- Identify, diagnose and correct network faults
- Notify the system managed about errors and abnormal situations
- Analyse error logs
- Perform diagnostic tests used to verify network activities.
• Configuration management provides facilities necessary to:
- Set key parameters of open systems
- Initialise and remove MOs
- Collect information about the system and notify state changes
- Modify the system configuration.
• Performance management provides facilities for monitoring, controlling,
analysing and tuning system activities.
• Accounting management provides the facilities necessary to:
- Collect information on the users and the resources they have used
- Calculate the costs involved in the utilisation of some MOs necessary to
perform a certain activity
- Collect statistics concerning errors and anomalous situations.
• Security management provides facilities necessary to:
- Authenticate users who performed management requests
- Control and maintain the tools used for security
- Handle encryption keys
21
- Control and maintain access rights
- Manage and maintain security logs.
2.3.1 The Common Management Information Protocol (CMIP)
The CMIP protocol was supposed to be the protocol that replaced SNMP in the
late 1980’s. Funded by governments and large corporations, many thought that it
would become a reality because of its almost unlimited development budget. Un-
fortunately, problems with its implementation have delayed its widespread avail-
ability and it is now only available in limited form from its developers themselves.
CMIP was designed to build on SNMP by making up for SNMP’s shortcom-
ings and becoming a bigger, more detailed network manager. Its basic design is
similar to SNMP, whereby PDU’s are employed as variables to monitor a network.
CMIP however contains 11 types of PDU’s (compared to SNMP’s five).
In CMIP, the variables are seen as very complex and sophisticated data struc-
tures, with many attributes. These include :
• variable attributes: which represent the variables characteristics (its data
type, whether it is writable).
• variable behaviors: what actions of that variable can be triggered.
• notifications: the variable generates an event report whenever a specified
event occurs (eg. a terminal shutdown would cause a variable notification
event.
As a comparison, SNMP only employs variable properties one and three from
above.
The biggest feature of the CMIP protocol is that its variables not only relay in-
formation to and from the terminal (as in SNMP), but they can also be used to per-
form tasks that would be impossible under SNMP. For instance, if a terminal on a
network cannot reach its fileserver a pre-determined amount of times, then CMIP
can notify the appropriate personnel of the event. With SNMP however a user
would have to explicitly keep track of how many unsuccessful attempts to reach a
22
fileserver that a terminal has incurred. CMIP thus results in a more efficient net-
work management system, as less work is required by a user to keep updated on
the status of their network.
Another advantage to the CMIP approach is that it addresses many of the
shortcomings of SNMP. For instance, it has built in security management devices
that support authorisation, access control, and security logs. The result of this is a
safer system from the installation of CMIP; no security upgrades are necessary
(like SNMP).
The last advantage is that CMIP was funded by not only governments, but also
large corporations. One can induce that CMIP not only has a very large develop-
ment budget, but also that when it becomes a widely available protocol it will
have numerous immediate users, namely the governments and corporations that
funded it.
From the above, one might wonder that if CMIP is so wonderful, why hasn’t it
been implemented already (for after all, it has been in development for about ten
years). The answer to this is CMIP’s only significant disadvantage: the CMIP
protocol takes more system resources than SNMP by a factor of ten. In other
words, very few systems on this planet would be able to handle a full implemen-
tation of CMIP without massive network modifications (such as the installation of
thousands of dollars of memory and the purchase of new protocol agents). This
major disadvantage has no inexpensive workaround, and for this reason many
people believe that the CMIP protocol is doomed to fail. The only possible work-
around is to decrease the size of the protocol by changing its specifications.
Several protocols have been developed to run "on top" of CMIP and thus use
less resources but none of these has gathered enough momentum to challenge
SNMP.
Another problem with CMIP is that it is very difficult to program; for the vari-
ables require so many different variables that only a few skilled programmers
would be able to use the variables to their full potential.