**4. Management information and knowledge management structure**

Management information models are abstractions of the network resources. They define the structures and contents of management information that the management functions act upon. A management information model provides a common characterization of the network resources, enables multiple management functions to interact with each other, and supports different management functions (Huang, 2008). Management information is exchanged among management systems where management functions are implemented (Goleniewski & Jarrett), 2006).

Attaining interoperability of network management systems and a common view of managed resources in a managed network environment requires that information models comply with standard models. The management functions currently exchange management information by means of techniques defined in ITU-T X.700.

These recommendations incorporate the important object-oriented and manager/agent paradigms for information modelling. The object-oriented approach for information exchange allows for grouping of data and the executable operations to be fully encapsulated into an object and object properties to be extended through "inheritance." The data can be manipulated only via the access operations provided in the object. The guidelines for the definition of managed objects, ITU-T Recommendation X.722 allow for a common data structure for managed objects in the managed and managing systems. Managed objects include their names, attributes, operations that can be performed on attributes, notifications that objects can emit, and behaviour descriptions of the objects.

The definition of a managed object class is made uniformly in the standard template, eliminating the confusion that may result when different persons define objects of different forms. This template is used to define the different kinds of objects that exist in the system. Classes describe what information and services they provide each manage object and GDMO defines format for this information (Kuo et al., 2005). This way we ensure that the classes and the management expert rules defined in system A can be easily interpreted in system B. Managed object class structure is show here:

```
<class-label> MANAGED OBJECT CLASS 
    [DERIVED FROM <class-label> [,<class-label>]*;] 
    [CHARACTERIZED BY <package-label> [,<package-label]*;] 
    [CONDITIONAL PACKAGES 
    <package-label> PRESENT IF condition; 
    ,<package-label>] PRESENT IF condition]*;] 
REGISTERED AS object-identifier; 
                                                                        (1)
```
DERIVED FROM clause specifies the superclass or superclasses from which this managed object is derived (inherited). This plays a very important role, when determining the relations of inheritance which makes it possible to reutilize specific characteristics in other classes of managed objects. In addition, a great advantage is the reusability of the object classes and therefore of the expert rules which are defined. By using this clause, any attribute, operation, notification, and behaviour exposed by managed objects, as well as inheritance and containment relationships among managed objects and managed object classes, can be defined, figure 5.

Fig. 5. Inheritance between classes

28 New Research on Knowledge Management Technology

attribute will define all the aspect about the management knowledge in a specific managed object class. The set of managed object classes and instances under the control of an agent is knows as it's a MIB, an abstraction of network resources properties and states for the purpose or management. The MIB, which is specified using the Structure Management

Two relationships are essential for the inclusion of knowledge in the component definition of the network: Managed Object Class and Package. GDMO includes the basic template MANAGED OBJECT CLASS, which is always implemented and GDMO also defines an optional template named PACKAGE, which defines a combination of properties for later

Management information models are abstractions of the network resources. They define the structures and contents of management information that the management functions act upon. A management information model provides a common characterization of the network resources, enables multiple management functions to interact with each other, and supports different management functions (Huang, 2008). Management information is exchanged among management systems where management functions are implemented

Attaining interoperability of network management systems and a common view of managed resources in a managed network environment requires that information models comply with standard models. The management functions currently exchange management

These recommendations incorporate the important object-oriented and manager/agent paradigms for information modelling. The object-oriented approach for information exchange allows for grouping of data and the executable operations to be fully encapsulated into an object and object properties to be extended through "inheritance." The data can be manipulated only via the access operations provided in the object. The guidelines for the definition of managed objects, ITU-T Recommendation X.722 allow for a common data structure for managed objects in the managed and managing systems. Managed objects include their names, attributes, operations that can be performed on attributes, notifications

The definition of a managed object class is made uniformly in the standard template, eliminating the confusion that may result when different persons define objects of different forms. This template is used to define the different kinds of objects that exist in the system. Classes describe what information and services they provide each manage object and GDMO defines format for this information (Kuo et al., 2005). This way we ensure that the classes and the management expert rules defined in system A can be easily interpreted in

Information (SMI) defines the actual objects to be managed (Clemm, 2006).

**4. Management information and knowledge management structure** 

inclusion in a managed object class template.

information by means of techniques defined in ITU-T X.700.

that objects can emit, and behaviour descriptions of the objects.

system B. Managed object class structure is show here:

[CONDITIONAL PACKAGES

REGISTERED AS object-identifier;

<class-label> MANAGED OBJECT CLASS

[DERIVED FROM <class-label> [,<class-label>]\*;]

 <package-label> PRESENT IF condition; ,<package-label>] PRESENT IF condition]\*;]

[CHARACTERIZED BY <package-label> [,<package-label]\*;]

(1)

(Goleniewski & Jarrett), 2006).

Packages included in the object class definition are identified by the CHARACTERIZED BY and CONDITIONAL PACKAGES clauses. The CHARACTERIZED BY clause identifies the package or packages that are always present when the managed object is included in the system. The CONDITIONAL PACKAGES clause is used to identify those packages that may or may not be included each time the managed object of this class is instantiated. Finally, the REGISTERED AS clause identifies the location of the managed object class on the OSI registration tree (Stallings, 2000).

#### **4.1 Package template**

The PACKAGE template is used to specify the characteristics that represent a consistent set of specifications about a network resource. One purpose of the package is to provide a set of re-useable definitions that can be used in several managed object class specifications. All the properties that we define in the package will be included later in the Managed Object Class Template, where the package is incorporated. A same package can be referenced by more than one class of managed objects. For each managed objects class, the following information is defined:


The current template package in GDMO standard is adapted and we add a new feature. In addition to the properties indicated above, we suggest the incorporation of a new property called RULES and its associated template called "RULE", which contains all the specifications of the knowledge base for the expert system, figure 6.

Integration of Knowledge Management in the MIB for the Network Management 31

In our study case the template RULE permits the normalized definition of the specifications of the expert rule to which it is related. This template allows a particular managed object class to have properties that provide a normalized knowledge of a management dominion.

> [BEHAVIOUR <behaviour-label> [,<behaviour-label>]\*;] [IF occurred-event-pattern [,occurred-event-pattern]\*]







In order to evaluate the fault management capabilities of the integrate management solution proposed we have simulated an application that monitors an environment to collect fault event data (Baker et al., 2008). As said before we have considered a private network. We suppose this network as being heterogeneous and hierarchical. The intelligent sensor nodes only disseminate data when the network is being monitored and an error occurs in a

The use of integrate knowledge in agents can help the system administrator in using the maximum capabilities of the intelligent network management platform without having to use other specification language to customize the application (Akinyokun & Imianvan, 2006). Our system has the following components: an inference engine, a knowledge base, and a

condition that will be applied on the events occurred or their parameters.

rule on the OSI registration tree. The identifier is compulsory.

**5. Fault management application using GDMO+ specifications** 

After the head, the following elements compose a normalized definition of an expert rule. - BEHAVIOUR: This construct is used to extend the semantics of previously defined templates. It describes the behaviour of the rule. This element is common to the others

(3)

The structure of the RULE template is shown here:

[PRIORITY <priority> ;]

REGISTERED AS object-identifier;

the specifications for the management expert rule.

[THEN sentence [, sentence]\* ;]

The first element in a template definition is headed. It consists of two sections:

<rule-label> RULE

have a unique characterizing name.

templates of the GDMO standard.

resource (Premchand et al., 2008), figure 7.

rules will be executed.

occurred.

user interface, figure 8.

Fig. 6. New rule template.

Next definition shows the elements of a package template, in which it is possible to observe the new property RULES.

```
<package-label> PACKAGE 
    [BEHAVIOUR <behaviour-label> [,<behaviour-label>]*;] 
    [ATTRIBUTES <attribute-label> propertylist [,<parameter-label>]* 
    ,<attribute-label> propertylist [,<parameter-label>]*]*;] 
    [ACTIONS <action-label> [<parameter-label>]* 
    [<action-label> [<parameter-label>]*]* ; 
    [NOTIFICATIONS <notification-label> [<parameter-label>]* 
    [<notification-label> [<parameter-label>]*]* ;] 
    [RULES <rule-label> [,<rule-label>]*;] 
REGISTERED AS object-identifier; 
                                                                          (2)
```
The property RULES allows a treatment similar to the other properties, including the possibility of inheritance of rules between classes. Like the rest of the other properties defined in a package, the property RULES needs a corresponding associated template.

#### **4.2 Expert rule template**

There are a number of different knowledge representation techniques for structuring knowledge in an expert system. The three most widely used techniques are expert rules, semantic nets and frames (Brachman & Levesque, 2004). For this study we use expert rules. We represented the knowledge in production rules or simply rules. Rules are expressed as IF-THEN statements which are relatively simple, very powerful as well as very natural to represent expert knowledge. A major feature of a rule-based system is its modularity and modifiability which allow for incremental improvement and fine tuning of the system with virtually no degradation of performance.

Next definition shows the elements of a package template, in which it is possible to observe

 [ATTRIBUTES <attribute-label> propertylist [,<parameter-label>]\* ,<attribute-label> propertylist [,<parameter-label>]\*]\*;]

The property RULES allows a treatment similar to the other properties, including the possibility of inheritance of rules between classes. Like the rest of the other properties defined in a package, the property RULES needs a corresponding associated template.

There are a number of different knowledge representation techniques for structuring knowledge in an expert system. The three most widely used techniques are expert rules, semantic nets and frames (Brachman & Levesque, 2004). For this study we use expert rules. We represented the knowledge in production rules or simply rules. Rules are expressed as IF-THEN statements which are relatively simple, very powerful as well as very natural to represent expert knowledge. A major feature of a rule-based system is its modularity and modifiability which allow for incremental improvement and fine tuning of the system with

(2)

[BEHAVIOUR <behaviour-label> [,<behaviour-label>]\*;]

 [NOTIFICATIONS <notification-label> [<parameter-label>]\* [<notification-label> [<parameter-label>]\*]\* ;]

 [ACTIONS <action-label> [<parameter-label>]\* [<action-label> [<parameter-label>]\*]\* ;

**[RULES <rule-label> [,<rule-label>]\*;]** 

Fig. 6. New rule template.

the new property RULES.

**4.2 Expert rule template** 

<package-label> PACKAGE

REGISTERED AS object-identifier;

virtually no degradation of performance.

In our study case the template RULE permits the normalized definition of the specifications of the expert rule to which it is related. This template allows a particular managed object class to have properties that provide a normalized knowledge of a management dominion. The structure of the RULE template is shown here:

> <rule-label> RULE [PRIORITY <priority> ;] [BEHAVIOUR <behaviour-label> [,<behaviour-label>]\*;] [IF occurred-event-pattern [,occurred-event-pattern]\*] [THEN sentence [, sentence]\* ;] REGISTERED AS object-identifier; (3)

The first element in a template definition is headed. It consists of two sections:


After the head, the following elements compose a normalized definition of an expert rule.

