Network Topology Management System Through a Database of Managed Network Resources Including Logical Topolgies

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the xeroxographic reproduction by anyone of the patent document or the patent disclosure in exactly the form it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

The present invention relates to the field of computer systems and their management and control. More specifically, in one particular embodiment the invention provides a method and device for managing and visualizing the topology of a computer network.

As computer networks have developed and achieved wide acceptance, it has become necessary for managers of such networks to have access to software and hardware tools necessary to manage, monitor, and control networks. As networks have increased in complexity, so have the tools needed for their management. Existing management packages for managing a network provide a wide range of functionality including network management application launchers, event request and filtering mechanisms, logging systems for storing network event and performance statistics, alarm correlation mechanisms, load balancing mechanisms, and other tools. Among the most advanced of such packages is SunSoft's Solstice Enterprise Manager 1.1. Other systems include Hewlett Packard's OpenView platform Network Node Manager, Operations Center and AdminCenter; IBM's NetView, and others.

The most advanced of such packages allow multiple operators to access management information simultaneously, and support multiple computing environments. To facilitate this complex functionality advanced network management systems have used an object oriented network model. Network resources represented as objects are stored and manipulated by management applications and agents. The use of such object oriented approaches enables, inter alia, much easier scalability and other advantages. In addition, the support of multiple network management protocols is facilitated. In SunSoft's Solstice products for example, the management tools may be distributed over multiple workstations. The same information is made available to all applications and tools via MISs ("Management Information Servers").

Such systems have met with substantial success and are, in fact, considered to be pioneering in the industry. However, certain challenges remain. For example, while the object oriented approach to network database management has proven successful certain limitations remain. Such systems have, previously, maintained separate databases representing the logical and physical layouts of a network, respectively. Separate applications in the network management system then access and may modify the logical and physical topology databases. In some instances it has been found that two views of the same network can be found to be inconsistent as a result of this architecture.

From the above it is seen that an improved set of tools for maintaining data relating to the physical and logical topology of a network is needed.

Improved tools for maintaining, viewing, and managing the physical and logical topology of a network are provided by virtue of the present invention. The system maintains databases for both logical and physical topology using an improved data model. Consistency is maintained by placing a consistency application in a logical/physical database. Users are able to access the data only through the physical topology database. Both physical and logical topology resides in MIS database.

Accordingly, in one embodiment the invention provides a computer network comprising a plurality of network nodes and interconnections; a network management system comprising a database of managed network resources, the database of managed network resources defining network nodes, associated node types, and associated views of the nodes; and a plurality of network management users, the network management users displaying views of the network using said network management database. Through user modification of node attributes, the views of the network are updated by the system through use of an object oriented database. In a preferred embodiment the views of the network are modified based on input or change of the attributes of the nodes. For example, parent relationships may be used to define a new view node when a new parent is added to an attribute of a node.

A further understanding of the nature and advantages of the inventions herein may be realized by reference to the remaining portions of the specification and the attached drawings.

FIG. 1 is an overall view of a hypothetical network, showing the relationship to the network management tools described herein;

FIG. 2 is a typical screen display provided by one embodiment of the invention;

FIG. 3 is an object relationship diagram according to one specific embodiment of the invention;

FIGS. 4A, 4B, and 4C illustrate a simple application of the invention;

FIGS. 5A, 5B, 5C, and 5D illustrate specific data structures used herein; and

FIGS. 6A, 6B, and 6C illustrate use of the invention in specific examples.

FIG. 1 illustrates a computer network along with its associated network management system. As shown, the computer network 100 will include hardware such as hosts 101a, 101b, 101c, 101d, and 101e, router 103, and subnetworks 100a and 100b. Hosts 101 may be, for example, users, servers, and other network elements. Attached to one or more of the hosts are network management elements 109. Management elements 109 will be connected to one or more of the network hosts for network managers to monitor and control the network.

The layout of the network is illustrated with regard to physical connectivity, but another set of relationships will also exist. That is, the various elements of the network will also be related by logical relationships. For example, a portion of the users connected to servers 101a and 101b may be in one logical group, while other portions of the network will be in other logical groups. Often it is desirable for network managers to be able to view the network in logical views rather than the physical layout of the network. The present invention provides an improved viewer for looking at and analyzing various portions of the network.

A management system or "nerve center" 111 is provided in the network to manage and control the network. While the management system 111 is illustrated as a single entity on the network, it may in many embodiments be distributed over multiple workstations and servers.

The management system includes an MIS or Management Information Server 113. The MIS is an object oriented network model that enables object definitions to be stored and manipulated by management applications 115, using object oriented tools such as classing, inheritance and scoping to represent complex resources and simplify complex operations. Management applications 115 interact through the network MIS rather than with each other.

System 111 will normally include a set of standard tools such as a relational database logging tool, alarm managers, and other tools. The system is able to provide access to managed objects via a common management information protocol (CMIP) with management protocol adapter (MPA) 119. Other system elements are supported directly through an interface such as a protocol driver manager (PDM) in the case of, for example, SunNet Manager Agent interactions.

As shown in FIG. 1, a particular user of the system will have applications 115 resident on his/her particular server or workstation. In addition, the user may have various tools, a particular graphical user interface 123, and viewer 125. The various applications utilize the resources of the nerve center to perform management tasks. A database 127 in the nerve center provides a single source of network objects in an object oriented relational database to service the various network applications for management of the network. The system illustrated in FIG. 1 will, in a preferred embodiment, be based on the Solstice Enterprise Manager 1.1, available from Sun Microsystems, Inc. The various software and data elements discussed herein are stored on a memory device 128 such as one or more magnetic or optical disc drives.

FIG. 2 illustrates a typical screen display available to a user of the network management system disclosed herein. As shown, the system will display a viewer 201 in which the topology of the system (logical or physical) may be displayed. In addition, the system may display other items of interest such as an alarm report 203.

Both the logical and physical elements of the network model are stored in a common database 127 according to the invention herein. FIG. 3 illustrates the architecture of the network database 127 according to a preferred embodiment of the invention. The purpose of the topology database is to store topological information about the managed networked environments. Topological information is in the form of objects which represent topological nodes, views, viewnodes, and types. The topology database includes data of the following types: a topoTypeDB, a topoNodeDB, and a topoViewDB. These data are used by the system applications to manage the user's networks.

topoTypeDB

The topoTypeDB object class 301 contains the general relationship or rules between objects (which represent a topoType 303). In other words, topoTypeDB contains a list of object types. Examples of such object types would be servers, routers, hubs, and users.

The topoTypeDB is a managed object class that acts as a "container" for all topoType objects. The topoTypeDB object class is named under the system object and only one instance of a topoTypeDB object class can be created under a system. TopoType is an object class that is named under the topoTypeDB object class.

topoNodeDB

The topoNodeDB object class 305 contains a flat layout of the objects in the particular managed networked environment, that is, lists of all nodes 307 in the network and their attributes.

The topoNodeDB is a managed object class that acts as the "container" for all topoNode objects. This object class lists all nodes and their attributes. The topoNodeDB object class is named under the system object and only one instance of the topoNodeDB object class can be created under a system.

TopoNode is an object class that is named under the topoNodeDB object class. The topoNode object class has the following features. TopoNode can be positioned in multiple views. This attribute is allowed since the behavior of "topoTypeLegalChildren" is checked for all parents specified by the attribute. The ASN1 syntax of topoNodeParents is a set of topoNodeId's. Special secondary index queries can be done with actions. TopoNode objects can be renamed. The topoNodeName attribute is unique across all topoNodes under the same topoNode DB. The reason that topoNodeName is not used as the naming attribute is to allow renaming of topoNode objects. If a topoNode object is renamed, it's new name cannot be the same as the name of an existing node.

A topoNodeChildren attribute is a reverse relationship attribute of a topoNodeParents attribute. It specifies all the topoNode children that are contained by this topoNode. Propagation severity of topoNode objects can be tracked and propagation can be controlled such that, for example, alarms are indicated in desired views.

Each node has an associated severity, derived from alarms posted for the corresponding resource. The tracking of the propagated severity is performed with a "topoNodePropagateSeverity" attribute. This attribute is the maximum value of the topoNodeSeverity of the topoNode and the topoNodePropagateSeverity of all its children.

To control propagation locally, a topoNode's "topoNodePropagateUp" attribute is used. To turn the propagation off for the entire topology database, the topoNodeDB's "topoStatePropagation" attribute is used. By default, the global propagation flag is set on. A topoNode propagates its current severity to its parents only if its topoNodePropagateUp flag is on and topoNodeDB's topoStatePropagation flag is on.

topoViewDB

The topoViewDB 309 object class contains views of the objects in the managed networked environment, that is, of all views 311. The various views contain logical groups of network resources or topology nodes that a user may wish to use for management purposes. For example, a view of various ethernet servers in a network may be desired to monitor the failure rate of such servers. Thus, a view of such servers will be formed.

TopoViewDB is a managed object class that acts as the container for all topoview objects. TopoViewDB lists all views; each of these views are called a topoview. The topoViewDB object class is named under the system object and only one instance of the topoViewDB object class can be created under a system. A view is a graphical representation of a set of related managed objects. For example, in a network that contains multiple subnetworks, the network might be one view that has subnetwork elements and each subnetwork within it might constitute or use separate views.

TopoView is an object class that lists views and is named under the topoViewDB object class. Each topoview object is called a topoViewNode. Each instance of the topoview class represents a view in an executable viewing program (em.sub.-- viewer in the case of SunSoft) to display objects that are in the view and store attributes that are related to the view. TopoView objects show relationships and hierarchy between objects. Instances of the class are named under topoViewDB, but create/delete operations are not supported by the name binding.

The topoViewNode objects 313 represent topoNode objects in different views (different logical views). Each topoViewNode object is associated with a topoNode object. There is a many-to-one relationship between topoViewNode and topoNode objects. If the information is available in the topoViewNode's associated topoNode object, the information is not duplicated in the topViewNode object. The exception is that the topoNodeId attribute is used as the naming attribute to create topoViewNode objects.

Since instances of the class are named under topoview, create/delete operations are not supported by the name binding. All topoViewNode objects are created/deleted as side effects of creating/deleting topoNodes and adding/removing parents to form a "topoNodeParents" attribute of topoNode objects. The MIS is responsible for maintaining the referential integrity between topoViewNode and topoNode objects (for example, a topoNode can contain other topoNodes).

TopoViewNode objects are automatically updated. When a new parent is added to the topoNodeParents attribute, the MIS creates a topoViewNode object associating to the topoNode under a topoview object which associates to the new parent. When an old parent is removed from topoNodeParents, the MIS deletes the topviewNode object associating to the topoNode from the topoview object which associates to the old parent. If the user wants to move or place a topoNode in a different or another view, it will be necessary to change the topoNode's topoNodeParents attribute.

Data integrity between topoNode, topoview, and topoViewNode is maintained by the system. Data integrity is maintained by the behavior, in the system herein, of the class. Once a new topoNode is created, if the type of the topoNode can contain other topoNodes, the MIS will create a topoview object associated to the topoNode. If a topoNode is deleted, all topoview and topoViewNode objects associated with the topoNode are automatically removed by the MIS.

FIG. 3 includes a description of the containment of the various objects in the database. Specifically, TopoViewDB, topoNodeDB, and topoTypeDB are contained within the "system." A topoview is contained within the topoViewDB. A topoViewNode is contained within a topoview. A topoNode is contained within the topoNodeDB. A topoType is contained within the topoTypeDB.

The reference rules for the database are as follows. A topoview must reference a topoNode. Only one topoview can reference a single topoNode. A topoViewNode must reference a topoNode. One or more topdViewNodes can reference a single topoNode. A topoNode can reference other topoNodes as topoNodeParents or topoNodeChildren. A topoNode must reference one topoType. A topoType can be referenced by multiple topoNodes.

Table 1 provides general descriptions of topology types.

FIGS. 4A to 4C illustrate various views of a network using the system herein. FIG. 4A illustrates a view of several routers 401 in a network. FIG. 4B illustrates a new view that has been created including only two of the routers that a particular user desires to monitor. FIG. 4C illustrates the display after using the system to add another router to the view. Of course, the layout of networks is most often quite complex and FIGS. 4A-4C shows only a simple illustration.

FIGS. 5A to 5D illustrate the data formats and contents of a particular topoType (FIG. 5A), topoNode (FIG. 5B), topoview (FIG. 5C), topoViewNode (FIG. 5D). Of interest, in topoNode, the topoNodeChildren entry (and, not shown, parents) is changed upon change or deletion of, e.g., a parent or other relevant attribute.

FIG. 5A illustrates the data structure for a topoType. FIG. 5B illustrates a topoNode entry. FIG. 5C illustrates a particular topoview entry. FIG. 5D illustrates the topoViewNode entry for node 13 in FIG. 5B.

The definition of all objects is preferably in GDMO (Guidelines for Definition of Managed Objects) format. The definitions according to one embodiment are included in Appendix 1 (topo.gdmo). The syntax for GDMO objects is defined in ASN.1. Appendix 2 (topo.asn1) provides object syntax according to one specific embodiment of the invention.

FIGS. 6A to 6C illustrate typical use of the present invention. A user typically identifies objects such as routers, hubs, bridges, print servers, NFS servers, and WAN links that have an impact on the greatest number of users on the network. The typical user will then monitor only those devices, reducing the number of managed objects to create and monitor.

In the system herein a view of the network can include part (or all) of a network topology or it can simply be an arbitrary collection of managed objects, not part of the topology. In a small scale network, one might wish to place all the critical nodes into a single view of the network, as shown in FIG. 6A. In this example, a network includes two subnets (A and B), which are connected by a router.

For most network configurations it will be useful to have multiple views of the network to represent functional groupings of network devices and to represent the network topology. Using the database model discussed above, one might want, for example, to depict devices in particular buildings, or a view that consists only of routers. Taking the example in FIG. 6A one might want to create a separate view for each subnet as well as separate views by type of device (routers, NFS servers, and print servers). A user would create these views one element at a time using a graphical user interface, which would then build the database elements discussed above. As an example, views grouping elements by function (software servers, routers, and print servers) and subnetwork(s) might be formed as shown in FIG. 6B. A high level view is shown in FIG. 6C. As shown therein, cloud icons represent the separate views that have been created. By double clicking on the clouds, one would then see the elements within these views of the network. of course, the same element may appear in multiple views. For example, a particular server could occur in both a "servers" view as well as the Net.sub.-- B view, which shows all of the nodes in that subnetwork.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those of skill in the art upon review of this disclosure. Merely by way of example specific database relationships have been used for illustration, but the invention is not so limited. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents. ##SPC1##