JP2001084198A - Manager agent system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To easily obtain an optimal DN(distinguished name) for allowing a manager to designate a management object. SOLUTION: A manager 100 is provided with a DN conversion table 121 for recording a conversion rule between a manager side DN and an agent side DN, and an alias registration processing part 122 for recording a conversion rule between a manager application side DN(MDN) and an agent side DN(AND) in the DN conversion table 121 according to a request from a manager application 110.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to a method for managing a management object (Ma) in an agent.
naged Object: MO) This relates to a manager agent system that specifies an instance.

[0002]

2. Description of the Related Art For example, CMIP (Common Management)
2. Description of the Related Art There is known a manager-agent system in which a manager as a management system using an Information Protocol) manages an agent as a management object via a network.

Here, CMIP is based on OSI (Open System Interface) standardized by ISO (International Organization for Standardization).
rconnection) is a protocol for management. In general, in a system having a manager-agent relationship, a manager specifies an instance of a managed object in an agent (hereinafter, referred to as an “MO instance”) by an instance name derived from a containment tree relationship. Such instance name is DN (Di
stinguished Name).

FIG. 2 is an explanatory diagram showing an example of a containment tree. In the example illustrated in FIG. 2, the managed objects MO-b and MO-c are included in the managed object MO-a, and the managed objects MO-d and MO-e are included in the managed object MO-b.

FIG. 3 is an explanatory diagram showing an example of a DN in such an inclusive relation. DN is a target managed object MO from a managed object MO-a which is a vertex of the containment tree.
-The RDN of the managed object on the route to reach e
(Relative DN: a pair of a naming attribute ID and a naming attribute value).

[0006] The containment relationship of a managed object is usually determined by the physical and logical containment relationship of the entity represented by the managed object. However, since the management object in the agent that the manager wants to operate abstracts various characters, it is often the case that the containing tree of the tree structure alone is not enough to express the relationship. That is, there is often a case where a manager wants to specify a certain MO instance by a relationship other than the containing tree. In such a case, a method of giving the DN of the management object to another management object as a relation attribute is used. in this case,
In order to specify the target managed object, first, a managed object having a relation attribute pointing to the target managed object is specified, and the DN of the relation attribute is obtained.
An operation of designating a target management object is performed by the obtained DN. If the DN of the target managed object cannot be obtained by one operation, the acquisition of the relation attribute is repeated to obtain the DN indicating the target managed object.

[0007]

By the way, in developing a manager system, a development platform in which details of a protocol such as CMIP are hidden is often used. In a conventional manager agent system, a manager application running on a platform must specify an MO instance using a DN.
However, if the DN cannot be generated directly from the information possessed by the manager application, the manager application repeatedly obtains the relation attributes,
A DN specifying the MO instance will be obtained.

Therefore, the manager application performs very complicated processing when designating the MO instance, which leads to a decrease in execution efficiency, an increase in the scale of development of the manager application, and a decrease in development efficiency.

[0009]

The present invention employs the following structure to solve the above problems. <Configuration 1> A manager agent system according to the first aspect of the present invention forms a relationship between a manager as a managing system and an agent as a management target system on a computer, and a plurality of management targets in the agent. In a manager-agent system in which a containment tree indicating the relationship between each instance of a managed object is constructed, a manager-side identifier for designating a managed object having a containment-tree relationship from the manager and a containment used by the agent. It comprises an identifier conversion table for recording a conversion rule with an agent-side identifier corresponding to a tree, and an alias registration processing means for registering a conversion rule in the identifier conversion table.

<Structure 2> In the manager agent system according to the second aspect of the present invention, the manager searches the identification name conversion table and, if a corresponding conversion rule is registered, identifies the manager in accordance with the conversion rule. A message transmitting means for converting the name into an agent-side identifier, including the converted agent-side identifier in a message, and transmitting the message.

<Structure 3> In the manager agent system according to the third aspect of the present invention, when the manager receives a message including the agent-side identifier from the agent, the manager searches the identifier conversion table and registers the corresponding conversion rule. If so, a message receiving means for converting the agent-side identifier to the manager-side identifier in accordance with the corresponding conversion rule is provided.

<Structure 4> In the manager agent system according to the invention of claim 4, when the message transmitting means converts the identifier in the message according to the conversion rule registered in the identifier conversion table, an invoke identifier is provided. The message receiving means, when receiving the response message, searches the identifier conversion table based on the invoke identifier included in the response message, identifies the conversion rule, and identifies the identifier. It is configured to perform an inverse transformation.

<Structure 5> In the manager agent system according to the invention of claim 5, when the message receiving means receives a message indicating that the management object is to be deleted from the agent, the conversion rule including the identification name of the management object. Is deleted from the conversion table.

<Structure 6> In a manager agent system according to the invention of claim 6, a relationship between a manager as a managing system and an agent as a managed system is formed on a computer, and a management target is stored in the agent. In a manager agent system in which a containment tree showing the relationship between each instance of a plurality of managed objects is constructed, a new containment relationship is specified so that an instance of a predetermined managed object can be designated by a containment relationship different from the constructed containment tree. A system for generating a message, wherein the manager includes a message transmitting unit that includes a parameter necessary for generating a new inclusion relation in a message, and transmits the message to an agent, wherein the agent transmits a message from the manager. Receiving and Message receiving means for decoding the contents of a message and parameters included in a message, and object managing means for managing all managed objects and activating a managed object for generating a new containment relationship in accordance with the contents of the decoded message And a new containment relationship different from the containment tree being constructed using the parameters controlled by the management object that manages the containment tree data and creates a new containment relationship and decrypted by the message receiving means. And a containment tree management means for generating

<Structure 7> In the manager agent system according to claim 7, the object management means of the agent is provided with a management object for generating a new inclusion relation in advance, and the message transmission means of the manager includes Is configured to transmit a message for activating a management object for generating a new inclusion relationship, using the identification name of the instance of the management object and the identification name of the instance of the predetermined management object on the included side as parameters.

<Structure 8> In the manager agent system according to the eighth aspect of the present invention, the manager's message transmitting means includes an identifier of an instance of the management object on the containing side and an object of an instance of the predetermined management object on the containing side. A message for generating a management object for generating a new inclusion relationship is transmitted using the class as a parameter, and the object management means of the agent generates a management object for generating a new inclusion relationship in accordance with the message, and is passed as a parameter. Calculating an inclusion relationship based on the identifier,
It is configured to control the containment tree management means based on the calculated inclusion relationship.

<Structure 9> In the manager agent system according to the ninth aspect of the present invention, the manager's message transmitting means includes an identification name of an instance of the management object on the containing side and identification of an instance of a predetermined management object on the containing side. A message for generating a management object for generating a new inclusion relation is transmitted using the name as a parameter, and the containment tree management means of the agent generates a management object for generating a new inclusion relation in accordance with the message, and The containing tree management means is controlled by the generated managed object, registers the identifiers of the instances of the containing object and the contained object in the constructed containing tree data, and Is configured to add different new containment relationships .

[0018]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the present invention will be described below using specific examples. <Specific Example 1> Specific example 1 includes a conversion table that records conversion rules between a manager-side DN (Distinguished Name) and an agent-side DN in the manager 100, and is optimal for the manager to specify a management object. This makes it possible to easily obtain a proper DN.

In the manager agent system, messages are exchanged between a managing manager and a managed agent on a network to which a plurality of network elements (NEs) are connected.

FIG. 1 is a block diagram showing the configuration of a manager in the network management system according to the first embodiment. The manager 100 includes a manager application 110 and a manager platform 120, and the manager platform 120 includes:
A DN conversion table 121, an alias registration processing unit 122,
The message receiving unit 123 and the message transmitting unit 124 are mounted.

The manager application 110
The DN on the manager application 110 side (hereinafter, referred to as “MDN”) and the DN corresponding to the containment tree actually used on the agent 200 side (hereinafter, referred to as “MDN”).
It is referred to as "ADN". ) Is used as a parameter and the alias registration processing unit 122 is sent to the API (application program
request registration of an alias using the mming interface).

The alias registration processing unit 122 has an API,
In response to a request from the manager application 110, the DN of the manager application (hereinafter referred to as "MDN") and the DN of the agent (hereinafter referred to as "ADN") are registered as aliases in the DN conversion table 121. This is an alias registration processing means for performing a process of setting a conversion rule during the process.

The DN conversion table 121 is an identification name conversion table for recording a conversion rule. FIG.
FIG. 4 is an explanatory diagram illustrating an example of an N conversion table 121. In this figure, the MDN column is a column for recording MDN, the ADN column is a column for recording ADN, and the number column is a column for recording serial numbers. However, the number field is not essential.

The MDN and AD recorded in the same number field
The pair of N becomes the above-described conversion rule. According to the conversion rule, MDN to ADN or ADN to MDN
Can be easily converted to

The alias registration processing unit 122 receives the MDN and the AD in accordance with the request from the manager application 110.
The N pairs are recorded in the DN conversion table 121, and when the recording is completed, the fact is transmitted to the manager application 110.

The message receiving section 123 is a message receiving means for receiving a message from the agent 200. The message transmitting unit 124
0 is a message transmitting means for transmitting a message.

<Operation of Embodiment 1> Next, the operation of Embodiment 1 will be described. The manager application 110 requests the alias registration processing unit 122 to record the conversion rule using the API, and the alias registration processing unit 122 records the conversion rule according to the request. The manager platform 120 communicates with the agent 200 in accordance with the conversion rules recorded in the DN conversion table 121.
Sends and receives P messages.

First, the CMI for the agent 200
The transmission operation of the P message will be described. FIG. 5 is a flowchart showing the operation. Step 1 (in the figure,
The step is described as “S”. ) Is a step executed by the manager application 110, and requests the message transmitting unit 124 to transmit a CMIP message. In step 2, the message transmitting unit 124
Using I, the DN conversion table 121 is searched to find a conversion rule.

In step 3, the message transmitting section 124
Checks whether a predetermined conversion rule is recorded. When the conversion rule is not recorded, it is determined that the conversion from MDN to ADN is unnecessary, and the process proceeds to step 6 as it is. If the conversion rule has been recorded, the process proceeds to step 4.

In step 4, the message transmitting section 124
Is stored in the ADN column according to the conversion rule
To get. In step 5, the message transmitting unit 124
For specifying the destination of the CMIP message
Is converted to ADN according to the conversion rule.

In step 6, the message transmitting section 124
Encodes the CMIP message and sends the CMIP message to agent 200. Step 7
Then, the agent 200 performs processing according to the CMIP message, and sends a response message to the manager 10.
Send to 0.

In step 8, the message receiving unit 123
Receives and decodes the response message from the agent 200, and passes the decoded message to the manager application 110.

Next, when the management object is deleted or when the conversion from MDN to ADN becomes unnecessary, the manager application 110 requests the alias registration processing unit 122 to delete the conversion rule.
At this time, the conversion rule is deleted by the alias registration processing unit 122. As parameters when the manager application 110 instructs the alias registration processing unit 122 to perform processing, a parameter for specifying an instance name stored in the MDN column and an instance name stored in the ADN column are specified. Parameters to be used.

Also, as shown below, the agent 2
It is also possible to automatically delete the relevant conversion rule from the DN conversion table 121 in conjunction with the CMIP management object deletion notification from 00.

FIG. 6 is a flowchart showing the operation of automatically deleting a conversion rule. Step 11 is a step executed by the agent 200, and transmits a notification of deletion of the managed object to the manager 100. In the message, AD for the management object to be deleted
N is included. Upon receiving this notification, the message receiving unit 123 executes steps 12 to 16.

In step 12, the management object deletion notification from the agent 200 is decoded. In step 13, a conversion rule is searched from the DN conversion table 121 based on the ADN of the management object to be deleted. When a conversion rule is found, the process proceeds from step 14 to step 15.

In step 15, the extracted conversion rule is deleted from the DN conversion table 121. After the deletion, the process returns to step 13 and executes step 13 in the same manner. If there is no conversion rule in step 14, the process proceeds to step 16. In step 16, a notification that the managed object has been deleted is passed to the manager application 110.

<Effects of Specific Example 1> As described above, according to Specific Example 1, the conversion of the managed object is performed using the conversion rule, so that the manager application 110 can easily convert the management object to the MDN. An ADN can be obtained based on the ADN. Therefore, the manager application 110 can use the optimum instance name that specifies the management object, and the need to repeat the acquisition of the relation attribute is reduced, and efficient processing is possible. Also, when developing the manager application 110, the complicated sequence of following the relation attributes is eliminated, which leads to improvement in development efficiency, reduction of bugs, and the like.

In the first embodiment, the message receiving unit 123 directly deletes the conversion rule in the DN conversion table 121 upon receiving the management object deletion notification. The rule may be deleted.

<Specific Example 2> Specific example 2 is an invoke ID.
When the instance name in the response message is already converted to ADN at the time of request, the instance name in the response message is converted back to MDN.

FIG. 7 shows the DN conversion table 12 of the second embodiment.
FIG. 3 is an explanatory diagram showing an example of the first example. The DN conversion table 121 of the specific example 2 is provided with an invoke ID column for storing an invoke ID in addition to the columns in the figure.

FIG. 8 is an explanatory diagram showing an example of an invoke ID. The invoke ID column is a variable-length link list as shown in FIG. 8, and can store a plurality of invoke IDs. Specific example 1
The same elements as those described above are denoted by the same reference numerals and description thereof is omitted.

<Operation of Embodiment 2> FIGS. 9 and 10 are flowcharts showing the transmission operation of the CMIP message of Embodiment 2.

In steps 21 to 25, the manager application 110 sends the message to the message transmitting unit 124 in the same manner as in steps 1 to 5 of the first embodiment.
Requests transmission of an MIP message, and sends a message
24 searches the DN conversion table 121 according to this request, and when a conversion rule is found,
And replaces MDN with ADN.

In step 26, the invoke ID is recorded in the invoke ID column of the conversion rule in the DN conversion table 121. The reason for recording the invoke ID is as follows. In the first specific example, the message transmitting unit 124 converts the MDN to the ADN of the conversion rule by referring to the DN conversion table 121 when transmitting the message.
When receiving a message, the message receiving unit 123
Is not converted to MDN. Therefore, the manager application 110 may receive a response having a DN different from the designated DN when requesting the manager platform 120 to transmit the CMIP message. This is often the manager
This is not a problem because the application 110 does not need to refer to the DN of the response. Rather, ADN is replaced by MDN
In order to convert to, the combination of a request and a response based on the invoke ID of the CMIP must be managed, which causes a problem that processing becomes heavy.

However, in some cases, it is desirable that the DN specified at the time of the CMIP message transmission request coincides with the DN included in the response message. Therefore, in the specific example 2, when the DN in the response message is converted from MDN to ADN at the time of request, the DN in the response message is converted back to MDN.

In steps 27 and 28, as in the first embodiment, the CMIP message is encoded and transmitted to the agent 200.
Performs a process according to the CMIP message and transmits a response message to the manager 100.

In step 29, the message receiving unit 12
3 receives the response message from the agent 200 and decodes the message. In step 30, the message receiving unit 123 assigns the same invoke ID to the invoke ID in the CMIP response message.
The conversion rule stored in the column is searched from the DN conversion table 121.

In step 31, the message receiving unit 12
3 checks for the presence or absence of a conversion rule, and if no recorded conversion rule is found, the process proceeds to step 34, and if a recorded conversion rule is found, the process proceeds to step 32.
In step 32, the message receiving unit 123 obtains the MDN from the manager application side DN column of the conversion rule obtained as a result of the search, and calls the conversion rule invoke ID.
Delete the invoke ID from the column.

In step 33, the message receiving unit 12
3 obtains the ADN in the response message in step 32
Replace with DN. In step 34, when the message receiving unit 123 finds or does not find the recorded conversion rule, it passes a response message to that effect to the manager application 110.

<Effect of Specific Example 2> According to the specific example 2 as described above, the invoke I of the CMIP message is performed.
D is used to handle message requests and responses, so that the manager application 1
If 10 uses an alias, the response can also be converted to an alias and returned. Therefore, the present invention can be applied to the manager application 110 that checks the DN of the response.

In the second embodiment, an example in which the present invention is applied to a network management system has been described. However, the present invention is also applicable to a system using a CMIP protocol in which a containment tree of a network structure is effective.

<Specific Example 3> In CMIP, which is a communication protocol between a manager and an agent in network management defined by OSI, only one upper management object on the inclusion relation can be specified when generating a management object. It is. Therefore, the containment tree necessarily has a tree structure, but in the specific example 3, the inclusion relation generation ACTION
Is used to extend the tree structure to a network structure.

FIG. 11 is a block diagram showing the configuration of the agent 200 in the network management system of the third embodiment. The agent 200 includes a message reception unit 210, a message distribution unit 220, and an MO management unit 23.
0, the containment tree management unit 240, and the message transmission unit 250
And is provided.

The message receiving unit 210 is a manager 1
00, and decodes parameters and the like included in the message, and
Is a message receiving means for passing a message to.

The message distribution unit 220 is a block that receives a message from the message reception unit 210 and distributes the received message to each block according to decoded parameters.

The message transmitting section 250 is a block for transmitting a response message to the manager 100 which has transmitted the message. The MO management unit 230 is an object management unit that manages the management objects MO-a to MO-e and the management object MO-m.

Here, the management objects MO-a to MO-e
Is an object used for the purpose of managing the network, and the management object MO-m is a management object for managing the inclusion tree for controlling the inclusion tree management unit 240 and editing the inclusion relationship.

The managed objects MO-a to MO-e and the managed object MO-m operate on, for example, a thread, and
The O management unit manages these managed objects by managing the state of the thread and switching the execution right.

The containing tree management unit 240 is a containing tree managing means for managing the containing tree. FIG.
FIG. 4 is an explanatory diagram showing an example of containment tree data managed by. In FIG. 12, a node ND-a is a managed object M
This is a node for Oa reference, and is located at the vertex of the containing tree. The nodes ND-b to e are nodes for referencing the managed objects MO-b to e, respectively.

The nodes ND-b and ND-c are connected by links LNK-1 and LNK-2, and the managed objects MO-b and MO-c are
Oa is included.

Similarly, the node ND-d and the node ND-
e is connected to the node ND-b by the links LNK-3 and LNK-4, whereby the managed object M
Od and MO-e are included in the managed object MO-b.

The management object MO-m is also represented as a node ND-m in the containment tree data, and the link LNK-m
5 is connected to the node ND-a. Note that the same reference numerals are given to the same elements as those in the first and second examples, and the description will be omitted.

<Operation of Specific Example 3> In specific example 3, the management object MO-m and its nodes ND-m,
As for the link LNK-5 connecting Dm and the node ND-a, the CM 100
It is generated by an IP message, or when the management object MO-a is generated, the
It is automatically generated by the management unit 230.

Then, in the specific example 3, the inclusion relation is newly generated so that a plurality of upper management objects on the inclusion relation can be set without changing the CMIP message. Here, as an example, a link LNK is provided between the managed objects MO-a and MO-e as shown by a broken line in FIG.
A process of directly connecting using -6 and generating a new inclusion relationship will be described.

When generating such a new containment relation, the manager 100 specifies the management object MO-m for managing the containment tree and sends an M-ACTION message for activating the containment relation generation ACTION to the agent 200. Send to The M-ACTION message is for causing the managed object to perform some operation such as reset, self-test, and the like. The M-ACTION message includes, as parameters, the DN of the managed object MO-e as a contained object (lower in the inclusion relationship). , The DN of the managed object MO-a as a managing object on the containing side (upper in the containing relationship) and the managed object M for managing the containing tree
O-m DN is included.

FIG. 13 shows an example of the management object MO-
14 shows an example of the DN of e, FIG. 14 shows a DN used to specify a higher-level managed object MO-a, and FIG. 15 is an explanatory diagram showing a DN used to specify a managed object MO-m. is there.

FIG. 16 is a flowchart showing the operation for generating the inclusion relation in the third embodiment. In step 41,
The message receiving unit 210 of the agent 200 generates the inclusion relation ACTION for the managed object MO-m.
After receiving the activation request message and decoding parameters and the like, the message is passed to the message distribution unit 220.

In step 42, the message distribution unit 22
0 passes the DN of the management object MO-m included in the message to the containment tree management unit 240, and
It requests the inclusion tree management unit 240 to identify O-m.

In step 43, the inclusion tree management unit 240 searches the inclusion tree data based on the DN of the management object MO-m received from the message distribution unit 220, obtains a reference to the management object MO-m, and The reference information is returned to the message distribution unit 220.

At step 44, the message distribution unit 22
0 activates the inclusion relation generation ACTION of the managed object MO-m based on the reference to the managed object MO-m. In step 45, the activated inclusion relation generation AC
TION is the containing managed object MO-a passed as a parameter and the contained managed object M
It requests the inclusion tree management unit 240 to newly generate an inclusion relationship with Oe.

In step 46, the containment tree management unit 240 sets the node ND-a representing the management object MO-a of the containment tree data and the node N representing the management object MO-e.
De-e is connected by link LNK-6 to generate an inclusion relationship.

In step 47, the containment tree management unit 240 sends a response indicating that the generation of the link LNK-6 has been completed to the
Return to TION. In step 48, the inclusion relation generation AC
The TION passes a response message indicating that the creation of the inclusion relation has been completed to the message transmitting unit 250.

In step 49, the message transmitting section 25
0 encodes a response message indicating completion of generation of the inclusion relation and transmits it to the manager 100. This completes the operation for newly generating the inclusion relation.

Next, the operation of specifying the management object MO-e using the link LNK-6 generated by the manager 100 will be described. Managed object MO-e
Is specified, the manager 100 sends an M-GET request message to the agent 200 to the managed object MO-e to acquire the value of the DN of the managed object MO-e. This M-GET request message is for obtaining the DN of the target managed object.

FIG. 17 is an explanatory diagram showing an example of the DN used at this time. This DN has a management object M
Oa and the naming DN of the management object MO-e are included.

FIG. 18 is a flowchart showing the operation of specifying the management object MO-e. Step 51
Then, the message receiving unit 210 sets the management object MO
After receiving the M-GET request message for -e and decoding parameters and the like, the message is passed to the message distribution unit 220.

In step 52, the message distribution unit 22
0 is included in the message.
e, and passes the DN of e to the containment tree management unit 240, and requests the inclusion tree management unit 240 to specify the management object MO-e.

In step 53, the inclusion tree management unit 240 searches the inclusion tree data based on the DN of the management object MO-e received from the message distribution unit 220, and follows the link LNK-6 to thereby search the node ND-e. From the management object MO-e. afterwards,
The reference information is returned to the message distribution unit 220.

In step 54, the message distribution unit 22
0 is the M-GET for the managed object MO-e based on the reference to the specified managed object MO-e.
Perform message processing. In step 55, the message transmitting unit 250 encodes the response message of the completion of the M-GET processing, and transmits this response message to the manager 100. This ends the operation of specifying the management object MO-e.

<Effects of Specific Example 3> As described above, according to Specific Example 3, the manager 100 determines whether the containment tree management M
Since the lower-level management object can set a plurality of higher-level management objects using the inclusion relation generation ACTION of O, the containment tree can be extended from a tree structure to a network structure. Therefore, the manager 100
The management object can be designated by using the most suitable DN from the viewpoint of network management, so that the man-hour for developing the manager software and the number of strokes required for the operation of the operator can be reduced.

In the third embodiment, the operation for generating two inclusion relations has been described as an example. However, the number of DNs and inclusion relations (links) passed as parameters is not limited to one.

Also, a request for generation of an inclusion relation at the time of generation of a management object is made from the management object MO-e to the inclusion tree management unit 240. However, the message distribution unit 220 or the MO management unit 230 sends a request for the inclusion tree management unit 240. May be performed.

Further, the number of management objects and links and the containing tree are not limited to the specific example 3. The same applies to the following specific examples.

<Specific Example 4> In specific example 4, when a management object is generated, a necessary inclusion relation is calculated without changing a CMIP message, and a plurality of inclusion relations are automatically generated. Things.

FIG. 19 is a block diagram showing the configuration of the agent 200 in the network management system according to the fourth embodiment. In the specific example 4, the management object MO-m for the inclusion tree management of the specific example 3 is not set.

FIG. 20 is an explanatory diagram showing an example of the containing tree of the fourth embodiment. In the specific example 4, since there is no management object MO-m for managing the inclusion tree, there is no node ND-m and no link LNK-5. In addition, the same reference numerals are given to the same elements as those of the first to third examples, and the description is omitted.

<Operation of Specific Example 4> Incidentally, in the specific example 4, as in the specific example 3, a process for generating the link LNK-6 will be described as an example.

The manager 100 is the agent 200
Making a request to generate a management object MO-e
Send a CREATE message; This M-creat
The E message is a message used to cause the other CMIS service user to generate a new managed object, and includes, as parameters, the DN of the managed object MO-b as the included managed object, and the included managed object. As a managed object MO-e
And the object class of the management object MO-e to be generated.

FIG. 21 is a flowchart showing the operation for generating the inclusion relation in the fourth embodiment. In step 61, the message receiving unit 210 of the agent 200 receives the M-CREATE message from the manager 100,
After decoding the parameters and the like, the message is passed to the message distribution unit 220.

In step 62, the message distribution unit 22
0 determines what processing is to be performed based on the contents of the message, the management object that has already been generated, and the inclusion relationship (such as a link).
-E request generation.

In step 63, the MO management unit 230 generates a management object MO-e in response to a request from the message distribution unit 220. In step 64, the generated managed object MO-e derives an inclusion relationship based on the DN passed as a parameter in the initialization process. As a result, the derived inclusion relation is linked to the link LNK.
-4 is requested to the inclusion tree management unit 240.

In step 65, the containment tree management unit 240 generates the inclusion relation requested from the management object MO-e using the link LNK-4. In step 66,
Based on the DN to which the managed object MO-e is passed as a parameter and the object class of the managed object MO-e, an inclusion relationship different from the inclusion relationship derived in step 64 is derived.

In step 67, the management object MO
-E generates the inclusion relation derived in step 66 using the link LNK-6.
Request 0. In step 68, the containment tree management unit 240
Generates the required inclusion relationship from the managed object MO-e.

In step 69, after the initialization of the managed object MO-e is completed, the MO managing unit 230 notifies the message transmitting unit 250 that the generation of the managed object MO-e has been completed. In step 70, the message transmitting unit 250 encodes a response message to the M-CREATE message for which the request for generating the managed object MO-e has been made, and transmits the encoded message to the manager 100.

When the M-GET request message for acquiring the DN of the managed object MO-e is sent from the manager 100 to the agent 200 in the containment tree generated in this way, a specific example 3 shown in FIG.
The management object MO-e is designated by the same operation as.

<Effects of Specific Example 4> As described above, according to Specific Example 4, a plurality of inclusion relations are automatically generated when a management object is generated, so that the man-hour for developing manager software is further reduced. Can be
The number of strokes required for the operation of the operator can be reduced.

<Fifth Embodiment> In the fifth embodiment, a plurality of inclusion relations are designated when a management object is generated by changing a message when a CMIP management object is generated. In addition, the same reference numerals are given to the same elements as those in the specific examples 1 to 4, and the description is omitted.

<Operation of Specific Example 5> When generating the inclusion relation, the manager 100 of the specific example 5 transmits a generation request message M-CREATE to the agent 200.
Note that also in the specific example 5, the inclusion tree in FIG. 20 will be described as an example.

In the CMIP standard, only one DN is specified in the generation request message. In the specific example 5, the format of the message is changed so that a plurality of DNs can be specified.

As the parameters of the message, the DN of the management object MO-a on the containing side as shown in FIG. 13 and the DN of the management object MO-e on the containing side as shown in FIG. 15 are used.

FIG. 22 is a flowchart showing the operation of generating a containment tree according to the fifth embodiment. In step 71, the message receiving unit 210 of the agent 200 receives the generation request message of the managed object MO-e, decodes the parameters and the like, and then transfers the message to the message distribution unit 2.
Pass to 20.

In step 72, the message distribution unit 22
0 sets the generation of the management object MO-e to the MO management unit 23
Request 0. In step 73, the MO management unit 230 generates a management object MO-e. In step 74, the MO management unit 230 generates the management object M
The reference to O-e is stored in the D specified by the manager 100.
In accordance with N, a request is made to the containing tree management unit 240 to record it in the containing tree data.

In step 75, the containing tree management unit 240 that has received the request stores the management object MO in the containing tree data.
Generate a node ND-4 representing -e. Step 76-
The processing up to 78 is performed for each D of the management object MO-e.
N, that is, for DN as shown in FIGS.

In step 77, the containment tree management unit 240 sets the link LNK according to the DN of the management object MO-e.
An inclusive relation is generated using -4 and 6. In step 79, the inclusion tree management unit 240 notifies the completion of the recording of the management object MO-e to the inclusion tree data by the MO management unit 2
Notify 30.

In step 80, the MO management section 230 passes a generation completion message of the management object MO-e to the message transmission section 250. In step 81, the message transmitting unit 250 encodes the generation completion message of the managed object MO-e and transmits it to the manager 100. In the containment tree generated in this way, an M-GET request message for acquiring the DN of the managed object MO-e from the manager 100 is transmitted to the agent 2.
When transmitted to 00, the operation is performed in the same manner as in the specific example 3, and the management object MO-e is designated.

<Effects of Specific Example 5> As described above, according to Specific Example 5, a plurality of inclusion relations can be generated when a managed object is generated by changing a message when a CMIP managed object is generated. it can.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a configuration of a manager in a network management system of a specific example 1.

FIG. 2 is an explanatory diagram illustrating an example of a containment tree.

FIG. 3 is an explanatory diagram showing an example of a DN in the inclusion relationship of FIG. 2;

FIG. 4 is an explanatory diagram illustrating an example of a DN conversion table according to a specific example 1.

FIG. 5 is a flowchart illustrating a transmission operation of a CMIP message according to the first embodiment.

FIG. 6 is a flowchart illustrating an operation of automatically deleting a conversion rule according to the first embodiment.

FIG. 7 is an explanatory diagram illustrating an example of a DN conversion table according to a specific example 2.

FIG. 8 is an explanatory diagram showing an example of an invoke ID of a specific example 2.

FIG. 9 is a flowchart (part 1) illustrating an operation of transmitting a CMIP message according to the second embodiment.

FIG. 10 is a flowchart (part 2) illustrating a transmission operation of a CMIP message according to the second embodiment.

FIG. 11 is a block diagram illustrating a configuration of an agent in the network management system according to the third embodiment.

FIG. 12 is an explanatory diagram illustrating an example of a containment tree according to specific example 3.

FIG. 13 is an explanatory diagram showing an example of a DN of specific example 3.

FIG. 14 is an explanatory diagram illustrating an example of a DN of specific example 3.

FIG. 15 is an explanatory diagram showing an example of a DN of specific example 3.

FIG. 16 is a flowchart illustrating an operation of generating an inclusion relation in specific example 3.

FIG. 17 is an explanatory diagram showing an example of a DN of specific example 3.

FIG. 18 is a flowchart illustrating an operation of specifying a management object (MO) according to the third embodiment.

FIG. 19 is a block diagram illustrating a configuration of an agent in the network management system according to the fourth embodiment.

FIG. 20 is an explanatory diagram illustrating an example of a containment tree according to specific example 4.

FIG. 21 is a flowchart illustrating an operation of generating an inclusion relation in specific example 4.

FIG. 22 is a flowchart illustrating an operation of generating an inclusion relation in specific example 5;

[Explanation of symbols]

 REFERENCE SIGNS LIST 100 manager 121 DN conversion table 122 alias registration processing unit 123 message reception unit 124 message transmission unit 200 agent 210 message reception unit 230 MO management unit 240 inclusion tree management unit

 ────────────────────────────────────────────────── ─── Continuation of front page (72) Inventor Yosuke Terakura 1-7-12 Toranomon, Minato-ku, Tokyo Oki Electric Industry Co., Ltd. F-term (reference) 5B045 GG01 5B089 GB08 HB14 JA35 JB22 KA10 KB06 KB10 KC15 KC44 KC51 KH03

Claims (9)

[Claims] 1. A containment tree which forms a relationship between a manager as a system to be managed and an agent as a managed system on a computer, and shows a relationship between each instance of a plurality of managed objects to be managed in the agent. In the manager agent system in which is constructed, conversion between a manager-side identifier for specifying a management object having a containment tree relationship from the manager and an agent-side identifier corresponding to the containment tree used on the agent side. A manager agent system comprising: an identification name conversion table for recording a rule; and alias registration processing means for registering a conversion rule in the identification name conversion table. 2. The manager searches a distinguished name conversion table, and when a corresponding conversion rule is registered, converts the manager-side distinguished name into an agent-side distinguished name according to the corresponding conversion rule, and converts the converted agent-side distinguished name. 2. The manager agent system according to claim 1, further comprising a message transmitting unit that transmits the message including the identification name in the message. 3. The manager, upon receiving a message including an agent-side identifier from an agent,
2. A message receiving means for retrieving an identifier conversion table and, when a corresponding conversion rule is registered, converting the agent-side identifier into a manager-side identifier according to the corresponding conversion rule. The manager agent system according to claim 2. 4. The message transmitting unit is configured to register an invoke identifier when performing conversion of an identifier in a message according to a conversion rule registered in an identifier conversion table. Upon receiving the response message, the apparatus is configured to search the identifier conversion table based on the invoke identifier included in the response message, specify a conversion rule, and perform reverse conversion of the identifier. The manager agent system according to claim 3. 5. The method according to claim 1, wherein the message receiving unit is configured to, when receiving a message to delete the management object from the agent, delete the conversion rule including the identification name of the management object from the conversion table. The manager agent system according to claim 3 or 4, wherein 6. A containment tree which forms a relationship between a manager as a system to be managed and an agent as a managed system on a computer, and shows a relationship between each instance of a plurality of managed objects to be managed in the agent. Is a system that generates a new containment relationship so that an instance of a predetermined managed object can be specified by a containment relationship different from the built containment tree. Message transmitting means for transmitting the message to an agent by including a parameter necessary for generating a relationship in the message, wherein the agent receives the message from the manager and is included in the content and the message of the message Decrypt parameters A message receiving means for managing all the managed objects, and an object managing means for activating a managed object for generating a new containment relationship in accordance with the content of the decrypted message; and A containment tree management means for generating a new containment relation different from the constructed containment tree by using a parameter controlled by a management object for creating a new containment relation and decrypted by the message receiving means. A manager agent system characterized by the following. 7. The object management means of the agent is provided with a management object for generating a new containment relationship in advance, and the message transmission means of the manager is provided with an identifier of an instance of the management object on the containing side and a predetermined name on the containing side. 7. The manager agent system according to claim 6, wherein a message for activating a management object for generating a new containment relationship is transmitted using the identifier of the instance of the management object as a parameter. 8. The management object for generating a new containment relationship using the identifier of the instance of the management object on the containing side and the object class of the instance of the predetermined management object on the containing side as parameters. The object management means of the agent generates a management object for generating a new inclusion relation according to the message, calculates the inclusion relation based on the identification name passed as a parameter, and calculates The manager agent system according to claim 6, wherein the manager agent system is configured to control the containment tree management means based on the obtained inclusion relationship. 9. The management object for generating a new containment relationship, using the identifier of the instance of the management object on the containing side and the identifier of the instance of the predetermined management object on the included side as parameters. Is transmitted, the containment tree management means of the agent generates a management object for generating a new inclusion relationship according to the message, and the containment tree management means of the agent controls the generated management object. Then, the identifiers of the instances of the management objects on the containing side and the included side are registered in the constructed containment tree data, and a new containment relationship different from the constructed containment tree is added. 7. The manager agent system according to claim 6, wherein: