Electrical computers and digital processing systems: multicomput – Multicomputer synchronizing
Reexamination Certificate
1998-08-26
2001-05-08
Lim, Krisna (Department: 2153)
Electrical computers and digital processing systems: multicomput
Multicomputer synchronizing
C709S202000, C714S707000
Reexamination Certificate
active
06230210
ABSTRACT:
FIELD OF THE INVENTION
The invention pertains to network communication systems. More particularly, the invention pertains to a method and apparatus for re-synchronizing a network manager to its agents.
BACKGROUND OF THE INVENTION
Communications networks with a significant number of communication nodes typically employ a manager/agent scheme to control communications between the network communication nodes. In such schemes, the communication nodes are termed “agents”, while the nodes which manage communications on the network are termed “managers”.
FIG. 1
illustrates one common type of communications network
10
and control scheme therefor, including a plurality of managers
4
which each manage a plurality of agents
6
. The plurality of managers
4
may be connected to each other in any one of a number of configurations, including tree (as shown) and star configurations. The various managers
4
may communicate with each other through a higher level node, termed a network manager
2
N (as illustrated), which communicates with all of the managers and the overall network. In other schemes, the managers
4
may communicate directly with each other (not shown). Each node
2
,
4
,
6
on the network typically will include some type of data processing unit,
2
a,
4
a,
and
6
a
and memory. As an exemplary illustration in
FIG. 1
, each node
2
,
4
,
6
has both ROM
2
b,
4
b
and
6
b
as well as RAM
2
c,
4
c
and
6
c.
Each node also should include a separate database memory,
2
d,
4
d,
and
6
d,
for at least network operational data.
In an object-oriented management scheme, each agent
6
maintains a Management Information dataBase (MIB) in database memories
6
d
that contains the condition of all of the attributes (commonly termed object instances) of all of the objects of that agent. The managers
4
usually also maintain in database memories
4
d
a putative copy of the MIB of each agent under its management control. The copy stored at the manager is deemed putative since it may not be identical to the data stored at the agent. The agent's MIB data is assumed to be the most correct copy of the MIB.
As long as the copy of the MIB for an agent stored at the manager is identical to the MIB stored by the agent, the manager and the agent are synchronized. However, various events can occur which would cause the manager to either lose synchronization with one or more of its agents or, at least, not know whether it is synchronized to one or more of its agents. For instance, the manager may simply become disabled for a period of time during which object instances of its agents may be changed, added or deleted. Also, it is possible for a communication link (or association) between a manager and an agent to go down for a period of time. In either event, the manager, when it re-establishes an association with the agent, will not know if its putative copy of the agent's object instances is current, and will need to confirm and/or update its database in accordance with any changes that occurred during the period of non-communication with the agent.
In one prior art resynchronization scheme, each agent maintains an event log in which each and every creation, deletion or change in state of an object instance is recorded. Whenever an event occurs, it is stored in the event log. Also, an M event report is sent from the agent to the manager informing it of the event. There usually is no confirmation of M event reports by the manager. The manager will update its relevant copy of the object instances for the agent accordingly. However, if the communication association between the manager and the agent is down, the manager will not receive the Event Report and, therefore, will no longer be synchronized with the agent.
The object instances in the event log are tagged with, for instance, a time-stamp. The event log is maintained in a circular buffer. After communication between a manager and an agent is re-established, the manager can check the event log and read out every entry in the event log having a tag indicating that the event occurred after the time that the association was lost. This type of resynchronization scheme can be extremely time consuming if the number of events which occurred during the loss of association is significant. In fact, the loss of an association between a manager and an agent is frequently caused by, or at least associated with, a problem in the system that will lead to a significant number of other network events, including changes in the object instances of the agents. Accordingly, a significant number of changes in object instances of the agents frequently occurs precisely when a communication association is lost between a manager and an agent. As an example, the MIB in present network systems typically may have between 500 and 10,000 object instances per agent. Smaller object instances may have on the order of 200 to 400 bytes each. However, larger ones can have 5,000 to 8,000 bytes of information. Future network systems are projected to have substantially increased numbers and sizes of object instances. Accordingly, resynchronization can be rather time consuming.
If the number of events occurring during a loss of association between a manager and an agent exceeds the length of the log, the log can no longer be used for resynchronization, since the earliest events are lost. In such a case, resynchronization can be achieved only by reading the entire MIB database out of the agent into the manager.
Accordingly, it is an object of the present invention to provide an improved resynchronization scheme for a network.
It is another object of the present invention to provide a resynchronization scheme for a network in which the amount of data which must be exchanged to achieve resynchronization is substantially reduced.
SUMMARY OF THE INVENTION
In the present invention, each object instance stored in the MIB of an agent contains two additional attributes, termed “UNIQUEID” and “DATASYNCH”. UNIQUEID is a unique number assigned to each object instance when it is created. Preferably, the UNIQUEID attribute is of sufficient bit length to assure that, in any practical situation, there are more unique ID's available than possible object instances for the agent.
DATASYNCH is a number assigned to each object instance upon creation. Typically, the number assigned upon creation will be 0 or 1. Each time that object instance is updated, DATASYNCH is incremented by 1. As with UNIQUEID, the bit length of the DATASYNCH attribute preferably is enough to handle any practical number of changes that might occur to an object instance during a loss of association.
When resynchronization is necessary, the manager will poll the agent requesting a copy of the UNIQUEID and DATASYNCH attributes for each object instance in the agent's MIB. While the agent is generating this report and communicating it to the manager, the manager is likewise preparing a similar report of each UNIQUEID and DATASYNCH attribute stored in its database.
The manager then compares the UNIQUEID and DATASYNCH attribute values received from the agent to its putative copy of the UNIQUEID and DATASYNCH values for the object instance for that agent.
For each UNIQUEID which the manager has in its database that does not have a corresponding UNIQUEID at the agent, the manager will delete that object instance from its database. For each object instance detected at the agent for which the manager does not have a corresponding UNIQUEID or that has a DATASYNCH attribute value different from the DATASYNCH attribute value stored at the manager, the manager reads the entire object instance from the agent and updates its corresponding object instance accordingly, including updating the UNIQUEID and DATASYNCH values. No action is taken with respect to object instances for which both the UNIQUEID and DATASYNCH attributes match.
The manager is resynchronized to the fault status of the agent by requesting each active fault status from the agent and updating its database accordingly.
REFERENCES:
patent: 546
Davies Graham John
Pennington P. Nigel
Startup Roy
Lim Krisna
Lucent Technologies - Inc.
Synnestvedt & Lechner LLP
LandOfFree
Method and apparatus for re-synchronizing a network manager... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for re-synchronizing a network manager..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for re-synchronizing a network manager... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2440515