Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring
Reexamination Certificate
1998-05-28
2001-03-06
Dinh, Dung C. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network monitoring
C709S202000
Reexamination Certificate
active
06199109
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to event handling in a network management system, and more specifically to the event notification process.
BACKGROUND OF THE INVENTION
One way that computer networks manage their resources is by using Open Systems Interconnection (“OSI”) standards. OSI management uses managed objects to represent resources.
FIG. 1
illustrates a conventional system in a computer network operating in an OSI environment. This system
100
includes a “manager”
110
(an application acting in the manager role) and an “agent”
120
(an application acting in the agent role). The agent
120
contains one or more managed objects (
130
1
-
130
t
) (“MO”) made visible to the manager
110
via the Common Management Information Protocol (“CMIP”), a discrimination component
140
, and Event Forwarding Discriminators (
150
1
-
150
p
) (“EFD”) managed by the discrimination component
140
. An agent
120
may contain a proxy agent coordinator (“PAC”)
160
which provides the appearance of agents, or “proxy agents” (
170
1
-
170
m
) for one or more devices (
180
1
-
180
m
represented by managed objects (
190
1
-
190
m
) using other existing protocols, such as the Simple Network Management Protocol (“SNMP”). The MOs (
190
1
-
190
m
) made visible by proxy agents (
170
1
-
170
m
) are outwardly indistinguishable from MOs (
130
1
-
130
t
) on a non-proxy agent
120
. Rather than interacting directly with a device, MOs (
190
1
-
190
m
) on a proxy agent (
170
1
-
170
m
) interact with a device via the management protocol supported by that device. Typically a manager will work with more than one agent.
All MOs have unique identifiers called Distinguished Names (“DN”). The DN's are organized in a tree-like or hierarchical structure. Each child MO is identified within the scope of its containing parent MO by an attribute of that child MO. An attribute consists of an attribute type and an attribute value. Using a directory mechanism, a manager
110
can determine to which agent a message should be sent to interact with a particular MO.
There are two types of messages that are sent between a manager
110
and an agent
120
. The manager
110
can send request messages to MOs (
130
1
-
130
t
) at agent
120
and receive response messages. The manager
110
can also receive unsolicited messages from agent
120
. A MO (for example
130
1
) can emit a notification to indicate that some event has occurred concerning the resource represented by the MO
130
1
. To receive this information, the manager
110
must create one or more EFDs (
150
1
-
150
p
) on the agent
120
containing the MO
130
1
.
FIG. 2A
illustrates the structure of a conventional notification. A notification contains two groups of information. The first group is the “header”
202
which contains information such as the DN of the MO that emitted the notification and the type of event being described in the notification. The second group
204
is the event information.
FIG. 2B
illustrates the structure of a conventional EFD. An EFD is just another type of MO that can reside on an agent. The EFD also contains two groups of information. The first group
206
is the EFD Object Information which includes the DN of the EFD, destination information (a list of managers to which the notifications should be sent), and the state information of the EFD MO. The second group
208
is a filter that determines which notifications should be forwarded. When a notification is forwarded from an agent to a manager, it is sent in a message called an Event Report (“ER”).
FIG. 3
is a flow chart illustrating a conventional method of processing a notification emitted by an MO. When a notification is generated, it is sent to the EFDs, via step
302
. The discrimination component of the agent sends (or forwards) the notification through each EFD on that agent, via step
304
. The values in the filter of the EFD are then compared with the notification event information, via step
306
. If the notification passes the criteria specified by the EFD's filter, via step
308
, then an ER is sent to each of the managers listed in the EFD's destination information, via step
310
.
For example, assume a manager
110
would like to be informed when the status of a resource changes.
FIG. 4
illustrates this example. The manager
110
would create an EFD
150
1
on the agent
120
that contains the MO
130
1
that represents that resource. This EFD's filter would specify that only status changes should be forwarded, and the destination would be the manager
110
itself. When a status change occurs on the resource, the MO
130
1
that represents that resource emits a status change notification
410
. This notification
410
is presented to each of the EFDs (
150
1
-
150
p
) on the agent
120
. Since this notification
410
meets the criteria in the filter of one EFD
150
1
on this agent
120
, an ER
420
is sent to the manager
110
. The ER
420
contains the DN of the MO
130
1
that emitted the notification
410
, so that the manager
110
knows which resource had a status change. A manager
110
typically manages more than one agent, so it would create similar EFDs that differ only in the DNs on each of the agents that it manages.
Although the above conventional process is adequate for MOs that interact directly with their associated resources, problems exist when the notification is generated by a proxy MO that is interacting with its resource via some other management protocol.
FIG. 4B
illustrates this problem. The problem arises because the PAC
160
can support more than one proxy agent (
430
1
-
430
n
). An agent
440
that has a PAC
160
contains sets of EFDs (
450
1
-
450
n
) that would each normally be on different agents. But since a notification must be sent to all of the EFDs (
450
1
-
450
n
) on an agent
120
, and since all of the EFDs that are created by the manager
110
on proxy agents (
430
1
-
430
n
) are nearly identical, a notification emitted by a proxy MO, such as
460
, on a proxy agent
430
1
will be processed and forwarded not only by the set of EFD
450
1
on proxy agent
430
1
, but also by all other sets of EFDs (
450
2
-
450
n
) on other proxy agents (
430
1
-
430
n
). The result is redundant processing, since each EFD on the proxy agents (
160
-
1
through
160
-r) must perform the same evaluation on the notification and the results will be the same, causing extra network traffic. Thus many ERs will be sent rather than just one which could possibly cause confusion for the managers, especially if the notification indicates that a resource has been created.
The ISO-Internet Migration/Coexistence (IIMC) group has developed one approach to the above problem by requiring that EFDs on a proxy agent be contained under a special managed object on that proxy agent. The discrimination component is enhanced so that notifications emitted by an MO on a proxy agent are sent only to the EFDs contained under the special managed object. Although this avoids the problem above, it introduces a new problem. This approach requires that the managers create their EFD's under the correct special managed object, i.e., the managers must know ahead of time which devices are supported by proxy agents and which are supported by non-proxy agents and handle the creation of the EFDs accordingly. This defeats the purpose of the proxy which is to hide differences from managers. This approach requires the existing manager applications to be at least partially rewritten and complicates the development of new managers. Thus, this approach is inflexible and cumbersome in its implementation.
Therefore, there exists a need for an event notification method and system which has the ability to distinguish between sets of EFDs on different proxy agents while maintaining the ability to hide the difference between proxy agents and non-proxy agents from managers. This system should be easy to implement and should not require changes to the programming of existing managers nor require new managers to be sensitive to the dif
Reder Paul Joseph
Zelek Mark Clarence
Dinh Dung C.
International Business Machines - Corporation
Sawyer, Jr. Joseph A.
Trim Nkosi
Woods Gerald R.
LandOfFree
Transparent proxying of event forwarding discriminators does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Transparent proxying of event forwarding discriminators, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transparent proxying of event forwarding discriminators will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2505767