 |
Description  |
|
|
TECHNICAL FIELD OF THE INVENTION
This invention relates in general to network management systems and methods, and more particularly to a configuration synchronization system and method.
BACKGROUND OF THE INVENTION
Communication networks are ubiquitous in our society. The continuing development of new technologies and investment in new infrastructure increases the connectivity and availability of networks that deliver voice, video, and data services to
more customers. This new infrastructure includes a variety of network elements that have become increasingly more complex and more dependent on their interaction with other components in the network. As such, communication service providers must
coordinate the operation of network elements to provision reliable and effective communication services to their customers. Often, this coordination of network elements is performed by a collection of hardware and software known as a network management
system.
Most network management systems include a network manager that manages and coordinates the operation of network elements in a communication network. The network manager allows the service provider to install, monitor, upgrade, and configure
network elements to provide the desired communication services. To accomplish these tasks, the network manager accesses an accurate view or status of provisioned equipment in the field, often in the form of a Management Information Base (MIB). Timely
access to accurate configuration information stored in the MIB is important to manage network elements.
SUMMARY OF THE INVENTION
In accordance with the present invention, a system and method for updating a memory storing configuration information of a network element is provided that substantially eliminates or reduces disadvantages or problems associated with previously
developed network management systems and methods.
In one embodiment of the present invention, a system for updating a memory storing configuration information of a network element includes a network element that stores configuration information. A network manager coupled to the network element
using a communication network stores a portion of the configuration information in memory. The network manager receives a state variable from the network element and compares the received state variable to a stored state variable. The network manager
receives selected configuration information from the network element to update a selected part of the memory if the received state variable does not match the stored state variable.
Technical advantages of the present invention include a system and method that update a memory storing configuration information of a network element using one or more state variables retrieved from the network element. In a particular
embodiment, a network management server maintains configuration information for a managed network element locally and provides access to the configuration information by one or more clients in a client/server environment. The server, clients, and
managed network elements communicate messages (e.g., SNMP messages) over a management network, such as an Ethernet, an Asynchronous Transfer Mode (ATM) network, or any suitable communication network. To improve access to configuration information, the
server maintains one or more caches of selected configuration information readily available to clients, as well as a persistent storage of full configuration information in a database.
Other technical advantages of the present invention include the ability to reconcile configuration information received in a variety of ways to maintain a consistent and accurate view of the managed network element. For example, the server may
receive configuration information in the form of traps autonomously generated by the network element indicating an alarm condition, alarm clear, or module insertion event. The server may also poll the network element for configuration information or
receive updates of the configuration information from a client managing the network element. Also, the server may be notified of changes in the network element configuration made by another network management device or system. The present invention
manages all of this information to achieve a consistent and accurate view of the network element in both a cache of information immediately available to clients and a database.
Another particular advantage of the present invention is the ability to perform a partial update of configuration information maintained by the server by comparing retrieved checksums associated with data subsets of configuration information, and
updating only those data subsets in which the checksums indicate an altered state. The server also includes processes that manage the processing of traps received from the network element. In a particular embodiment, the server identifies missed or
out-of-sequence traps and, if necessary, reissues alarms to maintain the consistency of configuration information stored in the cache and database. Other technical advantages are readily apparent to one skilled in the art from the following figures,
descriptions, and claims.
BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present invention, and for further features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
FIG. 1 illustrates a network management system constructed in accordance with the present invention;
FIG. 2 illustrates in more detail the server in the network management system;
FIGS. 3 and 4 illustrate a flowchart of a method for synchronizing configuration information in the network management system;
FIGS. 5 and 6 illustrate a flowchart of a method for processing traps in the network management system;
FIG. 7 is a flow chart of a method for synchronizing alarms in the network management system; and
FIGS. 8A and 8B illustrate a number of trap processing scenarios of the network management system.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 illustrates a network management system 10 that includes a number of clients 12 and one or more network managers or servers 14 that manage a variety of network elements 16. Generally, system 10 provides a number of network management
services to install, monitor, upgrade, and configure network elements 16 to provision communication services to users. In a particular embodiment, system 10 accomplishes these tasks by maintaining accurate and readily accessible configuration
information associated with network elements 16.
Network elements 16 managed by system 10 may include any variety of communication hardware and/or software to deliver a variety of voice,
video, data, and other communication services to users. Network elements 16 may be portions of the Public Switched Telephone Network (PSTN), private or public data networks, a global communications network such as the Internet, other wireline
or wireless networks, or any other local, regional, or global communication network. To perform its communication services, each network element 16 maintains and continually updates configuration information stored in a Management Information Base
(MIB), database, or other suitable storage facility, generally referred to as MIB 24.
Each network element 16 couples to management network 20 using management links 22. Management network 20 may be a local area network (LAN), a wide area network (WAN), a public or private network, a global data network such as the Internet, a
wireline or wireless network, or any other suitable communication network that provides communication among components in system 10. In a particular embodiment, management network 20 comprises an Ethernet that communicates network messages using, for
example, Simple Network Management Protocol (SNMP), Remote Monitor Protocol (RMON), Transport Control Protocol/Internet Protocol (TCP/IP), or any other suitable messaging protocol.
MIB 24 arranges configuration information in variables, tables, files, or any other suitable arrangement, referred to generally as data subsets. Data subsets in MIB 24 are associated with hardware and/or software of network element 16. For
example, data subsets may be associated with individual cards, racks, modules, or other resident components. Also, data subsets may include software tables or other data structures, such as alarm tables, module tables, and variable configuration tables. Configuration information as used in this description refers to any information maintained in MIB 24 either persistently or for a short period of time, and any communications from network elements 16 using management network 20. In a particular
embodiment, MIB 24 names and arranges data subsets in a manner consistent with the MIB or MIB-II conventions that are well-known in the industry. MIB 24 may also maintain other information specific to network element 16 that is not part of the MIB
conventions.
Server 14 in system 10 communicates with network element 16 using management network 20. Server 14 maintains at least portions of configuration information stored in MIB 24 for each managed network element 16 in a memory, which may include one
or more selected caches 30 (referred to generally as cache 30) and one or more databases 32 (referred to generally as database 32). In a particular embodiment, cache 30 includes selected configuration information of network element 16 that is readily
accessible to clients 12, whereas database 32 includes a complete and persistent copy of configuration information stored in MIB 24. Database 32 supports Standard Query Language (SQL), object-oriented operation, or any other suitable storage and
retrieval scheme to allow components in system 10 to access stored configuration information of network element 16. One important aspect of system 10 is that server 14 maintains cache 30 to allow faster access to configuration information without
performing queries to database 32.
Clients 12, also coupled to management network 20, allow service providers to monitor and manage network elements 16. In a particular embodiment, clients 12 perform management functions by accessing configuration information stored in cache 30
and/or database 32 maintained by server 14. For example, clients 12 may perform queries to cache 30 and/or database 32 to present a user with a current view or status of network element 16. Clients 12 may also provide a graphical user interface (GUI)
that presents graphically the current state of network element 16, and allows users of client 12 to modify or set configuration information in network element 16. In a particular embodiment, client 12 may operate or interface with an application
programming interface (API), such as CORBA, or other suitable external program to deliver network management functions.
In operation, server 14 runs a variety of software processes to communicate with network elements 16 and clients 12, and to maintain an accurate and consistent view of configuration information in both cache 30 and database 32. Configuration
information in network element 16 can change for a variety of reasons. For example, network element 16 may issue messages, notifications, or other communications (generally referred to as traps) to indicate the status change of network element 16. In a
particular embodiment, traps may be classified in the following categories: information, critical, major, minor, and clear. Also, instead of or in addition to classifications based on alarm severity, traps may also be classified based on alarm type or
may include additional information on the specific alarm event. Informational traps may indicate module insertion events, software download status, configuration or synchronization status, or any other informational event or status of network element
16.
Each trap includes an object identifier that associates configuration information in MIB 24 with a module, slot, port or other component designation of network element 16. A trap also includes an event code, a timestamp, and a trap sequence
number (TSN). During operation, network element 16 generates a number of traps indicating installation of new components, errors or alarms, or other condition resulting in the generation of a trap for communication to server 14. Due to congestion or
limitations in network 20, downtime of components in system 10, or other reasons, server 14 may miss the communication of traps or receive traps out of sequence. In these instances server 14 must not only update its memory (e.g., cache 30 and database
32) with any received traps, but also reconcile its memory whenever traps are missed or received out of sequence.
Configuration information stored in MIB 24 may also change due to local or remote modification by other network management devices or systems. For example, a local configurator 34 may represent hardware and/or software that is integral to or
separate from network element 16 that changes configuration information in MIB 24 locally. Also, other components such as an additional server 36 may communicate messages over management network 20 to change configuration information of network element
16. Normally, clients 12 communicate with network elements 16 through server 14, so any modification of configuration information by clients 12 should be captured and properly reflected at the memory maintained by server 14. However, when client 12,
server 14, network element 16, network 20, or other components of system 10 fail or malfunction, consistency may be lost between configuration information in MIB 24 and the memory maintained by server 14.
Whether based on missed or out-of-sequence traps, local or remote modification to MIB 24, or complete or partial failure of components in system 10, there are a variety of scenarios in which server 14 must reconcile information maintained in its
memory (e.g., cache 30 and database 32) to ensure a proper view and status of network elements 16. Traditionally, if there is a loss of consistency between MIB 24 and information stored in cache 30 and database 32, then server 14 initiates a full
database reconciliation or synchronization to download all relevant configuration information stored in MIB 24 from network element 16. However, this operation may be slow and cumbersome, especially with significant traffic demands on a
bandwidth-limited management network 20. This problem is further exacerbated by relatively crude messaging protocols (e.g., SNMP) that provide limited data integrity and lost message recovery mechanisms. Therefore, in one important aspect of the
present invention, server 14 recovers from missed or out-of-sequence traps, as well as other configuration changes, without requiring a full reconciliation of cache 30 and database 32.
FIG. 2 illustrates in more detail modules of network manager or server 14. In a particular embodiment, server 14 comprises a Unix workstation and the modules represent separate processes spawned by the workstation to provide a variety of
functions. In this particular embodiment, server 14 maintains a process monitor 50, an alarm formatter 52, a database module 54, and one or more network monitors 56. In this architecture, portions of cache 30 may be referred to as an alarm formatter
cache (AC) 58 accessible by alarm formatter 52, and portions of cache 30 may be referred to as one or more network monitor caches (NC) 60 accessible by network monitors 56. It should be understood that server 14 may maintain cache 30 in any form or
arrangement of files, tables, or other data structures. Also, server 14 contemplates any number and arrangement of modules to accomplish the various tasks of communicating with clients 12 and network elements 16, and maintaining the consistency of cache
30 and database 32. For example, portions of the tasks performed by process monitor 50, alarm formatter 52, database module 54, and network monitor 56 may be combined or rearranged in generally into a network interface and processor having related
hardware and/or software components.
Process monitor 60 controls the operations of server 14 and may perform global management of a number of servers, such as server 36. Process monitor 50 acts as a conduit for messages passing between modules of server 14 and clients 12 or network
elements 16. Process monitor 50 routes information received from management network 20 to the appropriate module in server 14. Similarly, process monitor 50 routes communications from modules in server 14 to the appropriate clients 12 and network
elements 16.
Alarm formatter 52 receives traps generated by network elements 16. Alarm formatter 52 identifies each trap, notifies any interested clients 12 managing network element 16 that generated the trap, and archives the trap in database 32. Alarm
formatter 52 also maintains AC 58 to provide expedited processing and notification of traps without the need to access database 32. As described below in more detail, alarm formatter 52 includes a missing trap timer 53 and maintains a missing trap list
in AC 58 to recover from a missing or out-of-sequence trap event without requiring a full or partial database reconciliation.
Each network monitor 56 in server 14 communicates with one or more network elements 16. Network monitor 56 maintains selected configuration information of its managed network element 16 in NC 60 and synchronizes MIB 24 with cache 30 and database
32 of server 14. Network monitor 56 can request or poll for selected configuration information from network element 16 to perform its functions. For example, network monitor 56 may poll MIB 24 for certain state variables and checksums to decide whether
to perform a configuration synchronization and, when a partial or full synchronization is indicated, poll for and retrieve contents of MIB 24 to reconcile cache 30 and/or database 32.
Database module 54 facilitates communication between other modules of server 14 and database 32. Specifically, database module 54 receives queries from process monitor 50, alarm formatter 52, or network monitor 56 and responds to those queries
by communicating the desired information from database 32. Also, during the reconciliation or synchronization process, database module 54 receives updated configuration information of network element 16 through alarm formatter 52 and network monitor 56. Database module 54 also allows alarm formatter 52 and network monitor 56 to maintain the internal consistency between configuration information stored in database 32 and components of cache 30 (e.g., AC 58 and NC 60).
In operation, alarm formatter 52 monitors traps generated by network element 16 and processes the traps with special attention to missing or out-of-sequence traps. When appropriate, network monitor 56 polls for configuration information stored
in MIB 24 at network element 16, and communicates set requests or other commands to modify MIB 24. Set requests may be generated locally by server 14 or by client 12 to change configuration information maintained in network element 16. While receiving
autonomously generated configuration information using alarm formatter 52 or through the generation and setting of configuration information using network monitors 56, server 14 invokes configuration and alarm synchronization processes to ensure cache 30
and database 32 are consistent and synchronized with configuration information stored in MIB 24. FIGS. 3 though 7 discuss these processes in more detail.
FIGS. 3 and 4 illustrate a flowchart of a method 100 performed by network monitor 56 for synchronizing the memory of server 14 (e.g., cache 30 and database 32) with MIB 24 of a particular network element 16. Method 100 may be invoked
periodically (e.g., once a day, once a week), by an operator of client 12, or autonomously by network monitor 56 or alarm formatter 52. Method 100 begins at step 102 where network monitor 56 retrieves selected state variables stored in MIB 24 and
represented by a subscript "E". In a particular embodiment, network monitor 56 retrieves a set request number (SRN.sub.E), a trap sequence number (TSN.sub.E), and system up-time (SUT.sub.E) stored in MIB 24. The variable SRN.sub.E represents the number
of set requests or requests to modify information stored in MIB 24. The variable TSN.sub.E represents the trap sequence number of the last trap communicated by network element 16. The variable SUT.sub.E indicates the amount of time that network element
16 has been operational since its last downtime, reboot, or other resetting event.
Although these specific MIB state variables are used in method 100, server 14 may use any appropriate state variable stored in MIB 24 to determine whether to perform a full or partial database reconciliation. In this manner, server 14 can make
an intelligent decision of whether to perform a reconciliation based on the analysis of a few state variables. This provides the advantage of decreasing the traffic on management network 20, while still employing an algorithm that provides an accurate
assessment of the consistency between MIB 24 and the memory of server 14 using selected state variables. In a particular embodiment, one state variable (SRN.sub.E) enables server 14 to detect whether network element 16 has been "managed" or configured
by local configurator 34, server 36, or some other device in system 10. If SRN.sub.E does not reconcile with information stored in database 32, then method 100 performs a full configuration synchronization. Another state variable (TSN.sub.E) enables
server 14 to detect a trap sequence mismatch and, in this case, perform a partial configuration synchronization. In this particular embodiment, server 14 utilizes a first state variable (SRN.sub.E) to trigger a full configuration synchronization and a
second state variable (TSN.sub.E) to trigger a partial configuration synchronization.
Network monitor 56 determines whether TSN.sub.E is less than the trap sequence number stored in NC 60 (TSN.sub.NC) at step 103, which would indicate a trap sequence reset or, more generally, a downtime, system reset, malfunction, or other failure
at network element 16. If TSN.sub.E is less than TSN.sub.NC, network monitor 56 sets a trap sequence update flag (TSU) to true at step 105. Network monitor 56 then compares SRN.sub.E to the set request number maintained in NC 60 (SRN.sub.NC) at step
104. If these variables are not equal, then server 14 performs a full database reconciliation at steps 106 and 108. Network monitor 56 retrieves configuration information from MIB 24 at step 106 and reconciles database 32 at step 108. If SRN.sub.E
equals SRN.sub.NC, SRN.sub.E equals zero, and SUT.sub.E, is less than the system up-time stored in NC 60 (SUT.sub.NC), then server 14 again performs steps 106 and 108 to invoke a full database reconciliation. In a particular embodiment, step 108 to
reconcile database 32 is performed as follows. Server 14 initially marks each configuration entry in database 32 for network element 16 as unclean, and traverses the variables configuration tables in MIB 24 to determine whether the configuration
matches. If the configuration matches, the entry in database 32 is marked as clean. If the configuration differs, the value retrieved from MIB 24 is used to update the entry in database 32, which is then marked clean-updated. If there is no entry in
MIB 24, the entry is left as unclean. When the process is complete, all unclean entries are deleted.
If either SRN.sub.E does not equal zero or SUT.sub.E is greater than or equal to SUT.sub.NC, then network monitor 56 determines whether a forced configuration synchronization flag (FCS) is true at step 112. If FCS is true, then server 14
performs a partial database reconciliation at steps 114-126. To perform a partial database reconciliation, network monitor 56 retrieves checksums of data subsets stored in MIB 24, referred to as CKS.sub.E (1) to CKS.sub.E (N), at step 114. In this
particular embodiment, N represents the number of data subsets maintained by network
element 16 or subject to the configuration synchronization. Network monitor 56 then sets the counting index (I) equal to "1" at step 116. For each data subset, network monitor 56 determines whether CKS.sub.E equals the corresponding checksum
stored in NC 60 (CKS.sub.NC) at step 118. If the checksums do not match, then network monitor 56 retrieves the associated data subset from MIB 24 at step 120 and reconciles database 32 at step 122 using the retrieved data subset. The reconciliation of
a data subset in step 122 may be performed in a similar manner as step 108 described above. Also, the reconciliation by data subsets described in steps 114-126 to perform partial database reconciliation may be similarly implemented and replace the full
equipment database reconciliation of steps 106-108 in method 100. Upon performing the retrieval and reconciliation at steps 120 and 122 or if the checksums are equal, network monitor 56 increments the index at step 124, determines if it has cycled
through each data subset at step 126 and, if not, repeats the checksum comparisons for the next data subset. If FCS is false, and TSN.sub.E does not equal the trap sequence number stored in database 32 (TSN.sub.D), then network monitor 56 also performs
a partial database reconciliation as described in steps 114-126.
After performing a full database reconciliation (steps 106-108), a partial database reconciliation (steps 106-108) or a partial database reconciliation (steps 114-126), method 100 continues with the steps in FIG. 4 to update cache 30 and database
32 with the retrieved state variables. Network monitor 56 determines whether SRN.sub.E equals SRN.sub.NC at step 150. If these variables are not equal, then server 14 sets both SRN.sub.NC and SRN.sub.D to the retrieved equipment value (SRN.sub.E) at
step 152. If the trap sequence update flag (TSU) is true at step 153, then network monitor 56 sets both TSN.sub.NC and TSN.sub.D to TSN.sub.E at step 162, and invokes an alarm synchronization performed by alarm formatter 52, as described in more detail
with reference to FIG. 7.
If TSU is false at step 153, network monitor 56 then retrieves TSN.sub.D from database 32 at step 154 and determines whether TSN.sub.D is greater than TSN.sub.NC at step 156. If TSN.sub.D is greater than TSN.sub.NC, then network monitor 56 sets
TSN.sub.NC equal to TSN.sub.D at step 158. If TSN.sub.E, is greater than TSN.sub.NC at step 160, then network monitor 56 sets both TSN.sub.NC and TSN.sub.D to TSN.sub.E at step 162. After updating state variables SRN and TSN in cache 30 and database
32, network monitor 56 invokes an alarm synchronization performed by alarm formatter 52, as described in more detail with reference to FIG. 7.
The above process describes a reconciliation of database 32 in step 108 as part of a full database reconciliation process and reconciliation of database 32 at step 122 on a data subset basis. Inherent in 108 and 122 is the logical internal
reconciliation performed by server 14 to maintain consistency between database 32 and cache 30. Therefore, during or after reconciliation of database 32, server 14 also updates the contents of cache 30 to maintain consistency between cache 30 and
database 32. This process may be performed in a similar manner as the reconciliation between database 32 and MIB 24, or using any other suitable database reconcilation process.
The maintenance of the integrity of cache 30 to reflect information maintained persistently in database 32 may also be done by a separate process that periodically marks entries in cache 30 as valid or invalid, retrieves updated information from
database 32, and performs suitable housekeeping functions to remove or update invalid values from cache 30.
FIG. 5 illustrates a method 200 performed by alarm formatter 52 in server 14 for processing traps received from network elements 16. Method 200 begins at step 202 where alarm formatter 52 receives a trap from a particular network element 16. As
described above, this trap may provide general information on network element 16, indicate a failure at various levels of severity (e.g., minor, major, critical), indicate a clear condition, indicate a module insertion event, or provide other status
information on network element 16. The trap includes an object identifier, event code, timestamp, and trap sequence number (TSN.sub.E). Alarm formatter 52 retrieves TSN.sub.E from the received trap at step 204.
At step 206, alarm formatter 52 determines whether TSN.sub.E is equal to an expected trap sequence number (the trap sequence number maintained in AC 60 (TSN.sub.AC) incremented by one). If TSN.sub.E equals TSN.sub.AC incremented by one, then
server 14 sets TSN.sub.AC and TSN.sub.D equal to TSN.sub.E at step 208 and proceeds to process the trap at step 210.
If TSN.sub.E is less than TSN.sub.AC incremented by one at step 212, alarm formatter 52 determines whether TSN.sub.E is in the missing trap list at step 213. If TSN.sub.E is not in the missing trap list, alarm formatter 52 performs a series of
activities to recover from a trap sequence reset at step 215. Alarm formatter 52 clears the missing trap list, sets an alarm synchronization required flag (ASR) to false, removes missing trap timer 53, sets TSN.sub.AC equal to TSN.sub.E, and processes
the trap. After recovering from a trap sequence reset of network element 16, alarm formatter 52 invokes the alarm synchronization method, described below with reference to FIG. 7.
If a trap sequence reset did not occur at step 213, alarm formatter 52 deletes the trap number from the missing trap list in AC 60 at step 214. If the missing trap list includes more entries at step 216, then alarm formatter 52 proceeds to
process the trap at step 210. If, however, there are no more traps in the missing trap list, then alarm formatter 52 resets and stops missing trap timer 53 at step 218 and sets TSN.sub.D equal to TSN.sub.AC decremented by one at step 220. If an alarm
synchronization required flag (ASR) is not true at step 222, then alarm formatter 52 proceeds to process the trap at step 210. However, if ASR is true at step 222, then alarm formatter 52 sets ASR to false at step 224, processes the trap at step 226,
and invokes the alarm synchronization process illustrated in FIG. 7.
If TSN.sub.E is not equal to TSN.sub.AC incremented by one (step 206) and TSN.sub.E is not less than TSN.sub.AC incremented by one (step 212), then alarm formatter 52 proceeds to step 230 and sets TSN.sub.AC equal to TSN.sub.E. Alarm formatter
52 then adds all missing traps to the missing trap list at step 232. For example, if TSN.sub.E retrieved in step 204 is equal to 9 and TSN.sub.AC maintained in AC 58 is equal to 6, then alarm formatter 52 adds traps #7 and #8 to the missing trap list at
step 232. Alarm formatter 52 then sets missing trap timer 53 at step 234 and proceeds to process the trap at step 210.
In a particular embodiment, alarm formatter 52 sets missing trap timer 53 to a time that will allow server 14 to recover from minor out-of-sequence trap events. However, if alarm formatter 52 receives out-of-sequence traps and is not within the
time set in missing trap timer 53 to receive and delete missing traps from the missing trap list, then additional processing is performed as illustrated in FIG. 6.
If missing trap timer 53 expires as determined in step 250 in FIG. 6, then alarm formatter 52 clears the missing trap list at step 252, sets the alarm synchronization required flag (ASR) to false, and invokes the configuration synchronization
method 100 illustrated in FIGS. 3 and 4. By setting and resetting missing trap timer 53 and through maintenance of a missing trap list in AC 58, alarm formatter 52 is able to recover from minor out-of-sequence traps without performing configuration
synchronization method 100. This allows for simple and efficient recovery from the transmission of out-of-sequence traps over management network 20.
FIG. 7 illustrates a flowchart of a method 300 performed by alarm formatter 52 to synchronize alarms at server 14. Method 300 may be invoked periodically, by a user of client 12, upon detection of a trap sequence mismatch, or by network monitor
56. Method 300 begins at step 302 where alarm formatter 52 determines whether the alarm synchronization request is from network monitor 56. If the alarm synchronization request is not from network monitor 56, then server 14 may optionally set a forced
alarm synchronization flag (FAS) at step 304. By setting FAS to true, method 300 guarantees to either perform an alarm synchronization or a configuration synchronization. In contrast if FAS is false and TSN.sub.E equals TSN.sub.AC, no action to
synchronize alarms will be taken.
If the alarm synchronization request is from network monitor 56 at step 302, then alarm formatter 52 retrieves the trap sequence number stored in database 32 (TSN.sub.D) at step 303. Alarm formatter 52 then determines if TSN.sub.D is greater
than TSN.sub.AC at step 306 and, if true, sets TSN.sub.AC to TSN.sub.D at step 308.
Alarm formatter 52 retrieves TSN.sub.E from network element 16 at step 310 and again determines whether the alarm synchronization request is from network monitor 56 at step 312. If it is not, then alarm formatter 52 determines whether TSN.sub.E
equals TSN.sub.AC at step 314. If there is a mismatch, then alarm formatter 52 sets TSN.sub.AC equal to TSN.sub.E at step 316 and invokes configuration synchronization method 100.
If TSN.sub.E equals TSN.sub.AC at step 314, then alarm formatter 52 determines whether FAS is true at step 318. If FAS is false, then no action is performed by alarm formatter 52 and method 300 ends. However, if FAS is true at step 318, then
alarm formatter 52 performs an alarm database reconciliation at step 320 to synchronize cache 30 and database 32 with configuration information maintained in MIB 24. To perform the alarm database reconciliation, server 14 reissues any missed alarms at
step to establish the correct alarm state at database 32. Server 14 will determine the correct alarm state by reconciling the alarms stored in database 32 with the current alarm table stored in MIB 24 of network element 16. All alarms that are present
in the current alarm table but not in database 32 will be reissued by server 14. All alarms that are present in database 32 but not in the current alarm table will be cleared from database 32. Server 14 will also inspect the module table in MIB 24 to
determine if there are any new modules in network element 16 that are not in database 32.
If the alarm synchronization request is from network monitor 56 as determined at step 312, then alarm formatter 52 determines whether there are missing trap list entries at step 322. If the missing trap list is empty, then alarm formatter 52
determines whether TSN.sub.E equals TSN.sub.AC at step 324 and, if so, executes the alarm database reconciliation at step 320. I | | |
