Network Management System Implementation

1. Introduction

1.1 Authorization

This report is to Mr. Ronney that provides information and recommendation on

implementing network management system. The main objective is to implement a
network management system for the organization to fully utilize the networking
capability and integrate the current equipment with any new equipment purchase.

1.2 Limitations

Due to the rapid changes of technology, it is difficult for me to do the research and longer
time is needed. The broad area of RFC documents makes the discussion of different
SNMP protocol and the use of the MIB more difficult, thus it cannot be completely
discussed in this report.

1.3 Scope of the report

This report provides definition on MIB data types, its limitations, additional usage and
the relationship to other data types. Besides, four OSI Network Management model:
Organisational, Information, Communication and Functional model are discussed
throughout the report. In addition, Pros and Cons of different SNMP versions and issues
of integrating equipment from different manufacturers will be discussed as well.
Moreover, in the last section of the report, discussions and limitations of Case-Based
reasoning and Codebook Correlation Model are well defined.

1
Network Management System Implementation

2. Definition for the MIB data types

This section defines the various data types that apply to describe objects in the context of
MIB.

Integer32 and INTEGER

This data type allows to store integer value up to -2^31 and 2^31-1 (-2147483648 to
2147483647 decimal). The limitation of it is hyphen character is not allowed as a part of
the label name for any named-number enumeration. Its additional usage is it can be used
as a name-number enumeration. Regarding its relationship to other data types, it can be
used as a base data type for IpAddress, Gauge32 or Counter32. (RFC 1442, page 22)

OCTET STRING
This data type represents arbitrary binary or textual data. It has no size limitation. The
limitation of it is sizes cannot excess 255 octets. Regarding its relationship to other data
types, it can be used as a base data type for Opaque or IpAddress. (RFC 1442, page 23)

OBJECT IDENTIFIER
This data type represents administratively assigned names. It is used to specify object
type. Its limitation is it only can have at most 128 sub-identifiers and each sub-identifier
must not exceed the value 2^32-1 (4294967295 decimal). (RFC 1442, page 23)

BIT STRING
This data type represents as enumeration of named bits. It allows only positive,
contiguous values that start at zero. The limitation of it is hyphen character is not allowed
as a part of the label name for any named-bits enumeration. (RFC 1442, page 23)

2
Network Management System Implementation

IpAddress
This data type represents a 32-bit Internet address. It is tagged type and should be
represented using an invocation of the TEXTUAL-CONVENTION macro type. That is
the limitation of IpAddress. Regarding its relationship to other data types, it can be
represented as an OCTET STRING of length 4, in network byte-order. (RFC 1442, page
23)

Counter32
This data type represents a non-negative integer which monotonically increases until it
reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and
starts increasing again from zero. The limitations of it is sub-typing is not allowed and it
does not allowed to set default value. Regarding its relationship to other data types, it can
be used as implicit integer. (RFC 1442, page 24)

Gauge32
This data type represents a non-negative integer with maximum 2^32-1 (4294967295
decimal). Its value can be increase or decrease. Regarding its relationship to other data
types, it can be used as implicit integer. (RFC 1442, page 24)

TimeTicks
This data type represents a non-negative integer which represents the time with maximum
2^32-1 (4294967295 decimal). It is measure in hundredths of a second. Regarding its
relationship to other data types, it can be used as implicit integer. (RFC 1442, page 24)

Opaque
This data type allows passing arbitrary ASN.1 syntax. Its limitation is it is provided
solely for backward-compatibility and shall not be used for newly-defined object types.
Its additional usage is it is able to double wrapping the original ASN.1 value. Regarding
its relationship to other data types, it can be used as implicit OCTET STRING. (RFC
1442, page 25)

3
Network Management System Implementation

NsapAddress
This data type represents an OSI address as a variable-length OCTET STRING. It is
tagged type and should be represented using an invocation of the TEXTUAL-
CONVENTION macro type. That is the limitation of NsapAddress. Regarding its
relationship to other data types, it can be used as implicit OCTET STRING. (RFC 1442,
page 25)

Counter64
This data type represents a non-negative integer which monotonically increases until it
reaches a maximum value of 2^64-1 (18446744073709551615 decimal), when it wraps
around and starts increasing again from zero. Regarding its relationship to other data
types, it can be used as implicit integer. (RFC 1442, page 26)

UInteger32
This data type represents integer-valued information between 0 and 2^32-1 inclusive (0
to 4294967295 decimal). Regarding its relationship to other data types, it can be used as
implicit integer. (RFC 1442, page 26)

4
Network Management System Implementation

3. OSI Network Management Model

The OSI describe Network Management form a number of models: Organisation,

Information, Communication and Functional. Organisation model deals with how the
network components can be connected to provide control. Then, the Information model
describes how the information is structured (SMI) and stored in Management Information
Base (MIB). On the other hand, Communication model describes the communications
between the agents and the managers on the network. Finally, the functional model is the
all important model which describes the areas of network which needs to be managed.

3.1 Organisation Model

The organisation model describes the components of network management and their
relationships. Organisation model consists of two-tier model and three-tier model. Figure
1 shows a two-tier model. Network objects can be classified into managed and
unmanaged objects or elements. Normally, network objects are the devices (network
elements) in a network. They can be hubs, bridges, switches, routers, etc. For those
managed elements, there is a management process running in them which called an agent.
In contrast, the unmanaged elements do not have a management process running in them.
Next, the manager manages the managed element. In figure 1, the manager queries the
agent and receives management data, process it, and stores it in the database. Note that
the database is under the manager, not the agent. Besides, alarm information can be sent
by the agent to the manager unsolicited.

M D B M anager

M a n a g e d o b je c t s

U n m a n a g e d o b je c ts

M D B M a n a g e m e n t D a ta b a s e
A g e n t p ro c e s s

Figure 1: Two-tier Network Management Organisation Model

F ig u r e 3 .2 T w o -T ie r N e tw o r k M a n g e m e n t O r g a n iz a tio n M o d e l
(Mani Subramanian 2000, page 107)

5
Network Management System Implementation

Figure 2 depicts a three-tier configuration. The intermediate layer acts as dual roles, for
example both agent and manager. It collects data from the network elements, processes it,
and stores the results in its database (which is the tasks of the manager). In addition, it
transmits information to the top-level manager (which is the task of an agent).

M D B M anager

M D B Agent /M anager

M a n a g e d o b je c ts
M D B M a n a g e m e n t D a ta b a s e

A g e n t p ro c e s s

Figure 2: Three-tier
F i g u r e Network
3 . 3 T h r e e - T i Management
e r N e t w o r k M a n g eOrganisation
m e n t O r g a n i z a t i o Model
n M o d e l (Mani
Subramanian 2000, page 108)

Network domains can be managed locally and a global view of the network can be
monitored by a manager of managers (MoM). For your information, MoM presents
integrated view of network domains and network domain may be geographical,
administrative, vendor-specific products, etc. Moreover, network management systems
can be configured in client/server architecture as well as peer-to-peer architecture.
Notice, the manager and agent functions are processes and not systems. (Mani
Subramanian 2000, page 107-109; Dr Mohamed Othman, page 7-12)

3.2 Information Model

Information model deals with the structure and organisation of management information.
The representation of objects and information relevant to their management form the
management information model. As described earlier, information on network
components is passed between the agent and management processes. Note that, the
information comprises syntax and semantics about an object. Basically, the task of the
information model is specifies the information base in order to describe managed objects
and their relationships.

6
Network Management System Implementation

There are two main things in the information model: Structure of Management
Information (SMI) and Management Information Base (MIB). The SMI defines the
syntax and semantics of management information stored in the MIB (plus additional
information such as status). In fact, the MIB is used by both agent and management
processes to store and exchange management information. There are two types of MIB:
agent MIB and manager MIB. Agent MIB refers to MIB that associated with an agent.
On the contrary, manager MIB refers to MIB that associated with a manager. A manager
MIB consists of information on all the network components that it manages, whereas an
agent MIB needs to know only its local information, its MIB view. The MIB that
contains data on managed objects need not be limited to physical elements. The
information that can be stored in the MIB are network elements (hubs, bridges, routers,
transmission facilities), software processes (programs, algorithms, protocol functions,
database) and administrative information (contact person, account number). (Mani
Subramanian 2000, page 109-115; Dr Mohamed Othman, page 13-14)

3.3 Communication Model

Communication model deals with the way information is exchanged between systems.
Management data is communicated between agent and manager processes, and also
between manager processes. There are three aspects that need to be considered in the
communication of information between two entities: transport medium of message
exchange (transport protocol), message format of communication (application protocol)
and actual message (commands and responses).

Figure 3 shows the communication model. First, the applications in the manager module
initiate requests to the agent. Note that the agent is located in the Internet model. It is a
part of operation in OSI operation, for example, Internet request or response. The agent
executes the requests on the network element which is managed object and return
response to the manager. The notification/traps (SNMPv2) are the unsolicited message,
such as alarm, generated by the agent. Figure 4 shows the communication protocol used
to transfer information between managed object and managing processes, as well as
between management processes. The OSI model uses Common Management Information

7
Network Management System Implementation

Protocol (CMIP) along Common Management Information Services (CMIS). On the

other hand, Internet uses Simple Network Management Protocol (SNMP) for
communication and the services are part of operations using requests, responses and
alarm notifications. Notice, OSI uses both connection oriented and connectionless
protocols for transportation. (Mani Subramanian 2000, page 116-117; Dr Mohamed
Othman, page 15-17)

O p e r a tio n s /
R e q u e s ts

M anager R esponses Agent

N o tific a tio n s / N e tw o r k E le m e n ts /
A p p lic a tio n s
T ra p s M a n a g e d O b je c ts

Figure
F i g u r e 33:
. 1 1Management
M a n a g e m e n t MMessage
e s s a g e C Communication
o m m u n i c a t i o n M o dModel
el
(Mani Subramanian 2000, page 116)

M anager O p e r a t io n s / R e q u e s t s / R e s p o n s e s Agent
A p p lic a t io n s T r a p s / N o tific a tio n s A p p lic a t io n s

M anager Agent
S N M P ( In te r n e t)
C o m m u n ic a tio n C o m m u n ic a tio n
C M IP ( O S I)
M o d u le M o d u le

U D P / IP ( In te r n e t)
T ra n s p o rt L a y e rs T ra n s p o rt L a y e rs
O S I L o w e r L a y e r P r o file s ( O S I)

P h y s ic a l M e d iu m

F i Figure
g u r e 3 . 1 4:
2 MManagement
a n a g e m e n t CCommunication
o m m u n i c a t i o n TTransfer
r a n s f e r P Protocols
r o t o c o ls
(Mani Subramanian 2000, page 117)

3.4 Functional Model

8
Network Management System Implementation

OSI functional model addresses the user-oriented applications, which are formally
specified in the OSI model. This model is divided into five categories of management:
configuration management, fault management, performance management, security
management and accounting management.

• Configuration management
Configuration management is the facilities that control, identify, collects data
from and provide data to managed objects for the purpose of assisting in
providing for the continuous operation of interconnection devices. Configuration
management is concerned with initializing a network and gracefully shutting
down part or the entire network. Configuration management is also concerned
with monitoring, adding and updating the relationships between each component
and the status of each individual component during network operation. The
configuration data is gathered automatically by and stored in the NMS at the
network operation center (NOC). NMS display in real time the configuration of
the network and its status.

• Fault management
Fault management deals with the detection, isolation and correction of abnormal
operation of the OSI environment. When a fault occurs within a network, it is
important to perform the following tasks as quickly as possible. First, determine
where the fault is. Then, isolate the rest of the network from the failure so that the
rest of the network can continue to perform without any downtime or interference
from the faulted segment of the network. After this, reconfigure or modify the
network in such a way as to minimize the impact of the operation without the
failed operation. Finally, repair or replace the failed component as quickly as
possible to restore the network to its initial state before the failure.

• Performance management

9
Network Management System Implementation

Performance management is needed to evaluate the behavior of managed objects

and the effectiveness of communication activities. Performance management of a
network comprises two broad functional categories: monitoring ad controlling.
The monitoring function tracks activities on the network, whereas the controlling
function enables performance management to make adjustments to improve
overall network performance. The status of the network is displayed by a
network-monitoring system. The network statistics include data on traffic volume,
network availability and network delay. These data are useful for tuning the
network to increase its reliability and to improve its response time.

• Security management
Security management addresses those aspects of OSI security essential to operate
OSI network management correctly and to protect managed objects. Security
management is concerned with managing information protection and access
control facilities. The access control facilities include generating, distributing and
storing encryption key. Security management is also concerned with monitoring
and controlling access to the computer network and to all or part of the network
management information obtained from the network elements.

• Accounting management
Accounting management enables charges to be established for the use of managed
objects and cost to be identified for the use of those managed objects. The things
that need to be specified in accounting management are accounting information to
be recorded at various network elements, the desired interval between sending the
recorded information to higher level management elements, and the algorithms to
be used in calculating the charging. Metrics are established to measure the use of
resources and services. Traffic data gathered by performance management serves
as input to this accounting management. (Mani Subramanian 2000, page 135-
136; Dr Mohamed Othman, page 18-22; Wisniewski, page 123-167)

10
Network Management System Implementation

4. SNMP Protocol

A network provides ease of communication between computers. To use networks

effectively, there is a need of a set of rules by which all the networks should abide. The
set of rules is called protocols. Simple Network Management Protocol (SNMP) is one
among the various protocols that defines messages related to network management. In
simple terms, SNMP is a primary protocol, used in the transfer of network management
information between two or more network entities or nodes.

Most of the network components used in enterprise network systems have built-in
network agents that can communicate to an SNMP network management systems. Thus if
a new component (bridge, router, hub, etc) that has a built in SNMP agent, is added to a
managed network, the NMS then can communicate with the components and monitoring
it. The ease of changing the network causes wide acceptance of SNMP management
systems. There are 3 versions of SNMP that have been developed, SNMPv1, SNMPv2
and SNMPv3.

4.1 SNMPv1
This is the first version of the protocol. The rapid changing in technologies has changed
the shape of networks. Where once there were dumb terminals and a handful of
intelligent host clustered together and then reached out of communicate with one another.
The market then come out with new devices like remote bridges and switch hubs. Higher
bandwidth is needed for LAN-to-LAN networking. Customers began to acquire systems
and equipments from many different vendors. Each vendor produced a console product
that talked to its equipment using a handcrafted secret language. This situation causes the
network management more difficult and confusing.

For an effective transition of systems, a common network management framework had to

be developed that would be used by all vendors. This framework was named the Simple
Network Management Protocol (SNMP). SNMP is the standard network management
protocol for TCP/IP networks. Internet Protocols are open, nonproprietary standards

11
Network Management System Implementation

developed through voluntary efforts by the Internet community, so is the SNMP that is
actively maintained and all future enhancements to SNMP are based on existing protocol
standards. All major vendors support SNMP. All SNMP-managed devices use the same
type of management interface to support a common set of network management
information. (SNMP Overview, paragraph 8-10)

In addition, SNMP is independent of operating system and programming language. The

functional design of SNMP is also portable and it defines a core set of operations that
must function identically in all devices that support SNMP. Besides, SNMP facilitates the
addition of management capability to a device without impacting the operation of the
device or its performance. SNMP management may be added to a network device with
very little increase in workload and demand on system resources. SNMP is a core set of
operations that remain the same on all managed devices. SNMP has the capability of
supporting any type of information on any type of device that may be part of any type of
computer network. (SNMP Overview, paragraph 10)

Managed components that have built in SNMP agent can communicate with the manager
that resides in NMS. The manager queries the agent and receives management data,
process it and stores in its database. The agent can also send a minimal set of alarm
information to the manager unsolicited. In a three-tier configuration, the intermediate
network management system that locates at remote site is used to pass the information at
local to the central site. This allows distribute networks to be managed at a single site,
which is more economical and convenient. Alarm threshold could be set at the managed
component and generate alarms when the situation match a defined condition. With
SNMP, network map is automatically updated when any new component is added to the
network. The status of all components is monitored constantly by the NMS and alarm
generated whenever network failure found.

As the name goes, the protocol is quite simple because it is easy to understand and the
agent requires only minimal software. It has a minimal transport needs that uses only four
straightforward messages that read and write MIB values, and a fifth message to report

12
Network Management System Implementation

important events. The request message formats were designed so that an agent just “fills
in the blanks” and sends the answer back. (Mani Subramanian 2000, page 101-225)

The weakest point in the protocol is in the use of community names for authentication.
The community name is used to define which managers are allowed to submit get or set
requests and the same community name mapping is used to define access policies for
different managers. However, anybody who knows a community name with powerful
rights can act as a manager for a possibly large selection of nodes. And, in addition,
compromising a community name compromises the security of the management in the
network. The second problem with the security of the SNMP is the fact that there is no
privacy. That is, there is no possibility to encrypt the management message. When all the
traffic flows through unsecured public network, nobody can tell if someone is spying the
traffic. This means that eavesdropping and masquerading are the most obvious threats to
take place. (Security in SNMPv3 versus SNMPv1 or v2c, page 3)

4.2 SNMPv2
The SNMPv2 was created as an update of SNMPv1 with several features. The key
enhancements of SNMPv2 are focused on the SMI, Manager-to-manager capability, and
protocol operations. One notable deficiency in SNMP was the difficulty in monitoring
networks, as opposed to nodes on networks. A substantial functional enhancement to
SNMP was achieved by the definition of a set of standardized management objects
referred to as the Remote Network Monitoring MIB (RMON MIB) objects. (Versions of
SNMP, paragraph 4)

The basic components of SNMPv2 are the same as in version 1. However, SNMPv2
provides for better authentication and a more uniform syntax for SNMP messages, in
which trap messages are similar to other messages. In addition, SNMPv2 provides better
support for non-TCP/IP protocols and mechanisms for communication between SNMP
manager stations. Besides, SNMPv2 defines a new get_bulk SNMP message that is used
to make a request for all of the MIB variables in a device. This is an improvement over
SNMPv1, in which repeated get_next messages must be sent to read all of the MIB

13
Network Management System Implementation

variables for a device. Besides, SNMPv2 also defines another new inform-request
message which deals with interoperability of two network management systems, which
allows two managers to communicate to each other. (Network Management for Microsoft
Networks Using SNMP, paragraph 30)

Moreover, the textual conventions in SNMPv2 help defines new data types and makes it
more human readable. The conformance statements define a minimum set of capabilities
that the vendor can implement in their products so that it is compatible with the given
SNMP version. Enhancement has been made to the table, which allows adding or
deleting of conceptual rows, and joining tables together.

One of the weaknesses in SNMPv2 is that the security problems in SNMPv1 still not yet
solved. Another weakness is that SNMPv2 MIB is not backward compatible with
SNMPv1 and hence requires conversion of messages. Additional features have to be
added into system in order to solve this problem. Two schemes have been recommended
for migrating from SNMPv1 to SNMPv2: bilingual manager and SNMP proxy server
(will be discussed later in this section). (Mani Subramanian 2000, page 230-279)

4.3 SNMPv3
Both the SNMPv1 and SNMPv2 lack the following security-related features:
authentication, privacy, authorization and access control, and remote configuration and
administration capabilities. SNMPv3 was formed mainly to address the deficiencies
related to security and administration. The security aspect is addressed by offering both
strong authentication and data encryption for privacy. SNMPv3 defines two security-
related capabilities, namely the User-base Security Model (USM) and View-based
Access Control Model (VACM). (Versions of SNMP, paragraph 4)

USM provides authentication and privacy (encryption) functions and operates at the
message level. Based on the security level set in the message, the USM invokes the
authentication and privacy modules. The authentication module provides two services,
that is data integrity, and data origin authentication. The data integrity service validates

14
Network Management System Implementation

the message at receiving end and ensures that an unauthorized intruder has not modified
it during the communication process. Authentication protocols such as HMAC-MD5-96
or HMAC-SHA-96 are used. The data origin authentication service ensures that the
identity of the user is truly the originator of the message. To make the SNMPv3 secure
against this kind of flow manipulating attacks, the USM has a timeliness mechanism.
SNMPv3 demands that the messages must be received within reasonable time window.
For privacy, the USM uses Data Encryption Standard for ciphering messages. The CBC-
mode of DES is used. On the contrary, VACM determines whether a given principal is
allowed access to a particular MIB object to perform specific functions and operates at
the PDU level. It validates the sending sources and their access privilege for command
requests. (Security in SNMPv3 versus SNMPv1 or v2c, page 4-6)

SNMPv3 provides a framework for all three versions of SNMP and future development
in SNMP management with minimum impact on existing operations. All the SNMP
documents have been organized into document architecture. It addresses how existing
documents and new documents can be designed to be autonomous and to be integrated to
provide documentation for the various SNMP frameworks. Furthermore, SNMPv3 is
expected to include support for IPv6, the replacement for the current IP protocol (IPv4).
The only weakness of SNMPv3 is that it is expensive to implement due to the high
demand for processing needs. (Mani Subramanian 2000, page 284-292)

4.4 Integration of various SNMP versions

Since SNMPv2 is not backward compatible with SNMPv1, therefore different versions of
SNMP are not able to communicate with each other. There are three ways to integrate
various SNMP versions:

• Bilingual manager
Bilingual manager has both the SNMP version interpreter modules, which has the
profiles of the agents’ version. The interpreter modules perform conversions of
SNMP protocol operation and MIB variables in both directions. This approach is
expensive to implement and maintain. (Mani Subramanian 2000, page 277)

15
Network Management System Implementation

• Proxy server
A proxy server is implemented as a front-end module to the manager to allow
communication with different version SNMP agent. Therefore, it can be use to
convert SNMPv1 to SNMPv2. Another usage of proxy server is to converts any
protocol to send an SNMP compatible MIB and protocol. (Mani Subramanian
2000, page 278)

• SNMPv3
Dispatcher in the SNMP engine determines the version of the message and
interacts with the corresponding message processing model that handle version-
specific SNMP messages. SNMPv3 provides security measures to the network
system and many placeholders are available for future enhancement.
Consequently, it is the most preferable approach to be implemented for most of
the organization.

5. Event Correlation Techniques

16
Network Management System Implementation

When the NMS recognize errors in the network, it will try to identify the source of the
problem. Sometimes a single problem source may cause multiple symptoms. Act on each
symptom independently is time consuming and the symptom might not relate to the
problem. The two event correlation techniques that can be used to isolate the root cause
of the problem are Cased-based Reasoning and Codebook Correlation Model.

5.1 Cased-based Reasoning

In Case-Based Reasoning (CBR) systems expertise is embodied in a library of past cases.
Each case typically contains a description of the problem, plus a solution and/or the
outcome. The knowledge and reasoning process used by an expert to solve the problem is
not recorded, but is implicit in the solution. To solve a current problem: the problem is
matched against the cases in the case library, and similar cases are retrieved. The
retrieved cases are used to suggest a solution which is reused and tested for success. If
necessary, the solution is then revised and adapted. Finally the current problem and the
final solution are retained as part of a new case. (Case Based Reasoning, paragraph 1-
10)

Case-Based Reasoning contains four modules: input, retrieve, adapt, and process, along
with a case library. At first when there is a fault detected in the network, it will be treat as
an input for this technique. The past experience or resolution which also called trouble
ticket is retrieved from the case library and compared with the input. There are three
ways to adapt the previous case: (1) parameterized adaptation (2)
abstraction/respecialization adaptation, and (3) critic-based adaptation. When there is a
similar case in the library, parameterized adaptation will be used. For
abstraction/respecialization adaptation, when more than one resolution that match the
current problem, the user have to adapting either one of the resolutions. A new trouble
ticket is generated and stored into the case library for future reference. For critic-based
adaptation, a critic person have to decide add, remove, or reorder an existing solution.
Finally, retaining the case is the process of incorporating whatever is useful from the new
case into the case library. (Mani Subramanian 2000, page 519-522)

17
Network Management System Implementation

Case
Library

Input Retrie Adapt Proces

ve s

Figure 5: General CBR Architecture

(Mani Subramanian 2000, page 519)

The major limitations of Case-Based Reasoning are that it may not handle large volumes
of purely numeric data as well as statistical or neutral network techniques, and that if
complex adaptation is required to provide a precise or optimum answer, CBR retrieves
the most similar case and attempts to reuse the solution from that case. CBR does not
provide precise, exact or optimum solutions. In other words, CBR is not suitable in use
when case data is not available, complex adaptation is required or an exact optimum
answer is required. Besides, the case base sometimes grows to become unmanageable,
and case acquisition isn't always as easy as it is made out to be. In addition, CBR may
add more space requirements for storing cases, and more time requirements to perform
retrieval and matching. Reasoning with Cases in the CBR System: A Case Study for
Applying OOExpert System, page 3)

5.2 Codebook Correlation Model

Based on network modeling and network component behavior, algorithms can be used to
correlate the events in the network. Two models and one correlator are being used in this
approach. When there is any problem event, monitors will capture these events and input
them into the correlator. The configuration model defines the configuration of the
network whereas the event model represents the various events and their causal
relationships. The correlator correlates the alarm events with the event model. The

18
Network Management System Implementation

function of the correlator is to "decode" those messages "encoded" by the system that
triggered the alarm. There are two phases in the coding techniques. The first phase is
called the codebook selection phase. A symptom matrix codebook needs to be created in
this phase. It is a table like structure that shows the symptoms that uniquely identify each
problem. This table is derived from the causality graph. Note that the problems to be
monitored are identified based on expert knowledge. In the second phase, the correlator
compares the problem events with the symptom matrix codebook and identifies the
problem. (Mani Subramanian 2000, page 522-529)

Configuration Event
Model Model
Networ
Correlator Proble
k
ms
Monitors

Manag
ed
Object
Figure
s 6: General Codebook Correlation Model Architecture
(Mani Subramanian 2000, page 523)

In Codebook Correlation Model, knowledge is required to construct the codebook. In

addition, finding a complete or correct correlation matrix is difficult and time consuming.
This is because there might be multiple different possibilities of correlation matrix.
Moreover, finding an optional (with good hamming distance) correlation matrix is tuff
because it might be too big or too small. Assume we have a correct codebook, the
compression ratio is highly dependent on the event pattern and reliability. Another
limitation of Codebook Correlation Model is it has no adaptation. (Network Management
Event Correlation Techniques, page 8)

6. Conclusion

19
Network Management System Implementation

Each MIB data type has its own usage, limitations and relationship to other data types.
The OSI network management model is an ISO standard and is the most superior of all
the models; it is structured and it addresses all aspects of management. In fact, the
management is the most important to implement in an organization. Besides, the three
versions of SNMP have its pros and cons. As discussed earlier, the latest version,
SNMPv3 is the most powerful and secure version. It allows integration of existing
equipment with new equipment purchases and provides protection to the network system.
Tracing root cause of the problems is one of the issues in fault management. Case-Based
reasoning and Codebook Correlation Model can be used to track down the cause of the
problems. However, they have their own limitations.

7. References

20
Network Management System Implementation

RFC 1442, page 22-26

Dr Mohamed Othman, Hampehs! What The Hell Is It, viewed 19 September 2004,
<http://fsktm.upm.edu.my/~mothman/skr4301/bab3.pdf>

Mani Subramanian 2000, Netwoek management principles and practice, Addison-Wesley

Publishing Company Inc., page 105-117.

Mani Subramanian 2000, Netwoek management principles and practice, Addison-Wesley

Publishing Company Inc., page 135-136.

Winsniewski, S 2003, Advanced network administration, Prentice Hall, Upper Saddle

River, page 123-167.

SNMP Overview, viewed 19 September 2004, <http://www.adventnet.com/products/

snmputilities/help/quick_tour/snmp_and_mib/snmpmib_snmpoverview.html>

Mani Subramanian 2000, Netwoek management principles and practice, Addison-Wesley

Publishing Company Inc., page 101-225.

Security in SNMPv3 versus SNMPv1 or v2c, page 3, viewed 21 September 2004,

<http://www.aethis.com/solutions/snmp_research/snmpv3_vs_wp.pdf>

Versions of SNMP, viewed 19 September 2004, <http://www.adventnet.com/products/

snmputilities/help/quick_tour/snmp_and_mib/snmpmib_versionssnmp.html>

Network Management for Microsoft Networks Using SNMP, viewed 21 September 2004,
< http://www.microsoft.com/technet/prodtechnol/winntas/maintain/featusability/
networkm.mspx>

21
Network Management System Implementation

Mani Subramanian 2000, Netwoek management principles and practice, Addison-Wesley

Publishing Company Inc., page 230-279.

Mani Subramanian 2000, Netwoek management principles and practice, Addison-Wesley

Publishing Company Inc., page 284-292

Case Based Reasoning, viewed 21 September 2004, <http://www.aiai.ed.ac.uk/links/

cbr.html>

Mani Subramanian 2000, Netwoek management principles and practice, Addison-Wesley

Publishing Company Inc., page 519-529

Reasoning with Cases in the CBR System: A Case Study for Applying OOExpert System,
viewed 21 September 2004, <http://romisatriawahono.net/publications/2000/romi-
ijw2000.pdf>

Network Management Event Correlation Techniques, viewed 21 September 2004,

<http://www.mnlab.cs.depaul.edu/~ehab/Courses/TDC568/PDF/correlation.pdf>

22