DETAILED DESCRIPTION

[0029] Although the present invention is open to various modifications and alternative constructions, a preferred exemplary embodiment that is shown in the drawings is described herein in detail. It is to be understood, however, that there is no intention to limit the invention to the particular forms disclosed. One skilled in the art can recognize that there are numerous modifications, equivalents, and alternative constructions that fall within the spirit and scope of the invention as expressed in the claims.

[0030] Referring now to FIG. 2 , there is illustrated a system 120 for configuring network devices 100 , 105 , 125 , 130 (collectively 135 ) in accordance with the principles of the present invention. This embodiment includes a network manager unit 140 disposed between the administrator 110 and the network devices 135 , which can include routers, optical devices, etc. The network manager unit 140 also is connected to remote storage 145 (connected by network 150 ) and a network manager support 155 .

[0031] To alter the configuration of a network device 135 or to add a network device to an existing network, the administrator 110 can access the network manager unit 140 , search for and retrieve the configuration record corresponding to a target network device, and through a series of interactive, wizard-like screens, change the configuration record for the target network device. This altered configuration record is stored in a central repository in the network manager unit 140 and can be checked against network policies accessible by the network manager unit 140 . Next, the network manager unit 140 can generate device-specific commands from the new configuration record and push those device-specific commands to the target network device or have the target network device pull the commands. Finally, the network manager unit 140 can verify that the new configuration was installed correctly at the target network device.

[0032] To generate the necessary device-specific commands, the network manager unit 140 may access the remote storage device 145 that can contain the various templates needed to generate device-specific commands for different types, brands, and/or models of network devices. Each of these templates can contain variable fields corresponding to either information stored in the configuration records or information input directly by the administrator. The network manager unit 140 generates the device-specific commands by retrieving the appropriate template and filling in the variable fields with the data from the configuration records and/or data input directly by the administrator 110 . Once generated, these device-specific commands can be stored in the configuration record and/or they can be stored in the remote storage device 145 with an appropriate pointer stored in the configuration record.

[0033] As can be appreciated by those skilled in the art, the network manager unit 140 can be implemented on virtually any hardware system. Good results, however, have been achieved using components running the Red Hat™ LINUX Operating System and the Sun Solaris™ UNIX Operating System. In embodiments running either of these operating systems, the network manager unit 140 preferably is configured to utilize the common services provided by that particular operating system.

[0034] Referring now to FIG. 3 , there is illustrated in more detail the network manager unit 140 shown in FIG. 2 . This embodiment of the network manager unit 140 includes six basic modules: an interface 160 , a directory 165 , a policy manager 170 , an event bus 175 , a health manager 180 and an action manager 185 . The illustrated connections between the various components are exemplary only. The components can be connected in a variety of ways without changing the basic operation of the system. Although the division of the network manager unit 140 into the six components is the presently preferred embodiment, the functions of these components could be subdivided, grouped together, deleted and/or supplemented so that more or less components can be utilized in any particular implementation. Thus, the network manager unit 140 can be embodied in several forms other than the one illustrated in FIG. 3 .

[0035] Referring first to the interface module 160 , it is designed to exchange data with the administrator 110 (shown in FIG. 2 ) and, in some embodiments, with the network devices 135 (also shown in FIG. 2 ). Although the interface 160 could implement virtually any type of interface, good results have been achieved using a graphical, web interface. Other interfaces can be based upon wireless protocols such as WAP (wireless application protocol).

[0036] The second component of the network manager unit 140 is the event bus 175 . The event bus 175 includes a central posting location for receiving messages relating to network events. For example, when a configuration for a network device 135 is to be changed, an appropriate message can be published (or otherwise made available) to the event bus 175 . Similarly, if a network condition such as an error occurs, an appropriate message can be published to the event bus 175 . Notably, any message published to the event bus 175 can also be sent to the administrator 110 by way of the interface 160 . The administrator 110 , however, does not necessarily need to respond to a received message for the event to be addressed by the network manager unit 140 .

[0037] To determine the proper response for a message posted to the event bus 175 , the received message can be compared against the policies stored in the policy manager 170 , which is a repository for the business and network policies and rules used to manage the network. By using these rules and policies, an administrator 110 (shown in FIG. 2 ) can define a response for any event published to the event bus 175 . The defined response can be virtually anything including reconfiguring a network device, shutting down a network device and notifying an administrator.

[0038] In operation, the policy manager 170 can read a message posted to the event bus 175 . Alternatively, the event bus 175 can automatically push the message to the policy manager 170 . Either way, however, the policy manager 170 uses the message to access policy records that can be stored, for example, in a look-up table and to correlate the message to the appropriate response. Once the policy manager 170 has determined the appropriate response, that response is published to the event bus 175 as a work order that can be read by the action manager 185 and subsequently executed. That is, the action manager 185 can read the work order from the event bus 175 and perform the necessary tasks to complete that work order. In other embodiments, the work order can be sent directly to the action manager 185 . For example, assume that the action manager 185 reads a work order from the event bus 175 that indicates two routers—one a Cisco™ router and one a Juniper™ router—need to be enabled. The action manager 185 can locate each of these routers and determine the device-specific code needed to enable them. The code required to enable the Cisco™ router, for example, might be “enable_router” and the code required to enable the Juniper™ router might be “router_enable.” Because the action manager 185 determines the appropriate device-specific code, however, the administrator 110 (shown in FIG. 2 ) only needs to generically indicate that both devices are to be enabled. The administrator 110 does not need to know the actual device-specific code required by each router. This feature is described in greater detail with relation to FIG. 8 .

[0039] In other embodiments, the action manager 185 can verify that the administrator 110 (shown in FIG. 2 ) has authority to make changes to network devices without authorization from additional parties. If additional authorization is required, the action manager 185 can post an appropriate message to the event bus 175 .

[0040] Still referring to FIG. 3 , the directory 165 of the network manager unit 140 includes a central repository for storing the configuration records of each of the network devices connected to the network manager unit 140 . For example, the directory 165 could store a separate configuration record for each of network devices 100 , 105 , 125 and 130 shown in FIG. 2 . In certain embodiments, several interconnected directories may be utilized, and in such systems, each directory can store a certain subset of the configuration records or a complete copy of all of the configuration records. Generally, such embodiments would employ multiple linked network manager units 140 , and in the embodiment where complete copies of the configuration records are stored in different directories, synchronization techniques can be used to guarantee data integrity.

[0041] The configuration records stored in the directory 165 are searchable by way of the interface 160 . That is, the administrator 110 or a component within the network manager 140 (shown in FIG. 2 ) can initiate a search through the interface 160 and the results of that search can be made available to the administrator 110 through the interface 160 . Moreover, the configuration records can be searched in any of a variety of ways. For example, the configuration records can be searched according to equipment type (e.g., routers, optical devices, etc.), device type (edge router, core router, etc.), device location, device manufacturer, device model, device name, operational status, etc. The directory 165 can be used to enable directory-based networking.

[0042] Referring now to the health manager 180 , it can be configured to monitor the overall health of the network and/or the health of individual network devices 135 (shown in FIG. 2 ) within the network. The health manager 180 can operate in an active mode and/or a passive mode. In the active mode, the health manager actively polls at least some of the network devices 135 about their status, utilization, congestion, etc. In the passive mode, the various network devices 135 automatically report to the health manager 180 . In either embodiment, however, the health manager 180 can collect individual device information and model overall network health. Additionally, the health manager 180 can publish messages regarding network device problems, projected network device problems, network problems, and/or projected network problems. The policy manager 170 can then determine the appropriate course of action to take for the particular message and the action manager 185 can implement that response.

[0043] In further embodiments, the health manager can monitor the health of the network manager components. For example, the health manager can monitor the operation of the event bus, the action manager and/or the directory. Moreover, the health manager can monitor the flow of data between the various components of the network manager.

[0044] Referring now to FIG. 4 , there is illustrated in more detail the directory 165 shown in FIG. 3 . This embodiment of the directory 165 consists of four interconnected modules: configuration storage 187 , configuration comparator 190 , configuration reader 195 and interface 200 . The directory 165 , however, does not need all of the modules to function in accordance with the principles of the present invention.

[0045] The configuration reader module 195 of the directory 165 is designed to initiate communication with (or directly communicate with) a target network device and retrieve that device's actual configuration. For example, the configuration reader can retrieve the actual configuration from the memory 115 of router 105 (shown in FIG. 2 ). This retrieved actual configuration can then be passed to the configuration comparator 190 . The configuration reader 195 can also retrieve the intended configuration of the target device from the configuration storage 187 and pass that intended configuration to the configuration comparator 190 . The configuration comparator 190 can then compare the actual configuration and the intended configuration and present the differences to the administrator 110 (shown in FIG. 2 ). In one embodiment, the differences in the configurations are not only presented literally, but also in a natural language summary form. Once the differences have been identified, they can be used to identify a failed configuration installation and/or to aid the administrator in creating the proper configuration for a device.

[0046] As previously discussed, the configuration storage 187 is designed to store configuration records corresponding to network devices such as network devices 135 shown in FIG. 2 . In one embodiment the configuration storage 187 is designed not only to store the present configuration record for a network device, but also to store previous configuration records for that device. By storing these previous configurations, fault recovery and correction are vastly improved over present systems because prior, successful configurations can be quickly retrieved and used to replace new, faulty configurations. For example, a prior configuration of a previously known good state can be retrieved and installed on the associated network device. This prior configuration could be days old or even weeks old. Prior configuration records can be distinguished by version numbers and/or a time stamp. Additionally, each configuration record can include a searchable summary that includes notes on the configuration and why that configuration was modified.

[0047] Referring now to FIG. 5 , there is illustrated a configuration record 205 for a typical network device. This configuration record 205 is divided into four portions: a common information model (“CIM”) data portion 210 , a vendor data portion 215 , proprietary data portion 220 and a data pointer 225 . The CIM data portion 210 contains data relating to the physical attributes of a particular network device such as name, device type, number of interfaces, capacity, etc. The CIM data items are defined in the CIM Specification v2.2 and the CIM Schema v2.4, both of which are well known in the art and incorporated herein by reference.

[0048] The vendor data portion 215 of the configuration record contains standard vendor-specific data regarding the particular network device. For example, the vendor data portion 215 could indicate which version of an operating system that the network device is running or which features of the device are enabled. Generally, the data in the vendor data portion 215 is specific to each manufacturer and even to each model of network device.

[0049] The proprietary data portion 220 of the configuration record can contain data used by the network manager unit in configuring and managing the network devices. In one embodiment, for example, the proprietary data portion 220 includes a pointer to an address at which a core dump for a network device is stored. That is, if a router initiates a core dump, the location of that core dump could be recorded in the proprietary data portion 220 of the configuration record for that router. In other embodiments, the proprietary data portion 220 can store version numbers, time stamps, health records for a particular configuration, configuration summary data, configuration notes, etc.

[0050] The pointer portion 225 of the configuration record 205 can be used to point to a storage location where the actual device-specific commands for the associated network device are stored. Similarly, the pointer 225 could be configured to point to a storage location for a device-specific template for configuring a newly installed network device. In other embodiments, the pointer portion 225 of the configuration record can be supplemented or replaced with a storage location for actual device-specific code.

[0051] Referring now to FIG. 6 , there is illustrated in more detail the event bus 175 shown in FIG. 3 . As previously described, the event bus 175 is a posting location for messages relating to network events. Network devices as well as the other components of the network manager unit 140 (shown in FIG. 2 ) can address and post events to the event bus 175 .

[0052] The particular embodiment of the event bus 175 shown in FIG. 6 is comprised of four basic modules: an interface 230 , a status storage 235 , an event queue 240 , and an event queue manager 245 . In operation, a message indicating the occurrence of a network event is posted to the event queue 240 by way of the interface 230 . The messages stored at the event queue 240 are then made available to the policy manager 170 (shown in FIG. 3 ), so that a proper response can be determined. If the posted message is a work order from the policy manager 170 , the work order is made available to the action manager 185 (shown in FIG. 3 ) for subsequent implementation.

[0053] In one embodiment of the event bus 175 , an event message is stored in status storage 235 along with a status field and an age field. Thus, for any message posted to the event bus 175 , its status and age can be continuously monitored. (The event bus can also get messages from client devices.) For example, status storage 235 could indicate that the status for a particular event is pending in the action manager 185 (shown in FIG. 3 ), awaiting proper authorization completed, stalled, etc. As the status changes from one status to another, appropriate messages can be generated and posted at the event queue 240 . For example, if the status of an event changes from pending to stalled, an appropriate message can be posted to the event queue 240 so that the policy manager 170 can determine how to respond. Similarly, if the age field in the status storage 235 indicates that a particular network event has not been addressed within a predetermined amount of time, that event can be requeued, deleted from the event queue 240 , or a new event notification indicating the delay can be generated and placed on the event queue 240 .

[0054] Referring now to FIG. 7 , there is a flow chart of one method for configuring or reconfiguring a network device in accordance with the principles of the present invention. In this embodiment, the administrator 110 (shown in FIG. 2 ) initially logs in to the network manager unit 140 (Step 250 ). Through a series of a graphical interfaces (such as the global GUI in FIG. 8 ), the administrator 110 can select a network device that needs to be configured or reconfigured. The configuration record associated with the selected device can then be retrieved from the directory 165 (shown in FIG. 3 ) and presented to the administrator (Step 255 ). If no configuration record is available for a selected device, the administrator 110 will be guided through a series of steps to build the configuration for that device. Otherwise, the administrator 110 can change parameters within the configuration record of the selected device and save those altered configuration records within the directory 165 (Step 260 ). Notably, even though the configuration record for the selected network device has been changed, the actual configuration of the device has not been changed. Before the configuration of the device can be changed, an event message indicating that a configuration record has been altered should be published to the event bus 175 (shown in FIG. 3 ) (Step 265 ). The policy manager 170 (shown in FIG. 3 ) then receives the event message, either by reading it from the event bus 175 or by receiving it from the event bus 175 , and determines if the configuration change is authorized (Step 270 ). If the configuration change is within the network rules and the administrator 110 (shown in FIG. 2 ) is authorized to make the change, a work order is published to the event bus (Step 280 ). The action manager 185 (shown in FIG. 3 ) can then read the work order from the event bus 175 and carry out the necessary steps to implement the work order (Step 280 ).

[0055] In one embodiment, the action manager 185 (shown in FIG. 3 ) carries out the work order by locating the target network device, retrieving the appropriate configuration record from the directory 165 (shown in FIG. 3 ), generating the device-specific code corresponding to the altered configuration (Step 290 ), and pushing the device-specific code to the target network device (Step 295 ). The action manger 185 can also store the device-specific code in a remote storage device, such as remote storage device 145 shown in FIG. 2 , and a pointer to the remote storage device can be recorded in the configuration record. Finally, the action manager 185 can verify that the device-specific code was properly transferred to the selected network device and that the network device is behaving accordingly (Step 300 ). Assuming that the device-specific codes were installed correctly and that the network device is operating properly, a completion message is published to the event bus 175 (shown in FIG. 3 ) (Step 305 ).

[0056] Referring now to FIG. 8 , there is illustrated a network system with an integrated global graphical user interface (GUI 310 ). In this embodiment, a global GUI 310 is disposed between the network administrator 110 and various network devices (collectively 315 ). These network devices include storage devices 320 a and 320 b, routers 325 a and 325 b, and DWDM (dense wave division multiplexing) switches 330 a and 330 b connected to optical servers 335 a and 335 b. Notably, the network devices of the same type can be manufactured by different manufacturers. For example, router 325 a can be manufactured by Cisco™ and router 325 b can be manufactured by Juniper™.

[0057] As previously discussed, in present network systems, a network administrator 110 could be required to navigate different communication interfaces for each of the network devices 315 . Thus, for network system x, a network administrator 110 without the benefit of the present invention could be forced to learn six distinct interfaces. Through the present invention, however, the network administrator 110 can communicate with any of the network devices 315 by navigating the global GUI 310 , which presents the network administrator 110 with a familiar graphical interface that has a similar look and feel for all network devices 315 , regardless of device type or manufacturer.

[0058] Configuration and reconfiguration of a network device requires that certain attributes be provided to the network device. For different types and manufacturers of devices, these attributes and their formats can vary. DWDM switches, for example, require a wavelength attribute that routers do not. Moreover, one DWDM manufacturer may require the wavelength in a first format, and a second manufacturer may require the same information in a second format. Thus, the global GUI 310 can include both attributes and formatting instructions associated with each of the network devices 315 . Good results have been achieved by arranging these attributes and/or formatting instructions in a directory tree 340 such as the one shown in FIG. 9 . In this directory tree 340 , the attributes and/or formatting instructions for a model A, Cisco™ router can be located by traversing the tree from the root to the router node to the Cisco™ node to the Model A leaf. The appropriate attributes and/or formatting instructions can be located from the Model A leaf.

[0059] To populate the attribute fields, the global GUI 310 could prompt the network administrator 110 for the necessary information. Once the global GUI 310 has acquired the necessary information, the information can be properly formatted—in accordance with the formatting instructions—and passed to the appropriate network device. In the presently preferred embodiment, the global GUI 310 formats the attribute data for a particular network device into a frame that includes a header portion and a payload portion. The header portion can include routing instructions in various formats including HTTP, and the payload portion can include the attribute data in various formats including XML. Additionally, the attribute data can be ordered within the payload according to the formatting instructions. When a network device receives a frame from the global GUI, it can extract the attribute data from the payload and use that data as if it had been received through the network device's own interface. Notably, the frame can be stored on virtually any computer media and/or can exist as an electronically altered signal-collectively referred to as a “computer program product.” (A “computer program product” refers to any media that may be used to provide programming instructions or data to an electronic system. A computer program product includes, but is not limited to, any memory device (whether fixed or removable), any storage medium, and/or any electronically altered signals that carry data.)

[0060] By using the present invention, a network administrator 110 need only learn to navigate the global GUI 310 and not the individual GUIs for the various network devices. Because the present invention allows network devices 315 to be configured and reconfigured without regard to their type or manufacturer, network administrators 110 will be able to add network devices to their network even when they are otherwise unfamiliar with the means for communicating with that type/brand of device. Additionally, the present invention will increase competition in the network device market because new device manufactures will be able to enter the market without first training network administrators to use their products. Moreover, the present invention will reduce network provider costs because fewer specialized administrators will be needed to communicate with the various types of devices.

[0061] Although the global GUI 310 can be operated independently of the network manager unit 140 (shown in FIG. 2 ), good results are expected when the two components are integrated. For example, the global GUI 310 could be used to alter the centrally stored configuration record for a network device. In fact, the templates used by the global GUI 310 can be associated with or even integrated with the configuration records stored in the directory 165 (shown in FIG. 3 ) of the network manager unit. For example, the data pointer 225 (shown in FIG. 5 ) could point to a corresponding template in the global GUI 310 .

[0062] The information stored in a configuration record 205 can be used to populate the attribute fields for a network device's template. In other words, the network manager unit 140 (shown in FIG. 5 ) could retrieve the template for a particular network device, populate the attribute fields of that retrieved template with information from the device's configuration record, format the attribute fields into a frame and pass that frame to the network device. This frame, in some embodiments, constitutes the device-specific commands required to configure the network device.

[0063] In conclusion, the present system provides, among other things, a method and apparatus to configure, monitor and manage network devices without regard for device type and/or manufacturer. Those skilled in the art, however, can readily recognize that numerous variations and substitutions may be made in the invention, its use and its configuration to achieve substantially the same results as achieved by the embodiments described herein. Accordingly, there is no intention to limit the invention to the disclosed exemplary forms. Many variations, modifications and alternative constructions fall within the scope and spirit of the disclosed invention as expressed in the claims.