database inter- action. It reads, populates, and maintains the network object model using the discovery interfaces that would involve functions like reading from con- figuration files, reading from dynamically modifiable tables or configuration related event notifications. 2. Configuration component: It offers application program interfaces (API) to add, modify, and delete configuration information related to the network and its elements like nodes, links, and paths. The configuration component creates template objects that would be generic in nature and could be custom- ized for any network element specific set of configuration variables. 3. Fault aggregation component: The role of this component is to collect fault data from the data collection components and convert them to events on objects in the topology model or network object model. This could be faults on the network elements or resources in the network elements. The aggrega- tion logic would be given in the XML files as rulesets, which would have as inputs the different fields of the fault record. Each fault record is expected to have a specific set of fields giving data like the severity of the event that gener- ated the record, the element in which the record was generated, the probable cause of the event, and SO forth. 4. Fault correlation component: This component would be triggered on each event. Based on a set of predefined rules, the fault information is updated when each fault record or event is obtained. The update can be an add, mod- ify, or delete operation in the database. 5. Fault delivery and query component: This component provides the applica- tion program interfaces for delivery of faults and query of faults from a data- base. This functionality is implemented using a listener module that registers for fault data. The registration as well as a fault related query can be filtered on any parameter of the fault record. 6. Performance aggregation and correlation component: This component col- lects performance records from the data collecti