CN1115636C - Category filtration: selecting method for managing objects in data tree - Google Patents

Abstract

The present invention relates to a new managed object (MO) selection method in a network management system, called class-level filtering (CLF). CLF goes between scoping and regular filtering operations, which reduces the selection of MOs in the containment tree of the network management system. The main idea of CLF is to use the class information of MO instances to exclude inappropriate managed objects from routine filtering operations, avoiding the large resource requirements that conventional filtering operations may cause on the managed system. In addition, a high-performance management information tree (MIT) structure is disclosed to support CLF.

Description

Class level filtering: new selection method for managed objects in the management information tree

technical field

The invention relates to a network management system, in particular to the selection of managed objects in the network management system of the telecommunication management network.

Background technique

Due to the rapid development of information and communication technology, it has become the trend of business affairs to connect with other communication networks and freely share data. However, even among business transactions established in the same area, network management platforms vary in organization and communication methods depending on the enterprise and established standards. Thus, there is a need for a global network management system that can efficiently and cooperatively manage various communication networks.

The Telecommunications Management Network (TMN) recommended by ITU-T (CCITT) is such a network management system. The TMN-type network management system provides a standardized interface for exchanging management information between network communication devices with different operating systems, so as to realize unified management of all types of communication networks. More specifically, the TMN system employs object-oriented information modeling techniques and the manager/agent concept, which form the basis of Open Systems Interconnection (OSI) system management.

In OSI system management, the system manager and agent model are used so that agents can manage objects. A Managed Object (MO) is generally an OSI abstract view of a logical or physical system resource to be managed. The MO class defines the properties of the object and a specific set of properties defines the MO instance. An MO instance has many relationships, of which the containment relationship is the primary relationship. Thus, the proxy must maintain a containment tree to express containment relationships between MO class instances. Therefore, the containment tree is the starting point of the agent's management operation and the core of MO management.

In the system managed by TMN, all MO instances are managed in the management information tree (MIT) established based on the containment relationship. A containment relationship allows one MO instance to contain one or more other MO instances, and a containing MO instance can be contained by other MO instances. Each MO instance is identified by a unique name based on a containment relationship. A management system specifies scope and filter parameters in a management operation primitive to request that a management operation be applied to one or more MO instances.

However, as communication networks become large and distributed, the number of resources that need to be managed grows. For example, an ATM switch supporting 60, 120 and 240 links requires about 7620, 15240 and 30480 MO instances in MIT only for configuration management. In such an MIT, selecting an appropriate MO instance becomes a management operation burden. However, the MIT is the starting point for management operations, which play a role in selecting the appropriate MO. Therefore, the performance of MIT greatly affects the network management system.

In particular, MIT requires that each MO instance have an attribute as a named attribute. This attribute and its assigned value constitute the Relative Distinguished Name (RDN), which is unique to all sibling MO instances. The Distinguished Name (DN) is formed by sequentially concatenating all relative Distinguished Names from the root managed object. Therefore, MOs in MIT can be accessed individually or collectively through object-oriented query tools.

As mentioned above, the selection of MO involves two stages, scoping and filtering. Scoping must identify the managed objects to be filtered. Scoping is specified with respect to a specific MO instance, which will be called the base managed object. The so-called basic managed object is the root of the MIT subtree, which is the starting point for scope definition and filtering.

A filter is a collection of one or more assertions that checks for the existence of property values of managed objects within a bounded range. If filtering involves multiple assertions, combine them with logical operators. If the filter tests are successful for a given MO, then that MO will be selected for management action. Such a filtering test is called MO-level filtering (MLF), which is a regular filtering, through which the equality, ordering, presence or set comparison of attribute values can be checked. carry out testing.

When management operations are performed on multiple MO instances, a series of interrelated results will be returned to the management system. Scoping and filtering have advantages in terms of expressiveness and minimizing the amount of management information exchanged in obtaining this result. However, conventional scoping and MLF may introduce unnecessary processing delays and unnecessary consumption of system resources when performing management operations. For MLF, the attribute value of MO must be obtained, and if MO is stored in DB (database) or file system, DB query or file I/O (input/output) operation must be performed when obtaining attribute value. Such access to storage devices when MLF is implemented creates a severe burden on the management system.

For example, a simple MIT as shown in FIG. 1 assumes that the basic managed object is {systemId=netjaguar, attrA1=A1}, and the scope of action is the entire subtree (that is, the basic object and all subobjects). If no filter is specified, all instances shown in this example will be picked and no MLF will be performed on any MO. If the specified filter is attrD2=D22, then MLF is performed on all instances in scope, and the fourth instance is selected for management operations. During this process, the first and second instances are still subject to MLF even though they do not contain the specified attribute (attrD2). Thus, the process involves unnecessary steps at the time of MLF.

Contents of the invention

One of the objects of the present invention is to solve at least the problems and disadvantages of the related art.

One of the objects of the invention is to improve the performance of a network management system. More specifically, one of the objects of the present invention is to increase the speed of MO selection operations in a network management system.

Another object of the present invention is to eliminate unnecessary processing delays and consumption of system resources in performing management operations. More specifically, one of the objects of the present invention is to eliminate unnecessary processing delays and system resource consumption when performing MO selection operations.

It is a further object of the present invention to provide additional filtering to simplify the MLF and to provide a new MIT structure to support this additional filtering.

Additional advantages, objects and features of the present invention will be set forth in the detailed description that follows, and will become apparent to those of ordinary skill in the art upon examination of the following parts or from practice of the present invention. The objects and advantages of the invention may be realized and realized as particularly pointed out in the appended claims.

To accomplish the foregoing, the class-level filtering (CLF) of the present invention is implemented between scoping and MLF, as broadly described herein. CLF utilizes MO class information to exclude inappropriate MO instances from MLF operations. In order to support CLF operation, the present invention also includes a high-performance MIT structure, which contains MO class information.

According to one aspect of the present invention, a method for selecting a managed object in the containment tree of a network management system is provided, wherein the network management system includes a management system and a plurality of managed objects, and the method includes the following steps: The range information given by the third-party system is used to define the range to identify the managed object; based on the class information of the managed object instance, the class-level filtering is performed on the managed objects within the range to exclude inappropriate managed object instances.

According to another aspect of the present invention, a management information tree structure of a network communication system is provided, including: a managed object instance and class information of the managed object instance, wherein the managed object node represents the managed object instance and contains The distinguished name of the managed object instance; the managed object information node contains the relative distinguished name of each managed object instance; and at least one managed object class node represents the managed object class.

According to another aspect of the present invention, a category-level filtering module is provided, including: a decomposer, which decomposes the filter structure into filter items and logical operators; an attribute checker, which receives the filter items and checks whether the attributes of the filter items belong to the Manage object classes; stack, which receives and stores logical operators from resolvers and stores results from attribute inspectors; stack evaluator, which evaluates logical expressions stored in the stack.

Description of drawings

The invention will now be described in detail with reference to the accompanying drawings, wherein like reference numerals correspond to like objects, wherein:

Figure 1 is an example of MIT;

Figure 2 is an example of a structure for class information management;

Figure 3A is an example of a containment relationship, and Figure 3B is the MIT of a containment relationship according to the present invention;

Figure 4 shows an example of class relationships according to the present invention;

Figure 5 shows an example of scoping operations in the present invention;

Figure 6 shows an example of CLF operation;

Figure 7 is the CLF module.

Detailed ways

As mentioned earlier, all MO instances available through the management interface in TMN are organized into MITs. As a result, the speed at which selection operations are performed on MOs greatly affects the overall performance of the network management system.

In the present invention, MOs are selected using class-level filtering (CLF), which is performed between two stages of scoping and MLF. CLF precedes MLF and does not replace MLF. It can be considered that CLF is an additional operation for efficient and fast MO selection. If a filter is specified, the CLF and MLF operations are performed sequentially after scoping completes the selection MO. CLF usually exploits the class information of MOs to exclude inappropriate MO instances from conventional filtering operations, namely MLF.

The present invention also includes a high-performance MIT structure to support the CLF feature. In the MIT according to the present invention, MO instances are classified according to their class information. According to OSI system management, MO classes are defined by several class elements, such as packages, attributes, operations, notifications, etc. Generally, some MO classes may share the same class element, that is, each class element can be used in multiple MO classes.

In order to effectively manage class information, class information can be stored in a separate structure, called Internal Data Structure (IDS) (Internal Data Structure), which is based on the consideration of class element reusability and search time. As shown in Figure 2, MO class information stores pointers to all packages contained in the MO class. Similarly, pointers to all information related to it are also stored in the package. A pointer to "MO class info" is kept in MIT. CLF can be performed using this structure.

In particular, a balanced binary search tree called an AVL tree and a doubly linked list are used as data structures to store class element information. For example, for the containment relationship shown in Figure 3A, its MIT structure is shown in Figure 3B. Each MO class node has an AVL tree to save child MO nodes. The AVL tree is used to search the basic MO node, and the double linked list is used to link sibling nodes. That is, a bidirectionally linked MO class node classifies its child MO nodes according to class. Therefore, the MIT of the present invention includes three parts: MO nodes, MO class nodes and MO information nodes.

MO nodes represent MO instances, which must be accessible from storage, eg by means of a database or file system. The MO node also includes the Distinguished Name (DN) of the MO instance. The MO information node has a relative distinguished name (RDN) of each MO instance, which can be used as a key value to traverse the AVL tree to find MO nodes with the same RDN. The MO class node is an intermediate node between a parent node and several child nodes, and each MO class node represents a MO class and can access IDS.

Both the design and implementation of MIT and CLF according to the present invention use an object-oriented approach. Thus, in the preferred embodiment all tree nodes are implemented as C++ classes. The relationship between classes is shown in Figure 4, where the core classes are CT, CTMONode, CTClassNode and MOInfo. Class CT represents MIT itself, and an instance of this class exists in the management system. It provides many methods to insert, delete and find MO instances. These interfaces are also available to other parts of the implemented TMN platform. It also provides MO selection tools for scoping and filtering.

The class CTMONode represents the MO instance and allows MIT users (ie other parts of the platform or the management system developer's code) to access the MO instance. This MO instance contains the location information of the MO instance in memory. The class CTClassNode represents an MO class, and aggregates and manages MO nodes belonging to the same MO class. Class CTClassNode also contains IDS interfaces, which are used for CLF within this node. The class MOInfo is designed for the nodes that constitute the AVL tree, and the AVL tree belongs to each MO class node. MOInfo contains RND and can be used as a key value to search for MO in the AVL tree. Class SearchTree and class List are template classes that provide the functionality of AVL trees and linked lists.

Generally, when a managing system requests a management operation with scoping and filtering restrictions, the managed system must find the base node or base MO as the starting point of the scoping operation. MOs that meet the scope information specified by the administrator's system must be selected. Correspondingly, the search for the basic nodes in MIT is carried out by means of an AVL tree, which contains child nodes classified according to MO classes at various levels. As mentioned above, each MO node has a unique name among all sibling nodes, that is, RDN, which is the key value of the AVL tree. RDN enables MIT users to efficiently find basic MO nodes by traversing the AVL tree.

The scope definition is carried out on the basis of the scope information given by the management system. In the present invention, scoping is performed cyclically in a given MIT, resulting in the selection of one or more MO nodes, including the base MO. Scoping consists of two while loops, where the outer loop imports MO class nodes and the inner loop imports MO nodes in MIT. Depending on the range type, the way to import nodes is also different. Figure 5 is an example of scoping, where the scope type is "baseToNthLevel" (baseToNthLevel), and the level is 2.

Although the scoping of MO class nodes may seem redundant, class nodes are necessary for CLF, and in practice the time added to this scoping operation is negligible compared to the time shortened by using CLF. Here is the Pascal-like code for the MIT scoping algorithm:

           
type
SCOPETYPE = {wholesubtree, subtree, baseToNthLevel and nthlevel};
MONODE＝↑CTMONode {MO node);
CLASSNODE = ↑ CTCLASSNODE {class node};
        <!-- SIPO <DP n="7"> -->
        <dp n="d7"/>
procedure Scoping(sType SCOPETYPE, sLevel: integer, moNode: MONODE);
var

    tmpmonode: MONODE;

    tmpclassnode: CLASSNODE;

    level: static integer; {To maintain the tree depth in recursive calling}
begin

       level:=1;

       tmpclassnode:=Header of class node list contained in moNode;

       while tmpclassnode is not nil do

    begin

       tmpmonode:=First child MO node of tmpclassnode;

       while tmpmonode is not nil do

      begin

           if(level＜sLevel)and(tmpnode has one or more class nodes))then

          begin

               level:=level+1;

               Scoping(sType, sLevel, tmpmonode);

               Visiting tmpmonode;

               Level: = level-1
          end

          else if(((level<sLevel)and(tmpnode does not have any class node))or(level=sLevel))

          begin

               Visiting tmpmonode

          end;

          tmpmonode := tmpmonode↑.next

     end; {inter loop}

     tmpclassnode:=tmpclassnode↑.next
  end{outer loop}
end; {Scoping}

        

After scoping, filtering is performed to decide whether to implement management actions on the MO instances in scope. If the result is false, no administrative action is performed. If the number of MO instances selected for scoping is large and/or the filter is complex, the time consumed by the filtering operation will greatly affect the total time to perform the management operation. Since the MIT of the present invention contains MO instances and their MO class information, it is possible to exclude instances of inappropriate classes from the filtering operation of the CLF.

Figure 6 shows a simple example of a CLF. Given that the filtering information is "(a=1 ORb>10) AND id=panzee", if a certain MO class does not contain the attribute "a", MLF will not be executed on the instance of the MO class. That is, "(a=1 OR b>10) AND id=panzee" is simplified to "b>10 AND id=panzee". Also, if there is no attribute "id" in a certain MO class, the filter expression becomes FALSE, and there is no need to perform management operations on the instance of this MO class. As a result, the unnecessary overhead of performing MLF on inappropriate MO instances will be greatly reduced.

In particular, CLF uses the stack data structure to calculate the value of the logical expression of CMISFilter, which is the filter structure recommended by X.710. The CLF module decomposes the CMISFilter and divides the expressions into two groups. A group is a collection of filter items, which are submitted to the attribute inspector 10, as shown in FIG. 7 . A filter item consists of an attribute OID and its value. With the help of the information of the IDS, the attribute checker 10 checks whether the attribute contained in the filter item 20 belongs to the MO class. Another group is a collection of logical operators, such as "and", "or" or "not", which are stored directly in the stack 30. After unpacking the CMISFilter into the stack, the CLF uses the stack evaluator 40 to compute the value of the filter. Here is the Pascal-like code for the MIT algorithm:

           
POP(var S: FILTERSTACK) {Delete the top element of stack S}
PUSH(s: STACKITEM, var S: FILTERSTACK) {Insert the element at the top of stack S}
TOP(s: FILTERSTACK): STACKITEM {Return the element at the top of stack S}
ATTR_CHECKER(attroid: OID, class: ↑MO_Class_Info): boolean

                                      {Check if class contains attribute(oid)}
type<br/>
STACKITEM=record

    item: boolean;

    op: integer
end;
FILTERSTACK=record

     stack: array[1..n]of STACKITEM;

     top; integer
end;
procedure ClassLevelFiltering(filter: ↑CMISFilter): boolean;
var
   stack: FILTERSTACK;
   a, b; STACKITEM;
   tmp bool; boolean;
   tmpstackitem: STACKITEM;
   level: integer;
        <!-- SIPO <DP n="9"> -->
        <dp n="d9"/>
    tmpfilter:↑CMISFilter;
begin

      if filter = nil then

          return (true); {If filter is null, then return true}

      if(filter↑, filter_type <> Filter_Item) then begin

          tmpstackitem.op;=filter↑.filter_type;

          PUSH(tmpstackitem, stack);

          tmpfilter:=filter↑.filter_filter;

          increment level by 1; {Increment filter depth}

          ClassLevelFiltering(tmpfilter); {Recursive calling}

          decrement level by 1; {Decrement filter depth}

          if(filter↑.filter_type=And) then begin

                               {Evaluation 'And' operator}

               a:=TOP(stack); POP(stack);

               b:=TOP(stack); POP(stack);

               tmpbool:=((a.item=true)AND(b.item=true));

               while TOP(stack).op=Filter_Item do being

                   a = TOP(stack); POP(stack);

                   tmpbool:=(tmpbool AND(a:item=true))

               end;

               POP(stack); {For removing AND from stack}

               {Push the result of'And'evaluation}

               tmpstackitem.op:=Filter_Item;

               tmpstackitem.item = tmpbool;

               PUSH(tmpstackitem, stack)

           end

           else if(filter↑.filter_type=Or) then begin

                                         {Evaluation'Or'operator}

                a:=TOP(stack); POP(stack);

                b:=TOP(stack); POP(stack);

                tmpbool := NOT((a.item=false) AND(b.item=false));

                if(tmpbool=false) then begin

                   while TOP(stack).op=Filter_Item do begin

                         a:=TOP(stack); POP(stack);

                         tmpbool :=((tmpbool=false) AND (a.itern=false))

                   end

                 end

                 else begin

                      while top. op of stack is Filter_Item

                             POP(stack)

                 end;

                 {Push the result of 'Or' evaluation}

                 POP(stack); {For removing Or from stack}
        <!-- SIPO <DP n="10"> -->
        <dp n="d10"/>
             tmpstackitem.op:=Filter_Item;

             tmpstackitem.item = tmpbool;

             PUSH(tmpstackitem, stack)

        end

        else if(filter↑.filte_rtype=Not) then begin

               {Push tne result of'Not'evaluation}

               a:=TOP(stack); POP(stack);
               if(a: item=true) then begin

                     tmpstackitem.op = Filter_Item;

                     tmpstackitem.item=false

                end

                else begin
               {Push the result of'Not'evaluation}

               PUSH(tmpstackitem, stack)

          end

      end

      else begin

          tmpstackitem.op = Filter_Item;

          {Check that class contains attribute(oid) and return the result}

          tmpstackitem.item:=ATTR_CHECKER(filter↑.filter_item↑.attr_oid);

          PUSH(tmpstackitem, stack);

          if filter↑.filter_next is not nil then begin

               tmpfilter:=filter↑.filter_next;

               ClassLevelFiltering(tmpfilter){Recursive calling}

          end

    end;
iflevel is nil then begin

      {Return the result of CLF}

      a:=TOP(stack); POP(stack);

      return a.item
end
end; {End of procedure}

        

As shown in Figure 7, the CLF module can be divided into four parts. The decomposer 50 decomposes the CMISFilter into filter items 20 and logical operators, and sends them to the attribute inspector 10 and the stack 30 respectively. The attribute checker 10 is the core module of CLF, it uses the IDS interface to judge whether the attribute of the filter item 20 belongs to the MO class. The stack 30 stores the logical operators passed by the parser 50 and the Boolean results produced by the attribute inspector 10 . The stack evaluator 40 performs computational evaluation of logical expressions stored in the stack 30 .

CLF greatly reduces the number of MO nodes for MLF. However, CLF is not suitable for very simple filters. Therefore, the CLF can be switched in real time by a specific action performed by the management system. Thus, the decision whether to implement the CLF rests with the administrator system. The administrator can switch the CLF by performing specific actions according to specific situations.

If there are multiple manager systems connected to a managed system, each manager can autonomously decide on switching characteristics in real time. To support this capability, the managed system maintains handover information for each managing system, which is distinguished from each other by an association descriptor, which is obtained from the ACSE stack when an association is established. Whenever receiving a management operation instruction from a management system, the managed system checks the association descriptor and decides whether to execute the CLF.

In summary, CLF does not need to extract attribute values compared with MLF. CLF uses information of MO classes residing in main memory. Since CLF simply checks for the existence of the attribute without extracting the attribute value, it can be completed in a very short time. It also doesn't require DB (database) or file access. Thus, CLF allows efficient management operations, thereby increasing the efficiency of the network management system.

The above-mentioned embodiments are merely exemplary, and the present invention should not be construed dogmatically as being limited thereto. This technique can be easily applied to other types of devices. The description of the present invention is presented for purposes of illustration and not to limit the scope of the claims. Obviously, many alternatives, modifications and variations are possible. The conclusion is that the speed of the MO selection operation greatly affects the overall performance of the network management system for those skilled in the art.

Claims (18)

1. choose the method for managed object during the containing in network management system is set, wherein network management system comprises manager system and a plurality of managed object, said method comprising the steps of:

Carry out scope definition with the identification managed object based on the range information that the manager system provides;

Category information based on Managed Object Instance carries out category filtration to get rid of unsuitable Managed Object Instance to the managed object in the scope.

2. method as claimed in claim 1, wherein scope definition comprises the basic managed object that identifies as the subtree root that contains tree, it is the starting point of scope definition and category filtration.

3. method as claimed in claim 1 also comprises:

Carry out the managed object layer and filter with decision whether the resulting managed object of category filtration is managed operation.

4. method as claimed in claim 3, wherein the managed object layer filters and comprises whether the property value of judging in the resulting managed object of category filtration satisfies the given filtering information of manager system.

5. method as claimed in claim 1 also comprises:

Storage Managed Object Instance and category information thereof in containing tree.

6. method as claimed in claim 5 wherein adopts the balanced binary search tree to store the category information of Managed Object Instance.

7. method as claimed in claim 6, wherein scope definition comprises the basic managed object that uses the balanced binary search tree to identify the subtree root of setting as containing, it is the starting point of scope definition and category filtration.

8. method as claimed in claim 5 also is included in to contain in the tree and connects fraternal Managed Object Instance with double linked list.

9. method as claimed in claim 5, the node that wherein contains tree is realized with C++ class.

10. method as claimed in claim 1 also comprises:

The category information separate storage of Managed Object Instance uses IDS to carry out category filtration in IDS.

11. method as claimed in claim 1, wherein category filtration is by the supvr of manager system switch in real time.

12. the management information tree construction of a network communicating system comprises:

Managed Object Instance, and

The category information of Managed Object Instance, wherein,

The managed object node is represented Managed Object Instance and is contained the difference name of Managed Object Instance;

The managed object information node contains the relative distinguished name of each Managed Object Instance; With

Have at least a managed object category node to represent Managed Object Class.

13. as the management information tree construction of claim 12, wherein managed object information node formation can be in order to search for the balanced binary search tree of basic managed object.

14. as the management information tree construction of claim 12, wherein the managed object category node is the intermediate node between father's managed object node and its a plurality of sub-managed object node.

15., be bi-directional chaining between the wherein fraternal managed object node as the management information tree construction of claim 12.

16., be bi-directional chaining between the wherein fraternal managed object category node as the management information tree construction of claim 12.

17. a category filtration module comprises:

Resolver is decomposed into filtering item and logical operator with filtration device structure;

Property inspector, whether receiving filtration item and the attribute of examining filtering item belong to Managed Object Class;

Stack receive and store the logical operator from resolver, and storage is from the result of property inspector;

The stack evaluation program is calculated the value that is stored in the logical expression in the stack.

18. as the category filtration module of claim 17, wherein filtration device structure is CMISFilter.

Images