Network Management System Report by alanmoney

VIEWS: 557 PAGES: 22

More Info
									Network Management System Implementation



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.



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.


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.


Network Management System Implementation


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)


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)


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 TEXTUALCONVENTION 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)


Network Management System Implementation


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.


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.
MDB Manager

Managed objects Unmanaged objects MDB Management Database Agent process

Figure 1: Two-tier Network ManagementOrganization M odeModel Figure 3.2 Two-Tie r Ne twork M ange me nt Organisation 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).




Agent / Manager

Managed objects MDB Management Database Agent process

Figure 3.3 Thre e -Tie Ne twork M ange me nt Organization M ode Figure 2: Three-tier Networkr Management Organisation Model 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)


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


Network Management System Implementation

information model is specifies the information base in order to describe managed objects and their relationships.

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)


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,


Network Management System Implementation

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 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)

Operations / Requests Manager Applications Responses Notifications / Traps Agent Network Elements / Managed Objects

Figure 3.11 M anagement M e ssage Communication M ode l Figure 3: Management Message Communication Model (Mani Subramanian 2000, page 116)

Manager Applications

Operations / Requests / Responses Traps / Notifications

Agent Applications

Manager Communication Module

SNMP (Internet) CMIP (OSI)

Agent Communication Module

Transport Layers

UDP / IP (Internet) OSI Lower Layer Profiles (OSI)

Transport Layers

Physical Medium

Figure 3.12 Management Communication Transfer Protocols Figure 4: Management Communication Transfer Protocols

(Mani Subramanian 2000, page 117)


Network Management System Implementation


Functional Model

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.


Network Management System Implementation


Performance management 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 135136; Dr Mohamed Othman, page 18-22; Wisniewski, page 123-167)


Network Management System Implementation


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.



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


Network Management System Implementation

protocol for TCP/IP networks. Internet Protocols are open, nonproprietary standards 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


Network Management System Implementation

straightforward messages that read and write MIB values, and a fifth message to report 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)



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


Network Management System Implementation

SNMPv1, in which repeated get_next messages must be sent to read all of the MIB 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)



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 securityrelated 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,


Network Management System Implementation

that is data integrity, and data origin authentication. The data integrity service validates 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 CBCmode 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)


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


Network Management System Implementation

SNMP protocol operation and MIB variables in both directions. This approach is expensive to implement and maintain. (Mani Subramanian 2000, page 277) 

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 versionspecific 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.


Network Management System Implementation


Event Correlation Techniques

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.


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)


Network Management System Implementation

Case Library


Retrie ve


Proces 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)


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


Network Management System Implementation

relationships. The correlator correlates the alarm events with the event model. The 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 Model

Event Model Correlator

Proble ms

Networ k


Figure 6: General Codebook Correlation Model Architecture Manage (Mani Subramanian 2000, page 523) d Objects

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)


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.


Network Management System Implementation



RFC 1442, page 22-26

Dr Mohamed Othman, Hampehs! What The Hell Is It, viewed 19 September 2004, <>

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, < 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, <>

Versions of SNMP, viewed 19 September 2004, < snmputilities/help/quick_tour/snmp_and_mib/snmpmib_versionssnmp.html>

Network Management for Microsoft Networks Using SNMP, viewed 21 September 2004, < networkm.mspx>


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, < 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, <>

Network Management Event Correlation Techniques, viewed 21 September 2004, <>


To top