US20020091857A1 - System and method for determining network status along specific paths between nodes in a network topology - Google Patents
System and method for determining network status along specific paths between nodes in a network topology Download PDFInfo
- Publication number
- US20020091857A1 US20020091857A1 US10/032,970 US3297001A US2002091857A1 US 20020091857 A1 US20020091857 A1 US 20020091857A1 US 3297001 A US3297001 A US 3297001A US 2002091857 A1 US2002091857 A1 US 2002091857A1
- Authority
- US
- United States
- Prior art keywords
- path
- connector
- end node
- node
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
Definitions
- the present invention generally relates to data communication networks and, more particularly, to systems and methods for determining the operational status of devices along a probable network path or paths between two nodes in a network topology.
- a data communications network generally includes a group of devices, such as computers, repeaters, bridges, switches, routers, etc., situated at network nodes and a collection of communication channels for interconnecting the various nodes. Hardware and software associated with the network and, particularly, the devices permit the devices to exchange data electronically via the communication channels.
- a local area network is a network of devices in close proximity, typically less then one mile, and usually connected by a single cable, for instance, a coaxial cable.
- a wide area network is a network of devices which are separated by longer distances, often connected by, for example, telephone lines or satellite links. In fact, some WANs span the U.S. as well as the world. Furthermore, many of these networks are widely available for use by the public, including universities and commercial industries.
- IP Internet Protocol
- TCP Transmission Control Protocol
- UDP Unreliable Datagram Protocol
- TCP/IP Transmission Control Protocol/IP
- SNMP simple network management protocol
- management software packages (“management platforms”) are presently available for implementing “management stations” on a network and particularly in connection with the SNMP.
- Examples of commercially available SNMP management software packages include OpenView from the Hewlett-Packard Company, NetView/6000 from IBM Corp., Spectrum from Cabletron Systems, Inc., Netlabs/Manager from Netlabs, Inc., and SunNet Manager from Sun Connect, Inc.
- the nodes on a network and their interconnections, oftentimes referred to as a network “topology,” are best displayed in a graphical format and most, if not all, of the available management packages provide for this feature.
- a network can be viewed from different vantage points, depending on the scope of the view desired.
- one view of the network could be a very wide encompassing view of all nodes on the entire network.
- a second view could be a view of those portions of a network within a local range, for example, within a particular site or building.
- a third view of a network, often called a segment, could be a view of the nodes attached to a particular LAN cable.
- a user may consider it beneficial to be able to predict the probable path or paths between two nodes in a network. Additionally, it may be beneficial to be able to determine the status of data transfer or other network devices situated at the network nodes along the probable path or paths. However, heretofore, the ability to determine the probable path or paths between two nodes has not been addressed by available management platforms. Likewise, the ability to determine the status of network devices along the probable path or paths has not been addressed.
- the present invention relates to determining the status of and continually monitoring network devices along a probable network path or paths between two nodes in a network topology.
- embodiments of the present invention may be construed as providing systems for determining paths between a start node and an end node of a communication network.
- a communication network is formed of sub-networks, with each of the sub-networks including one or more connectors and one or more segments. More specifically, the segments interconnect various ones of the connectors, with the start node, which corresponds to one of the connectors, being designated at one end of the path, and the end node, which corresponds to another of the connectors, being designated at the other end of the path.
- the connectors are identified, their statuses are continually monitored.
- the system includes a processor, a discovery mechanism, a layout mechanism, and a connector evaluation mechanism.
- the discovery mechanism is configured to generate and store topology data specifying connectors and segments of a communication network.
- the layout mechanism which interfaces with the discovery mechanism, is configured to receive topology data from the discovery mechanism and drive a display based upon the topology data.
- the discovery mechanism is configured to determine a path between a start node and an end node based upon the topology data. For instance, such a path(s) may be based upon information corresponding to a type of path of interest and/or information corresponding to a type of connector of interest.
- the connector evaluation mechanism is configured to receive parameter values from the connectors along the path representative of their operational status and compare the parameter values to preselected values or specifications. If a connector parameter exceeds a preselected specification, an event is generated signaling an error with the connector.
- Some embodiments of the present invention may be construed as providing methods for determining the status of paths between a start node and an end node of a communication network.
- a preferred method includes the steps of: receiving information corresponding to the start node and the end node; receiving information corresponding to a type of path of interest; receiving information corresponding to a type of connector of interest; determining a path between the start node and the end node based upon the type of path of interest and the type of connector of interest; identifying at least one connector in the path; receiving data representative of an operating parameter from the at least one connector; comparing the data to a predetermined value; and providing an indication if the data exceeds the predetermined value.
- a preferred computer readable medium includes: logic configured to receive information corresponding to the start node and the end node; logic configured to receive information corresponding to a type of path of interest; logic configured to receive information corresponding to a type of connector of interest; logic configured to determine a path between the start node and the end node based upon the type of path of interest and the type of connector of interest; logic configured to receive a parameter value from a connector in the path; logic configured to compare the parameter value to a preselected value; and logic configured to generate an event if the parameter value exceeds the preselected value.
- FIG. 1 is a block diagram of a management station including discovery/layout software which employs a preferred embodiment of the system and method of the present invention.
- FIG. 2 is a schematic diagram illustrating a display map, which comprises a collection of sub-maps, any of which can be displayed on the display of the management station by the discovery/layout software of FIG. 1.
- FIG. 3 is a block diagram of the discovery/layout software implementing a preferred embodiment of the present invention.
- FIG. 4 is a flowchart depicting functionality of a preferred embodiment of the present invention.
- FIG. 5 is a flowchart depicting functionality of a preferred embodiment of the present invention.
- FIG. 6 is a flowchart depicting functionality of a preferred embodiment of the present invention.
- FIG. 7 is a flowchart depicting functionality of a preferred embodiment of the present invention.
- FIG. 1 shows a block diagram of an object-oriented management station 100 which is implemented with a general purpose computer system containing novel discovery/layout software 101 , which employs a probable path mechanism 103 and associated methodology of the present invention.
- the management system 100 contains a processor 102 .
- the processor 102 communicates with other elements/components within the management station 100 over a system bus 104 .
- An input device 106 for example, a keyboard or mouse, is used to input data from a user of the system 100 , and a display 108 is used to output data to the user.
- a network interface 112 is used to interface the management station 100 to a network 118 in order to allow the management station 100 to act as a node on a network 118 .
- a disk 114 may be used to store the software of the discovery layout software 101 of the present invention, as well as to store the databases (topology and map) generated by the discovery layout software 101 .
- a printer 116 can be used to provide a hard copy output of the nodes of the network 118 discovered by the discovery/layout software 101 .
- a main memory 110 within the management station 100 contains the discovery/layout software 101 .
- the discovery/layout software 101 communicates with a conventional operating system 122 and conventional network software 124 to discover the nodes on the network 118 .
- the network software 124 serves as the intelligence, including validation, for the data communication protocols. As shown in FIG. 1, in the preferred embodiment, the network software implements the IP, the TCP and UDP over the IP, and the SNMP over the UDP. All of the foregoing protocols are well known in the art.
- the discovery/layout software 101 implements object-oriented functionality.
- object-oriented means that most of the management system actions and processes that the user can invoke are oriented toward a class of devices rather than individually managed network nodes.
- the discovery/layout software 101 of FIG. 1 is configured to discover the network topology, that is, all network node interconnections existing on the network 118 , and to construct a map, comprising various sub-maps, any of which can be used for displaying the network topology on the display 108 .
- Connector evaluation software 120 may also reside within the main memory 110 .
- a layer 3 connector is defined as a component functioning as a router, i.e., a device that routes data between two or more IP sub-networks (subnets).
- a layer 2 (data link layer) connector is defined as a bridging or switching device which operates within an IP subnet.
- the connector evaluation software 120 is sometimes referred to as a connector evaluation mechanism. As described in greater detail below, the connector evaluation software 120 causes the management station 100 to communicate with specific connectors within the network 118 . The communication causes the connectors to transmit operational parameters back to the management station 100 .
- the connector evaluation software 120 compares the operational parameters of the connectors to preselected values or specifications. If the operational parameters exceed the preselected specifications, an indication of an error is provided.
- the indication may include the specific connector that is operating improperly in addition to the parameter and its value that is causing the connector to operate improperly.
- FIG. 2 shows a map 200 which is generated by the discovery/layout software 101 from topology data discovered from the network 118 .
- the discovery/layout software 101 can drive any of the various sub-maps to the display 108 (FIG. 1) for viewing by the user.
- the sub-maps in the map 200 of FIG. 2 are arranged in a hierarchy.
- a root sub-map 202 is defined at a root level.
- the root sub-map 202 represents the highest logical level sub-map in the hierarchy and shows objects 203 as anchor points for different sub-map hierarchies.
- Each hierarchy is a separate management domain. This could be, for instance, a network, logical grouping of nodes, or some other domain.
- An Internet sub-map 204 is defined at an Internet level and is generated by exploding an object 203 within the root sub-map 202 . “Exploding” in the context in this document means that the user prompts the management station 100 with the input device 106 to breakdown and provide more data pertaining to the object 203 at issue. Further, the Internet sub-map 204 illustrates objects 203 in the form of networks and routers. Any one of a number of network sub-maps 206 can be exploded from the Internet sub-map 204 . Each network sub-map 206 shows objects 203 in the form of segments and connectors. Any one of a number of segment sub-maps 208 can be exploded from an object 203 within a network sub-map.
- Each segment sub-map 208 shows objects in the form of network nodes.
- any one of a number of node sub-maps 210 can be exploded from an object 203 within a segment sub-map 208 .
- Each node sub-map 210 shows objects 203 in the form of interfaces within that node.
- FIG. 3 A high level block diagram of the discovery/layout software 101 (FIG. 1) is set forth in FIG. 3 according to a preferred embodiment.
- the architecture of the discovery/layout software 101 in FIG. 3 is substantially similar to the architecture of Hewlett-Packard's well known and commercially available management software package called OpenView.
- the discovery/layout software 101 comprises a discovery mechanism 302 for discovering nodes and interconnections of the network 118 and a layout mechanism 304 for receiving topology data from the discovery mechanism 302 and for generating the map 200 (FIG. 2) for driving the display 108 .
- one or more integrating applications 332 may communicate display and map information with the layout mechanism 304 .
- the discovery mechanism 302 has a network monitor 306 connected to the network 118 as indicated by connections 308 a , 308 b , a topology manager 310 connected to the network monitor 306 , as indicated by arrows 312 a , 312 b , and a topology database in communication with the topology manager 310 as indicated by arrow 316 .
- the probable path mechanism 103 is implemented by or computed within the topology manager 310 , as described in detail hereinafter.
- the network monitor 306 transmits and receives data packets to and from the network 118 .
- the network monitor 306 discovers and monitors network topology, as indicated by arrows 308 a , 308 b .
- the network monitor 306 When network topology changes on the network, the network monitor 306 generates events, or “traps” (SNMP vernacular), which include an object identifier and object change information.
- the network monitor 306 can also receive events from other devices, such as a router, in the network 118 .
- the network monitor 306 interacts with the network 118 by way of the network software 124 (FIG.
- the topology manger 310 in addition to managing the probable path system and methodology of the present invention, manages the topology database 314 , as indicated by bi-directional arrow 316 .
- the topology manager 310 prompts the network monitor 306 to update topology data related to particular events, as indicated by arrow 312 a , and receives topology updates, as indicated by 312 b.
- the topology database 314 stores topology data based upon objects, which are used to partition the network for logical reasons.
- Objects include, for example, but are not limited to, networks, routers, segments, connectors, nodes, computers, repeaters, bridges, switches, hubs, etc.
- the topology data stored with respect to the objects includes, for example, but are not limited to, an interface or device address, an interface or device type, an interface or device manufacturer, and whether an interface or device supports the SNMP.
- the layout mechanism 304 has a topology-to-map translator 318 in communication with the topology manger 310 as indicated my arrows 320 a , 320 b , a graphical user interface (GUI) 322 in communication with the topology-to-map translator 318 as indicated by arrows 324 a , 324 b , and a map database 326 in communication with the GUI 322 as indicated by bi-directional arrow 328 .
- the integrating application 332 communicates information with the GUI 322 , as indicated by arrows 333 a , 333 b.
- the network monitor 306 , the topology manager 310 , the translator 318 , the GUI 322 take turns utilizing the combination of the operating system 122 (FIG. 1) and the processor 102 (FIG. 1) in order to accomplish their respective functions.
- the translator 318 converts topology data from the topology database 314 to map data and constructs the various sub maps 202 through 210 in the map 200 of FIG. 2.
- the translator 318 can forward a request to the topology manager 310 , as indicated by arrow 320 a , in order to obtain topology data regarding particular objects.
- the topology manager 310 advises the translator 318 , as indicated by the arrow 320 b , when topology data has changed based upon an event so that the translator 318 can make any appropriate changes in these submaps.
- the GUI 322 manages the map database 326 as indicated by the bi-directional arrow 328 , and manages the display 108 and input device 106 , as indicated by the arrows 330 a , 330 b .
- the GUI 322 receives map updates from the translator 318 , as indicated by arrow 324 b , and submits user-triggered events to the translator 318 , as indicated by arrow 324 a .
- a user-triggered event includes a prompt 330 a from a user to explode an object, as described relative to FIG. 2.
- FIG. 4 depicts the functionality of a preferred implementation of the probable path mechanism 103 (FIG. 3) and associated methodology of the present invention.
- each block of this flowchart, as well as other flowcharts depicted herein represents a module segment or portion of code which comprises one or more executable instructions for implementing the specified logical function or functions.
- the functions noted in the various blocks may occur out of the order depicted in the flowchart(s). For example, two blocks shown in succession in FIG. 4 may, in fact, be executed substantially concurrently where the blocks may sometimes be executed in the reverse order depending upon the functionality involved.
- the preferred functionality depicted may be construed as beginning at block 410 where information corresponding to a start node and an end node of interest may be received. Proceeding then to block 412 , information corresponding to a particular path-type of interest may be received. For example, such information may correspond to whether a user is inquiring as to the shortest path and/or all paths between the start node and the end node. Proceeding to block 414 , information corresponding to the type(s) of connectors of interest with respect to a given path(s) is received. In particular, such information may correspond to whether layer 2 and layer 3 connectors or, alternatively, only layer 3 connectors are of interest. Thereafter, such as depicted in block 416 , the probable path or paths may be determined.
- Link a connection between an interface on one node and an interface on another node.
- “Path” a conceptual series of links that connect two nodes, e.g., the first interface is on the starting node and the last interface is on the ending node.
- Hop a node that serves as the endpoint for a link in the path.
- Hop count the number of hops traversed in path, e.g., the first link in a path will have a hop count of zero.
- Shortest path a path that traverses the fewest number of hops between the starting node and the ending node.
- the present invention may facilitate the determination of probable paths between nodes in a network and may describe the determined path(s) in reference to various types of connectors. More specifically, embodiments of the present invention may define a path as comprising layer 2 and layer 3 connectors or, alternatively, only layer 3 connectors.
- a layer 3 (IP layer) connector is defined as a component functioning as a router, i.e., a device that routes data between two or more IP sub-networks (subnets).
- a layer 2 (data link layer) connector is defined as a bridging or switching device which operates within an IP subnet.
- FIG. 5 depicts the functionality of a preferred embodiment of the present invention.
- the functionality represented may be construed as beginning at block 510 where the start node is determined. Determination of the start node may be based upon a designation of a start node by a user. Proceeding to block 512 , a determination is made as to what networks communicate with the starting node. Then, as depicted in block 514 , each network communicating with the starting node is then evaluated to determine whether the end node, which also may be designated by the user, is associated therewith.
- one or more process refinements may be employed. For example, if one of the networks is determined to be an IPX network, that network may be discarded, e.g., appropriately marked so as not to be later utilized during the path determination process. Additionally, if a network has previously been visited, further processing of that network may be avoided, such as by marking that network as “visited.”
- a gateway is a level 3 connector.
- identification of a gateway(s) of a network only is facilitated if the network has not been previously visited and is not an IPX network.
- a network associated with the gateway also may be identified, such as depicted in block 518 . Steps 514 - 518 then may be recursively repeated until one or more paths between the start node and the end node are determined.
- the path may be saved in memory (depicted in block 520 ).
- each determined path may be saved in memory.
- the user inquired as to the shortest path between the start node and the end node preferably, only the shortest path currently identified by the system during processing is saved in memory. More specifically, if a current shortest path has been previously stored in memory, only information corresponding to a later determined shortest path need be saved in memory, such as by replacing the previous current shortest path. By so doing, an efficient allocation of memory may be achieved.
- FIG. 6 depicts the functionality of a preferred embodiment of the present invention.
- the functionality represented may be construed as beginning at block 610 where the start node is determined. Proceeding to block 612 , a determination is made as to what segment(s) communicate with the start node. Then, as depicted in block 614 , each segment communicating with the start node is then evaluated to determine whether the end node is associated therewith. As described hereinbefore (in regard to the flowchart of FIG. 5), efficiency of the path determination process may be enhanced by one or more process refinements, e.g., disregarding nodes associated with an IPX network, among others.
- the process may proceed to block 616 where identification of connector(s) and/or gateway(s) associated with the identified segments is facilitated—a gateway is a level 3 connector. Then, as depicted in block 618 , segments associated with the newly identified connector(s) and/or gateway(s) may be evaluated. Steps 614 - 618 may be recursively repeated until one or more paths between the start node and the end node are determined. It should be noted that, when transitioning from one segment to another segment during processing, a segment which belongs to another network is not utilized unless the connector associated with that segment is a gateway. This is because level 2 connectors connect segments within a particular subnet and only gateways connect different subnets. Conversely, transitioning between a segment of one network or subnet and a segment of another network or subnet only occurs at a gateway.
- the path may be saved in memory (depicted in block 620 ).
- each determined path may be saved in memory.
- the user inquired as to the shortest path between the start node and the end node preferably, only the shortest path currently identified by the system during processing is saved in memory, such as described hereinbefore in relation to the flowchart of FIG. 5.
- the connectors within the paths may be monitored to assure that they are functioning properly. By first determining a probable path or paths between nodes of interest, only the connectors along the probable paths need to be monitored. This reduces the time and resources required for monitoring a network because only specific connectors need to be monitored.
- FIG. 7 This process of monitoring the connectors is illustrated by the flowchart of FIG. 7, which begins in a manner similar to the functionality depicted in the flowchart of FIG. 4.
- the preferred functionality depicted may be construed as beginning at block 710 where information corresponding to a start node and an end node of interest may be received as was described above. Proceeding then to block 712 , information corresponding to a particular path-type of interest may be received. For example, such information may correspond to whether a user is inquiring as to the shortest path and/or all paths between the start node and the end node. Proceeding to block 714 , information corresponding to the type(s) of connectors of interest with respect to a given path(s) is received. In particular, such information may correspond to whether layer 2 and layer 3 connectors or, alternatively, only layer 3 connectors are of interest. Thereafter, such as depicted in block 716 , the probable path or paths may be determined.
- a connector in the path is identified as depicted in block 718 .
- information relating to an operating parameter is received from the connector.
- the level two and level three connectors in the network 118 may have the ability to communicate with the management station 100 .
- the network 118 may use the SNMP, which provides for communications between the management station 100 and the connectors.
- the level two and level three connectors may store operational parameters locally.
- the operational parameters may, as a non-limiting example, be stored within the connectors in the form of conventional management information bases (MIBs).
- the MIBs may include such parameters as the traffic passing through the connector, the disc space available on the connector, and any errors in the operation of the connector that have been detected by self diagnostics.
- the values of the above-described parameters are then transmitted or otherwise sent to the management station 100 .
- the connector evaluation software 120 receives the values of the connector parameters and compares them to preselected values or specifications as is depicted in block 722 . Should a value of a connector parameter exceed a preselected value or specification, as depicted in block 724 , an alarm or other indication may be provided to notify a network administrator or the like of the problem as is depicted in block 726 .
- the connector evaluation software 120 may continually operate in order to find errors before they become significant. For example, the connector evaluation software 120 may periodically retrieve the above-described connector parameters from the connectors for evaluation. Accordingly, the connector evaluation software 120 may continually evaluate the status of the connectors by continually comparing the connector parameters to the above-described connector values.
- the above-described specifications within the connector evaluation software 120 may be established by various methods. In one embodiment, a probable path is found as described above. A user may then view the connectors located within the path and set the parameter specifications for each of the connectors. In another embodiment, the parameter specifications may be set for each type of device in the path.
- the parameter specifications are preestablished for each of the different connectors that may be located in the path.
- a specific type or model of connector may have specific parameter specifications associated therewith. This allows for ease in establishing the parameters specifications by simply associating the specifications with the type of connector that is found to be in the path.
- Another method for establishing the parameter specifications is to select them based on the operational history of the network as is described in the U.S. patent application Ser. No. 09/915,070 of Loyd filed on Jul. 25, 2001 for METHOD AND DEVICE FOR MONITORING THE PERFORMANCE OF A NETWORK (attorney docket number 10006615-1), which is hereby incorporated by reference for all that is disclosed therein.
Abstract
Description
- This application is a Continuation-in-Part of U.S. application, Ser. No. 09/694,843 filed on Oct. 23, 2000, which is hereby incorporated by reference for all that is disclosed therein.
- The present invention generally relates to data communication networks and, more particularly, to systems and methods for determining the operational status of devices along a probable network path or paths between two nodes in a network topology.
- A data communications network generally includes a group of devices, such as computers, repeaters, bridges, switches, routers, etc., situated at network nodes and a collection of communication channels for interconnecting the various nodes. Hardware and software associated with the network and, particularly, the devices permit the devices to exchange data electronically via the communication channels.
- The size of networks varies. A local area network (LAN) is a network of devices in close proximity, typically less then one mile, and usually connected by a single cable, for instance, a coaxial cable. A wide area network (WAN) is a network of devices which are separated by longer distances, often connected by, for example, telephone lines or satellite links. In fact, some WANs span the U.S. as well as the world. Furthermore, many of these networks are widely available for use by the public, including universities and commercial industries.
- A very popular industry standard protocol for data communication along the networks is the Internet Protocol (IP). In time, the Transmission Control Protocol (TCP) and the Unreliable Datagram Protocol (UDP) were developed for use with the IP. The former protocol (TCP/IP) is a protocol which guarantees transfer of data without errors, as it implements certain check functionality, and the latter protocol (UDP/IP) is a protocol which does not guarantee transfer of data, but requires must less overhead than the TCP/IP platform. Furthermore, in order to keep track of and manage the various devices situated on a network, the simple network management protocol (SNMP) was eventually developed for use with the UDP/IP platform. The use of the foregoing protocols has become extensive in the industry, and numerous venders manufacture many types of networks devices which can employ these protocols.
- Many management software packages (“management platforms”) are presently available for implementing “management stations” on a network and particularly in connection with the SNMP. Examples of commercially available SNMP management software packages include OpenView from the Hewlett-Packard Company, NetView/6000 from IBM Corp., Spectrum from Cabletron Systems, Inc., Netlabs/Manager from Netlabs, Inc., and SunNet Manager from Sun Connect, Inc. The nodes on a network and their interconnections, oftentimes referred to as a network “topology,” are best displayed in a graphical format and most, if not all, of the available management packages provide for this feature. Typically, with these packages, a network can be viewed from different vantage points, depending on the scope of the view desired. For example, one view of the network could be a very wide encompassing view of all nodes on the entire network. A second view could be a view of those portions of a network within a local range, for example, within a particular site or building. A third view of a network, often called a segment, could be a view of the nodes attached to a particular LAN cable.
- Hewlett-Packard's very successful OpenView has been the subject of several patents, including, for instance, U.S. Pat. No. 5,185,860, issued to J. C. Wu on Feb. 9, 1993, and U.S. Pat. No. 5,276,789, issued to Besaw et al. on Jan. 4,1994, the disclosures of which are incorporated herein by reference for all that is disclosed therein. U.S. Pat. No. 5,185,860 describes an automatic discovery system for a management station for determining the network devices and interconnections of a network, or the topology. U.S. Pat. No. 5,276,789 describes a graphic display system for a management station for graphically displaying the topology of a network and provides for various views, including, Internet, segment, and node views, that can be requested by a user.
- When utilizing a management station, such as a station implemented by Hewlett-Packard's OpenView, a user may consider it beneficial to be able to predict the probable path or paths between two nodes in a network. Additionally, it may be beneficial to be able to determine the status of data transfer or other network devices situated at the network nodes along the probable path or paths. However, heretofore, the ability to determine the probable path or paths between two nodes has not been addressed by available management platforms. Likewise, the ability to determine the status of network devices along the probable path or paths has not been addressed.
- Therefore there is a need for improved systems and methods which address these and other shortcomings of the prior art.
- Briefly stated, the present invention relates to determining the status of and continually monitoring network devices along a probable network path or paths between two nodes in a network topology. In this regard, embodiments of the present invention may be construed as providing systems for determining paths between a start node and an end node of a communication network. Typically, such a communication network is formed of sub-networks, with each of the sub-networks including one or more connectors and one or more segments. More specifically, the segments interconnect various ones of the connectors, with the start node, which corresponds to one of the connectors, being designated at one end of the path, and the end node, which corresponds to another of the connectors, being designated at the other end of the path. When the connectors are identified, their statuses are continually monitored.
- In a preferred embodiment of the present invention, the system includes a processor, a discovery mechanism, a layout mechanism, and a connector evaluation mechanism. The discovery mechanism is configured to generate and store topology data specifying connectors and segments of a communication network. The layout mechanism, which interfaces with the discovery mechanism, is configured to receive topology data from the discovery mechanism and drive a display based upon the topology data. Additionally, the discovery mechanism is configured to determine a path between a start node and an end node based upon the topology data. For instance, such a path(s) may be based upon information corresponding to a type of path of interest and/or information corresponding to a type of connector of interest. The connector evaluation mechanism is configured to receive parameter values from the connectors along the path representative of their operational status and compare the parameter values to preselected values or specifications. If a connector parameter exceeds a preselected specification, an event is generated signaling an error with the connector.
- Some embodiments of the present invention may be construed as providing methods for determining the status of paths between a start node and an end node of a communication network. In this regard, a preferred method includes the steps of: receiving information corresponding to the start node and the end node; receiving information corresponding to a type of path of interest; receiving information corresponding to a type of connector of interest; determining a path between the start node and the end node based upon the type of path of interest and the type of connector of interest; identifying at least one connector in the path; receiving data representative of an operating parameter from the at least one connector; comparing the data to a predetermined value; and providing an indication if the data exceeds the predetermined value.
- Other embodiments of the present invention may be construed as providing computer readable media for facilitating a determination of paths between a start node and an end node of a communication network. In this regard, a preferred computer readable medium includes: logic configured to receive information corresponding to the start node and the end node; logic configured to receive information corresponding to a type of path of interest; logic configured to receive information corresponding to a type of connector of interest; logic configured to determine a path between the start node and the end node based upon the type of path of interest and the type of connector of interest; logic configured to receive a parameter value from a connector in the path; logic configured to compare the parameter value to a preselected value; and logic configured to generate an event if the parameter value exceeds the preselected value.
- Other features and advantages of the present invention will become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such features and advantages be included herein within the scope of the present invention, as defined in the appended claims.
- The invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.
- FIG. 1 is a block diagram of a management station including discovery/layout software which employs a preferred embodiment of the system and method of the present invention.
- FIG. 2 is a schematic diagram illustrating a display map, which comprises a collection of sub-maps, any of which can be displayed on the display of the management station by the discovery/layout software of FIG. 1.
- FIG. 3 is a block diagram of the discovery/layout software implementing a preferred embodiment of the present invention.
- FIG. 4 is a flowchart depicting functionality of a preferred embodiment of the present invention.
- FIG. 5 is a flowchart depicting functionality of a preferred embodiment of the present invention.
- FIG. 6 is a flowchart depicting functionality of a preferred embodiment of the present invention.
- FIG. 7 is a flowchart depicting functionality of a preferred embodiment of the present invention.
- Referring now to the drawings wherein like numerals indicate corresponding parts throughout the several views, FIG. 1 shows a block diagram of an object-oriented
management station 100 which is implemented with a general purpose computer system containing novel discovery/layout software 101, which employs aprobable path mechanism 103 and associated methodology of the present invention. As shown in FIG. 1, themanagement system 100 contains aprocessor 102. Theprocessor 102 communicates with other elements/components within themanagement station 100 over asystem bus 104. Aninput device 106, for example, a keyboard or mouse, is used to input data from a user of thesystem 100, and adisplay 108 is used to output data to the user. Anetwork interface 112 is used to interface themanagement station 100 to anetwork 118 in order to allow themanagement station 100 to act as a node on anetwork 118. Adisk 114, for example, may be used to store the software of thediscovery layout software 101 of the present invention, as well as to store the databases (topology and map) generated by thediscovery layout software 101. Aprinter 116 can be used to provide a hard copy output of the nodes of thenetwork 118 discovered by the discovery/layout software 101. Amain memory 110 within themanagement station 100 contains the discovery/layout software 101. The discovery/layout software 101 communicates with aconventional operating system 122 andconventional network software 124 to discover the nodes on thenetwork 118. Thenetwork software 124 serves as the intelligence, including validation, for the data communication protocols. As shown in FIG. 1, in the preferred embodiment, the network software implements the IP, the TCP and UDP over the IP, and the SNMP over the UDP. All of the foregoing protocols are well known in the art. - The discovery/
layout software 101 implements object-oriented functionality. In the context of SNMP managers, object-oriented means that most of the management system actions and processes that the user can invoke are oriented toward a class of devices rather than individually managed network nodes. Generally, the discovery/layout software 101 of FIG. 1 is configured to discover the network topology, that is, all network node interconnections existing on thenetwork 118, and to construct a map, comprising various sub-maps, any of which can be used for displaying the network topology on thedisplay 108. -
Connector evaluation software 120 may also reside within themain memory 110. Two types of connectors are primarily described herein, a layer 3 connector and a layer 2 connector. As utilized herein, a layer 3 (IP layer) connector is defined as a component functioning as a router, i.e., a device that routes data between two or more IP sub-networks (subnets). Additionally, a layer 2 (data link layer) connector is defined as a bridging or switching device which operates within an IP subnet. Theconnector evaluation software 120 is sometimes referred to as a connector evaluation mechanism. As described in greater detail below, theconnector evaluation software 120 causes themanagement station 100 to communicate with specific connectors within thenetwork 118. The communication causes the connectors to transmit operational parameters back to themanagement station 100. Theconnector evaluation software 120 then compares the operational parameters of the connectors to preselected values or specifications. If the operational parameters exceed the preselected specifications, an indication of an error is provided. The indication may include the specific connector that is operating improperly in addition to the parameter and its value that is causing the connector to operate improperly. - FIG. 2 shows a
map 200 which is generated by the discovery/layout software 101 from topology data discovered from thenetwork 118. The discovery/layout software 101 can drive any of the various sub-maps to the display 108 (FIG. 1) for viewing by the user. The sub-maps in themap 200 of FIG. 2 are arranged in a hierarchy. Aroot sub-map 202 is defined at a root level. Theroot sub-map 202 represents the highest logical level sub-map in the hierarchy and shows objects 203 as anchor points for different sub-map hierarchies. Each hierarchy is a separate management domain. This could be, for instance, a network, logical grouping of nodes, or some other domain. AnInternet sub-map 204 is defined at an Internet level and is generated by exploding an object 203 within theroot sub-map 202. “Exploding” in the context in this document means that the user prompts themanagement station 100 with theinput device 106 to breakdown and provide more data pertaining to the object 203 at issue. Further, theInternet sub-map 204 illustrates objects 203 in the form of networks and routers. Any one of a number ofnetwork sub-maps 206 can be exploded from theInternet sub-map 204. Eachnetwork sub-map 206 shows objects 203 in the form of segments and connectors. Any one of a number ofsegment sub-maps 208 can be exploded from an object 203 within a network sub-map. Eachsegment sub-map 208 shows objects in the form of network nodes. Finally, any one of a number ofnode sub-maps 210 can be exploded from an object 203 within asegment sub-map 208. Eachnode sub-map 210 shows objects 203 in the form of interfaces within that node. - A high level block diagram of the discovery/layout software101 (FIG. 1) is set forth in FIG. 3 according to a preferred embodiment. With the exception of the
probable path mechanism 103, the architecture of the discovery/layout software 101 in FIG. 3 is substantially similar to the architecture of Hewlett-Packard's well known and commercially available management software package called OpenView. As shown in FIG. 3, at a general architecture level, the discovery/layout software 101 comprises adiscovery mechanism 302 for discovering nodes and interconnections of thenetwork 118 and alayout mechanism 304 for receiving topology data from thediscovery mechanism 302 and for generating the map 200 (FIG. 2) for driving thedisplay 108. Moreover, one or more integratingapplications 332 may communicate display and map information with thelayout mechanism 304. - The
discovery mechanism 302 has anetwork monitor 306 connected to thenetwork 118 as indicated byconnections topology manager 310 connected to thenetwork monitor 306, as indicated byarrows topology manager 310 as indicated byarrow 316. In a preferred embodiment, theprobable path mechanism 103 is implemented by or computed within thetopology manager 310, as described in detail hereinafter. - The network monitor306 transmits and receives data packets to and from the
network 118. The network monitor 306 discovers and monitors network topology, as indicated byarrows network monitor 306 generates events, or “traps” (SNMP vernacular), which include an object identifier and object change information. The network monitor 306 can also receive events from other devices, such as a router, in thenetwork 118. The network monitor 306 interacts with thenetwork 118 by way of the network software 124 (FIG. 1), which essentially comprises protocol stacks, corresponding to IP, TCP, UDP, SNMP in the preferred embodiment, and which generally implements these protocols and performs validation functions. Furthermore, thenetwork monitor 306 populates thetopology database 314 by way of thetopology manager 310 and notifies the topology manager 31 of events (topology changes). Finally, it should be noted that U.S. Pat. No. 5,185,860, issued to J. C. Wu, which is incorporated herein by reference, describes a node discovery system which could be employed to implement the network monitor 306 herein. - The
topology manger 310, in addition to managing the probable path system and methodology of the present invention, manages thetopology database 314, as indicated bybi-directional arrow 316. Thetopology manager 310 prompts the network monitor 306 to update topology data related to particular events, as indicated byarrow 312 a, and receives topology updates, as indicated by 312 b. - The
topology database 314 stores topology data based upon objects, which are used to partition the network for logical reasons. Objects include, for example, but are not limited to, networks, routers, segments, connectors, nodes, computers, repeaters, bridges, switches, hubs, etc. Moreover, the topology data stored with respect to the objects includes, for example, but are not limited to, an interface or device address, an interface or device type, an interface or device manufacturer, and whether an interface or device supports the SNMP. - The
layout mechanism 304 has a topology-to-map translator 318 in communication with thetopology manger 310 as indicated myarrows map translator 318 as indicated byarrows 324 a, 324 b, and amap database 326 in communication with theGUI 322 as indicated bybi-directional arrow 328. The integratingapplication 332 communicates information with theGUI 322, as indicated byarrows - It should be noted that the
network monitor 306, thetopology manager 310, thetranslator 318, theGUI 322 take turns utilizing the combination of the operating system 122 (FIG. 1) and the processor 102 (FIG. 1) in order to accomplish their respective functions. - The
translator 318 converts topology data from thetopology database 314 to map data and constructs thevarious sub maps 202 through 210 in themap 200 of FIG. 2. Thetranslator 318 can forward a request to thetopology manager 310, as indicated byarrow 320 a, in order to obtain topology data regarding particular objects. Moreover, in addition to forwarding topology data to thetranslator 318 upon request, thetopology manager 310 advises thetranslator 318, as indicated by thearrow 320 b, when topology data has changed based upon an event so that thetranslator 318 can make any appropriate changes in these submaps. - The
GUI 322 manages themap database 326 as indicated by thebi-directional arrow 328, and manages thedisplay 108 andinput device 106, as indicated by thearrows GUI 322 receives map updates from thetranslator 318, as indicated byarrow 324 b, and submits user-triggered events to thetranslator 318, as indicated by arrow 324 a. A user-triggered event includes a prompt 330 a from a user to explode an object, as described relative to FIG. 2. Finally, it should be noted that U.S. Pat. No. 5,276,789, issued to Besaw et al., which is incorporated herein by reference, describes a graphical user interface which could by employed to implement theGUI 322 herein. - Reference will now be made to the flowchart of FIG. 4 which depicts the functionality of a preferred implementation of the probable path mechanism103 (FIG. 3) and associated methodology of the present invention. In this regard, each block of this flowchart, as well as other flowcharts depicted herein, represents a module segment or portion of code which comprises one or more executable instructions for implementing the specified logical function or functions. It should also be noted that, in some alternative implementations, the functions noted in the various blocks may occur out of the order depicted in the flowchart(s). For example, two blocks shown in succession in FIG. 4 may, in fact, be executed substantially concurrently where the blocks may sometimes be executed in the reverse order depending upon the functionality involved.
- As shown in FIG. 4, the preferred functionality depicted may be construed as beginning at
block 410 where information corresponding to a start node and an end node of interest may be received. Proceeding then to block 412, information corresponding to a particular path-type of interest may be received. For example, such information may correspond to whether a user is inquiring as to the shortest path and/or all paths between the start node and the end node. Proceeding to block 414, information corresponding to the type(s) of connectors of interest with respect to a given path(s) is received. In particular, such information may correspond to whether layer 2 and layer 3 connectors or, alternatively, only layer 3 connectors are of interest. Thereafter, such as depicted inblock 416, the probable path or paths may be determined. - The following definitions are provided for facilitating a more clear understanding of the functionality implemented in the preferred embodiment of the present invention.
- “Link”—a connection between an interface on one node and an interface on another node.
- “Path”—a conceptual series of links that connect two nodes, e.g., the first interface is on the starting node and the last interface is on the ending node.
- “Hop”—a node that serves as the endpoint for a link in the path.
- “Hop count”—the number of hops traversed in path, e.g., the first link in a path will have a hop count of zero.
- “Shortest path”—a path that traverses the fewest number of hops between the starting node and the ending node.
- As mentioned hereinbefore, the present invention may facilitate the determination of probable paths between nodes in a network and may describe the determined path(s) in reference to various types of connectors. More specifically, embodiments of the present invention may define a path as comprising layer2 and layer 3 connectors or, alternatively, only layer 3 connectors. As utilized herein, a layer 3 (IP layer) connector is defined as a component functioning as a router, i.e., a device that routes data between two or more IP sub-networks (subnets). Additionally, a layer 2 (data link layer) connector is defined as a bridging or switching device which operates within an IP subnet. Thus, when a user requests a probable path determination based upon level 3 connectors only, only connectors operating at level 3 of the network protocol stack will be utilized during path determination. Likewise, when the user requests a probable path determination based upon level 2 connectors and level 3 connectors, connectors operating at both level 2 and level 3 of the network protocol stack will be considered during path determination.
- In regard to determining a path or paths that include only level3 connectors, reference will now be made to the flowchart depicted in FIG. 5 which depicts the functionality of a preferred embodiment of the present invention. As shown in FIG. 5, the functionality represented may be construed as beginning at
block 510 where the start node is determined. Determination of the start node may be based upon a designation of a start node by a user. Proceeding to block 512, a determination is made as to what networks communicate with the starting node. Then, as depicted inblock 514, each network communicating with the starting node is then evaluated to determine whether the end node, which also may be designated by the user, is associated therewith. In order to promote efficiency during the path determination process, one or more process refinements may be employed. For example, if one of the networks is determined to be an IPX network, that network may be discarded, e.g., appropriately marked so as not to be later utilized during the path determination process. Additionally, if a network has previously been visited, further processing of that network may be avoided, such as by marking that network as “visited.” - If it was previously determined, such as in
block 514, that the end node is not associated with any of the currently identified networks, the process may proceed to block 516 where identification of a gateway(s) of the identified networks is facilitated. As utilized herein, a gateway is a level 3 connector. For those embodiments incorporating the aforementioned process refinements, it may be assumed that identification of a gateway(s) of a network only is facilitated if the network has not been previously visited and is not an IPX network Thus, when a gateway is identified, a network associated with the gateway also may be identified, such as depicted inblock 518. Steps 514-518 then may be recursively repeated until one or more paths between the start node and the end node are determined. - When a path between the start node and the end node has been determined during processing, the path may be saved in memory (depicted in block520). Thus, if a user inquired as to all probable paths between the start node and the end node, each determined path may be saved in memory. Alternatively, if the user inquired as to the shortest path between the start node and the end node, preferably, only the shortest path currently identified by the system during processing is saved in memory. More specifically, if a current shortest path has been previously stored in memory, only information corresponding to a later determined shortest path need be saved in memory, such as by replacing the previous current shortest path. By so doing, an efficient allocation of memory may be achieved.
- For ease of description and not for the purpose of limitation, the following segments of pseudo code are provided as representative examples for implementing the above-described functionality. ComputePaths (currentPath, enteringViaNetwork, startingNode, endingNode, hopCount, currentShortestHopCount, allPaths0rShortestPath, outputPathList, failedIfsList, loopedOrNot, loopedNodesList, currentpathNodesList)
{ If (allPathsOrShortestPath == SHORTEST-PATH && currentShortestHopCount <= hopCount) return FALSE add the startingNode to the currentPathNodesList // Useful during loop checking Create a currentLink with dummy starting and ending interfaces Append this link to the outputPath Mark startingNode as visited Increment hopCount by 1 Get all the interfaces on this node For every interface on this node { if this interface is marked “not to be searched from” continue get the network to which this interface belongs if the network is marked visited then continue if transitioning to an IPX network then continue mark this network as visited Set this interface as the starting interface of the currentLink Check if any of the endingNode's interfaces is on this network If yes then { Set that interface as the ending interface of the current link If all paths were requested then Add this path to the outputPathList If total number of paths has reached a maximum break Else Replace the current shortest path with this one on the outputPathList } else { for every gateway known as currentGateway connected to this network { If gateway is same as the startingNode then Continue If gateway is marked visited then { Add this gateway to the loopedNodesList if not already present in that list Continue } get the interface of the gateway connected to this network set that as the ending interface of the current link // Make the recursive call to ComputeLevel3OnlyPaths from the next // gateway node call ComputeLevel3OnlyPaths( ...) where... represents all the required parameters If allPathsOrShortestPath is ALL PATHS then If maximum paths have been obtained then Break } } Clear the visited flag on this network If allPathsOrShortestPath is ALL PATHS then If maximum paths have been obtained then Break Else If a shortest path was found Break If we did not loop and nor did our descendant from this node and if we did not find a path then Mark this interface of the node as “not to be searched from” in the future Add this interface to the failedlfsList //This list is used to clear this flag in the future on this interface } Remove the last link from the currentPath Clear the visited flag on the startingNode Remove this node from the currentPathNodesList } - In contrast to the determination of paths utilizing only level3 connectors, the determination of paths that include both level 2 and level 3 connectors is facilitated at the segment level (in contrast to the network level determination previously described). In this regard, reference will now be made to the flowchart of FIG. 6 which depicts the functionality of a preferred embodiment of the present invention. As shown in FIG. 6, the functionality represented may be construed as beginning at
block 610 where the start node is determined. Proceeding to block 612, a determination is made as to what segment(s) communicate with the start node. Then, as depicted inblock 614, each segment communicating with the start node is then evaluated to determine whether the end node is associated therewith. As described hereinbefore (in regard to the flowchart of FIG. 5), efficiency of the path determination process may be enhanced by one or more process refinements, e.g., disregarding nodes associated with an IPX network, among others. - If it was previously determined, such as in
block 614, that the end node is not associated with any of the currently identified segments, the process may proceed to block 616 where identification of connector(s) and/or gateway(s) associated with the identified segments is facilitated—a gateway is a level 3 connector. Then, as depicted inblock 618, segments associated with the newly identified connector(s) and/or gateway(s) may be evaluated. Steps 614-618 may be recursively repeated until one or more paths between the start node and the end node are determined. It should be noted that, when transitioning from one segment to another segment during processing, a segment which belongs to another network is not utilized unless the connector associated with that segment is a gateway. This is because level 2 connectors connect segments within a particular subnet and only gateways connect different subnets. Conversely, transitioning between a segment of one network or subnet and a segment of another network or subnet only occurs at a gateway. - When a path between the start node and the end node has been determined during processing, the path may be saved in memory (depicted in block620). Thus, if a user inquired as to all probable paths between the start node and the end node, each determined path may be saved in memory. Alternatively, if the user inquired as to the shortest path between the start node and the end node, preferably, only the shortest path currently identified by the system during processing is saved in memory, such as described hereinbefore in relation to the flowchart of FIG. 5.
- In regard to the computation of paths (paths designated by both layer2 and layer 3 connectors) the following representative pseudo code is provided for ease of description and not for the purpose of limitation.
- ComputePaths (currentPath, enteringViaNetwork, startingNode, endingNode, hopCount, currentShortestHopCount, allPaths0rShortestPath, outputPathList, failedIfsList, loopedOrNot, loopedNodesList, currentPathNodesList)
{ If (allPathsOrShortestPath == SHORTEST-PATH && currentShortestHopCount <= hopCount) return FALSE add the startingNode to the currentPathNodesList // Useful during loop checking Create a currentLink with dummy starting and ending interfaces Append this link to the outputPath Mark startingNode as visited Increment hopCount by 1 Get all the interfaces on this node For every interface on this node { if this interface is marked “not to be searched from” continue get the segment to which this interface belongs if the segment is marked visited then continue if transitioning to an IPX network then continue if startingNode is not a gateway and if the network to which this interface belongs is different from the entering ViaNet then continue // Can not transition to another network unless device is a gateway mark the current network as visited mark the current segment as visited Set this interface as the starting interface of the currentLink Check if any of the endingNode's interfaces is on this segment If yes then { Set that interface as the ending interface of the current link If all paths were requested then Add this path to the outputPathList If total number of paths has reached a maximum break Else Replace the current shortest path with this one on the outputPathList } else { for every connector known as connector connected to this network { If connector is same as the startingNode then Continue If connector is marked visited then } Mark that we looped here Add connector to the loopedNodesList if not already present in that list Continue } get the interface of the connector connected to this network set that as the ending interface of the current link // Make the recursive call to ComputePaths from the next // gateway node call ComputePaths(...) where ... represents all the required parameters If allPathsOrShortestPath is ALL-PATHS then If maximum paths have been obtained then Break } } Clear the visited flag on this segment If startingNode is a gateway then, Clear the visited flag on this network If allPathsOrShortestPath is ALL-PATHS then If maximum paths have been obtained then Break Else If a shortest path was found Break If we did not loop and nor did our descendant from this node and if we did not find a path then Mark this interface of the node as “not to be searched from” in the future Add this interface to the failedlfsList //This list is used to clear this flag in the future on this interface } Remove the last link from the currentPath Clear the visited flag on the startingNode Remove this node from the currentPathNodesList } - When the paths and connectors have been identified as described above, the connectors within the paths may be monitored to assure that they are functioning properly. By first determining a probable path or paths between nodes of interest, only the connectors along the probable paths need to be monitored. This reduces the time and resources required for monitoring a network because only specific connectors need to be monitored.
- This process of monitoring the connectors is illustrated by the flowchart of FIG. 7, which begins in a manner similar to the functionality depicted in the flowchart of FIG. 4. As shown in FIG. 7, the preferred functionality depicted may be construed as beginning at
block 710 where information corresponding to a start node and an end node of interest may be received as was described above. Proceeding then to block 712, information corresponding to a particular path-type of interest may be received. For example, such information may correspond to whether a user is inquiring as to the shortest path and/or all paths between the start node and the end node. Proceeding to block 714, information corresponding to the type(s) of connectors of interest with respect to a given path(s) is received. In particular, such information may correspond to whether layer 2 and layer 3 connectors or, alternatively, only layer 3 connectors are of interest. Thereafter, such as depicted inblock 716, the probable path or paths may be determined. - When the probable path or paths have been determined, a connector in the path is identified as depicted in
block 718. Proceeding to block 720, information relating to an operating parameter is received from the connector. With additional reference to FIG. 1, the level two and level three connectors in thenetwork 118 may have the ability to communicate with themanagement station 100. For example, thenetwork 118 may use the SNMP, which provides for communications between themanagement station 100 and the connectors. In addition, the level two and level three connectors may store operational parameters locally. The operational parameters may, as a non-limiting example, be stored within the connectors in the form of conventional management information bases (MIBs). The MIBs may include such parameters as the traffic passing through the connector, the disc space available on the connector, and any errors in the operation of the connector that have been detected by self diagnostics. - The values of the above-described parameters are then transmitted or otherwise sent to the
management station 100. Theconnector evaluation software 120 receives the values of the connector parameters and compares them to preselected values or specifications as is depicted inblock 722. Should a value of a connector parameter exceed a preselected value or specification, as depicted inblock 724, an alarm or other indication may be provided to notify a network administrator or the like of the problem as is depicted inblock 726. Theconnector evaluation software 120 may continually operate in order to find errors before they become significant. For example, theconnector evaluation software 120 may periodically retrieve the above-described connector parameters from the connectors for evaluation. Accordingly, theconnector evaluation software 120 may continually evaluate the status of the connectors by continually comparing the connector parameters to the above-described connector values. - The above-described specifications within the
connector evaluation software 120 may be established by various methods. In one embodiment, a probable path is found as described above. A user may then view the connectors located within the path and set the parameter specifications for each of the connectors. In another embodiment, the parameter specifications may be set for each type of device in the path. - In another embodiment, the parameter specifications are preestablished for each of the different connectors that may be located in the path. For example, a specific type or model of connector may have specific parameter specifications associated therewith. This allows for ease in establishing the parameters specifications by simply associating the specifications with the type of connector that is found to be in the path. Another method for establishing the parameter specifications is to select them based on the operational history of the network as is described in the U.S. patent application Ser. No. 09/915,070 of Loyd filed on Jul. 25, 2001 for METHOD AND DEVICE FOR MONITORING THE PERFORMANCE OF A NETWORK (attorney docket number 10006615-1), which is hereby incorporated by reference for all that is disclosed therein.
- The foregoing description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Modifications or variations are possible in light of the above teachings. The embodiment or embodiments discussed, however, were chosen and described to provide the best illustration of the principles of the invention and its practical application to thereby enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. All such modifications and variations are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly and legally entitled.
Claims (29)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/032,970 US20020091857A1 (en) | 2000-10-23 | 2001-10-25 | System and method for determining network status along specific paths between nodes in a network topology |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/694,843 US7003559B1 (en) | 2000-10-23 | 2000-10-23 | System and method for determining probable network paths between nodes in a network topology |
US10/032,970 US20020091857A1 (en) | 2000-10-23 | 2001-10-25 | System and method for determining network status along specific paths between nodes in a network topology |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/694,843 Continuation-In-Part US7003559B1 (en) | 2000-10-23 | 2000-10-23 | System and method for determining probable network paths between nodes in a network topology |
Publications (1)
Publication Number | Publication Date |
---|---|
US20020091857A1 true US20020091857A1 (en) | 2002-07-11 |
Family
ID=24790482
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/694,843 Expired - Lifetime US7003559B1 (en) | 2000-10-23 | 2000-10-23 | System and method for determining probable network paths between nodes in a network topology |
US10/032,970 Abandoned US20020091857A1 (en) | 2000-10-23 | 2001-10-25 | System and method for determining network status along specific paths between nodes in a network topology |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/694,843 Expired - Lifetime US7003559B1 (en) | 2000-10-23 | 2000-10-23 | System and method for determining probable network paths between nodes in a network topology |
Country Status (2)
Country | Link |
---|---|
US (2) | US7003559B1 (en) |
GB (1) | GB2370720B (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030135644A1 (en) * | 2000-03-31 | 2003-07-17 | Barrett Mark A | Method for determining network paths |
US20040153572A1 (en) * | 2003-01-31 | 2004-08-05 | Walker Anthony Paul Michael | Method of indicating a path in a computer network |
US20060069741A1 (en) * | 2002-11-29 | 2006-03-30 | Morris Stephen B | Route objects in telecommunications networks |
US20060101340A1 (en) * | 2004-11-09 | 2006-05-11 | Sridhar S | System and method for multi-level guided node and topology discovery |
US20070198732A1 (en) * | 2006-02-21 | 2007-08-23 | Microsoft Corporation | Object-oriented discovery framework |
US20080114874A1 (en) * | 2006-11-15 | 2008-05-15 | Cisco Technology, Inc. | Root cause analysis in a communication network |
US7392482B2 (en) * | 2003-12-18 | 2008-06-24 | International Business Machines Corporation | Selection accelerator in topology views |
US8108547B1 (en) * | 2005-02-10 | 2012-01-31 | Oracle America, Inc. | Symbolic links in a distributed system |
US20160308712A1 (en) * | 2015-04-16 | 2016-10-20 | Hewlett-Packard Development Company, L.P. | Business service discovery |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8677016B1 (en) * | 2000-10-16 | 2014-03-18 | Packet Design, Llc | System and method for identifying network topology information |
US6973023B1 (en) * | 2000-12-30 | 2005-12-06 | Cisco Technology, Inc. | Method for routing information over a network employing centralized control |
US7139823B2 (en) * | 2001-08-23 | 2006-11-21 | International Business Machines Corporation | Dynamic intelligent discovery applied to topographic networks |
US20030208572A1 (en) * | 2001-08-31 | 2003-11-06 | Shah Rajesh R. | Mechanism for reporting topology changes to clients in a cluster |
WO2004025465A1 (en) * | 2002-09-12 | 2004-03-25 | Thomson Licensing S.A. | Associating notifications of the status of a data network by use of a topology editor |
ES2240626T3 (en) * | 2002-09-13 | 2005-10-16 | Siemens Aktiengesellschaft | PLANNING SYSTEM FOR A COMMUNICATIONS NETWORK, PROCEDURE FOR GENERATING PLANS FOR THE COMMUNICATIONS NETWORK AND CONTROL PROGRAM FOR A PLANNING SYSTEM FOR THE COMMUNICATIONS NETWORK. |
JP3831696B2 (en) * | 2002-09-20 | 2006-10-11 | 株式会社日立製作所 | Network management apparatus and network management method |
US20040210654A1 (en) * | 2003-04-21 | 2004-10-21 | Hrastar Scott E. | Systems and methods for determining wireless network topology |
US7299426B2 (en) * | 2005-05-26 | 2007-11-20 | International Business Machines Corporation | System and method to improve chip yield, reliability and performance |
US7995474B2 (en) * | 2005-09-13 | 2011-08-09 | International Business Machines Corporation | Grid network throttle and load collector |
US20070118839A1 (en) * | 2005-10-24 | 2007-05-24 | Viktors Berstis | Method and apparatus for grid project modeling language |
US7853948B2 (en) * | 2005-10-24 | 2010-12-14 | International Business Machines Corporation | Method and apparatus for scheduling grid jobs |
US20070271130A1 (en) * | 2006-05-19 | 2007-11-22 | Microsoft Corporation | Flexible scheduling and pricing of multicore computer chips |
US8601025B1 (en) * | 2011-09-28 | 2013-12-03 | Emc Corporation | Techniques using a bidirectional graph for reporting to clients |
US11120346B2 (en) | 2015-11-25 | 2021-09-14 | Systamedic Inc. | Method and descriptors for comparing object-induced information flows in a plurality of interaction networks |
CN111145540B (en) * | 2019-12-18 | 2021-09-03 | 福建工程学院 | Method and system for discovering topological connecting edges of urban road network |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5185860A (en) * | 1990-05-03 | 1993-02-09 | Hewlett-Packard Company | Automatic discovery of network elements |
US5276789A (en) * | 1990-05-14 | 1994-01-04 | Hewlett-Packard Co. | Graphic display of network topology |
US5905711A (en) * | 1996-03-28 | 1999-05-18 | Lucent Technologies Inc. | Method and apparatus for controlling data transfer rates using marking threshold in asynchronous transfer mode networks |
US5926463A (en) * | 1997-10-06 | 1999-07-20 | 3Com Corporation | Method and apparatus for viewing and managing a configuration of a computer network |
US6327677B1 (en) * | 1998-04-27 | 2001-12-04 | Proactive Networks | Method and apparatus for monitoring a network environment |
US6684237B1 (en) * | 1998-10-14 | 2004-01-27 | Cisco Technology, Inc. | Network interface throttling mechanisms and methods |
Family Cites Families (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5049873A (en) | 1988-01-29 | 1991-09-17 | Network Equipment Technologies, Inc. | Communications network state and topology monitor |
US5123098A (en) | 1989-02-28 | 1992-06-16 | Hewlett-Packard Company | Method for executing programs within expanded memory of a computer system using MS or PC DOS |
CA2017974C (en) | 1989-08-07 | 1998-06-16 | Richard Alan Becker | Dynamic graphical analysis of network data |
US5063523A (en) | 1989-11-16 | 1991-11-05 | Racal Data Communications Inc. | Network management system with event rule handling |
GB2243973A (en) | 1990-05-12 | 1991-11-13 | Motorola Inc | Data network interface |
US5317568A (en) | 1991-04-11 | 1994-05-31 | Galileo International Partnership | Method and apparatus for managing and facilitating communications in a distributed hetergeneous network |
US5414812A (en) | 1992-03-27 | 1995-05-09 | International Business Machines Corporation | System for using object-oriented hierarchical representation to implement a configuration database for a layered computer network communications subsystem |
US5233604A (en) | 1992-04-28 | 1993-08-03 | International Business Machines Corporation | Methods and apparatus for optimum path selection in packet transmission networks |
US5491796A (en) | 1992-10-23 | 1996-02-13 | Net Labs, Inc. | Apparatus for remotely managing diverse information network resources |
GB2272311A (en) | 1992-11-10 | 1994-05-11 | Ibm | Call management in a collaborative working network. |
US5706508A (en) | 1993-04-05 | 1998-01-06 | International Business Machines Corporation | System and method for monitoring SNMP tables |
EP0637152A1 (en) | 1993-07-30 | 1995-02-01 | International Business Machines Corporation | Method and apparatus to speed up the path selection in a packet switching network |
EP0648034A1 (en) | 1993-09-08 | 1995-04-12 | ALCATEL BELL Naamloze Vennootschap | Communication network and computer network server and interface modules used therein |
US5455952A (en) | 1993-11-03 | 1995-10-03 | Cardinal Vision, Inc. | Method of computing based on networks of dependent objects |
US5568605A (en) | 1994-01-13 | 1996-10-22 | International Business Machines Corporation | Resolving conflicting topology information |
US5485455A (en) * | 1994-01-28 | 1996-01-16 | Cabletron Systems, Inc. | Network having secure fast packet switching and guaranteed quality of service |
US5509123A (en) | 1994-03-22 | 1996-04-16 | Cabletron Systems, Inc. | Distributed autonomous object architectures for network layer routing |
CA2145921A1 (en) | 1994-05-10 | 1995-11-11 | Vijay Pochampalli Kumar | Method and apparatus for executing a distributed algorithm or service on a simple network management protocol based computer network |
JP3521955B2 (en) | 1994-06-14 | 2004-04-26 | 株式会社日立製作所 | Hierarchical network management system |
US5488715A (en) | 1994-08-01 | 1996-01-30 | At&T Corp. | Process for integrated traffic data management and network surveillance in communications networks |
US5526358A (en) * | 1994-08-19 | 1996-06-11 | Peerlogic, Inc. | Node management in scalable distributed computing enviroment |
US5675741A (en) | 1994-10-25 | 1997-10-07 | Cabletron Systems, Inc. | Method and apparatus for determining a communications path between two nodes in an Internet Protocol (IP) network |
US5689645A (en) | 1994-12-01 | 1997-11-18 | Hewlett-Packard Co. | Persistence specification system and method for producing persistent and transient submaps in a management station for a data communication network |
US5655081A (en) | 1995-03-08 | 1997-08-05 | Bmc Software, Inc. | System for monitoring and managing computer resources and applications across a distributed computing environment using an intelligent autonomous agent architecture |
US6456306B1 (en) * | 1995-06-08 | 2002-09-24 | Nortel Networks Limited | Method and apparatus for displaying health status of network devices |
US5774669A (en) | 1995-07-28 | 1998-06-30 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Scalable hierarchical network management system for displaying network information in three dimensions |
US5758083A (en) | 1995-10-30 | 1998-05-26 | Sun Microsystems, Inc. | Method and system for sharing information between network managers |
US5848243A (en) * | 1995-11-13 | 1998-12-08 | Sun Microsystems, Inc. | Network topology management system through a database of managed network resources including logical topolgies |
JPH09153059A (en) * | 1995-11-30 | 1997-06-10 | Matsushita Electric Ind Co Ltd | History display method |
US5796951A (en) * | 1995-12-22 | 1998-08-18 | Intel Corporation | System for displaying information relating to a computer network including association devices with tasks performable on those devices |
US5910803A (en) * | 1996-08-14 | 1999-06-08 | Novell, Inc. | Network atlas mapping tool |
US6040834A (en) * | 1996-12-31 | 2000-03-21 | Cisco Technology, Inc. | Customizable user interface for network navigation and management |
US6256295B1 (en) * | 1997-09-25 | 2001-07-03 | Nortel Networks Limited | Method and apparatus for determining multiple minimally-overlapping paths between nodes in a network |
US6253240B1 (en) * | 1997-10-31 | 2001-06-26 | International Business Machines Corporation | Method for producing a coherent view of storage network by a storage network manager using data storage device configuration obtained from data storage devices |
GB2332809A (en) * | 1997-12-24 | 1999-06-30 | Northern Telecom Ltd | Least cost routing |
GB2334852A (en) | 1997-12-24 | 1999-09-01 | Northern Telecom Ltd | Automatic connections manager |
US6370119B1 (en) * | 1998-02-27 | 2002-04-09 | Cisco Technology, Inc. | Computing the widest shortest path in high-speed networks |
US6411946B1 (en) * | 1998-08-28 | 2002-06-25 | General Instrument Corporation | Route optimization and traffic management in an ATM network using neural computing |
US6208977B1 (en) * | 1998-12-04 | 2001-03-27 | Apogee Networks, Inc. | Accounting and billing based on network use |
US6377987B1 (en) * | 1999-04-30 | 2002-04-23 | Cisco Technology, Inc. | Mechanism for determining actual physical topology of network based on gathered configuration information representing true neighboring devices |
US6574663B1 (en) * | 1999-08-31 | 2003-06-03 | Intel Corporation | Active topology discovery in active networks |
US6396810B1 (en) * | 1999-09-08 | 2002-05-28 | Metasolv Software, Inc. | System and method for analyzing communication paths in a telecommunications network |
US6639900B1 (en) * | 1999-12-15 | 2003-10-28 | International Business Machines Corporation | Use of generic classifiers to determine physical topology in heterogeneous networking environments |
US6842425B1 (en) * | 2000-02-14 | 2005-01-11 | Lucent Technologies Inc. | Method and apparatus for optimizing routing through network nodes |
GB2361383B (en) * | 2000-04-13 | 2002-10-30 | 3Com Corp | Graphically distinguishing a path between two points on a network |
-
2000
- 2000-10-23 US US09/694,843 patent/US7003559B1/en not_active Expired - Lifetime
-
2001
- 2001-10-17 GB GB0124940A patent/GB2370720B/en not_active Expired - Lifetime
- 2001-10-25 US US10/032,970 patent/US20020091857A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5185860A (en) * | 1990-05-03 | 1993-02-09 | Hewlett-Packard Company | Automatic discovery of network elements |
US5276789A (en) * | 1990-05-14 | 1994-01-04 | Hewlett-Packard Co. | Graphic display of network topology |
US5905711A (en) * | 1996-03-28 | 1999-05-18 | Lucent Technologies Inc. | Method and apparatus for controlling data transfer rates using marking threshold in asynchronous transfer mode networks |
US5926463A (en) * | 1997-10-06 | 1999-07-20 | 3Com Corporation | Method and apparatus for viewing and managing a configuration of a computer network |
US6327677B1 (en) * | 1998-04-27 | 2001-12-04 | Proactive Networks | Method and apparatus for monitoring a network environment |
US6684237B1 (en) * | 1998-10-14 | 2004-01-27 | Cisco Technology, Inc. | Network interface throttling mechanisms and methods |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030135644A1 (en) * | 2000-03-31 | 2003-07-17 | Barrett Mark A | Method for determining network paths |
US20060069741A1 (en) * | 2002-11-29 | 2006-03-30 | Morris Stephen B | Route objects in telecommunications networks |
US20040153572A1 (en) * | 2003-01-31 | 2004-08-05 | Walker Anthony Paul Michael | Method of indicating a path in a computer network |
US8463940B2 (en) * | 2003-01-31 | 2013-06-11 | Hewlett-Packard Development Company, L.P. | Method of indicating a path in a computer network |
US7392482B2 (en) * | 2003-12-18 | 2008-06-24 | International Business Machines Corporation | Selection accelerator in topology views |
US7716587B2 (en) | 2003-12-18 | 2010-05-11 | International Business Machines Corporation | Selection accelerator in topology views |
US20060101340A1 (en) * | 2004-11-09 | 2006-05-11 | Sridhar S | System and method for multi-level guided node and topology discovery |
US7958250B2 (en) * | 2004-11-09 | 2011-06-07 | Sterling Commerce, Inc. | System and method for multi-level guided node and topology discovery |
US8108547B1 (en) * | 2005-02-10 | 2012-01-31 | Oracle America, Inc. | Symbolic links in a distributed system |
US7685303B2 (en) * | 2006-02-21 | 2010-03-23 | Microsoft Corporation | Object-oriented discovery framework |
US20070198732A1 (en) * | 2006-02-21 | 2007-08-23 | Microsoft Corporation | Object-oriented discovery framework |
US20080114874A1 (en) * | 2006-11-15 | 2008-05-15 | Cisco Technology, Inc. | Root cause analysis in a communication network |
US8484336B2 (en) | 2006-11-15 | 2013-07-09 | Cisco Technology, Inc. | Root cause analysis in a communication network |
US20160308712A1 (en) * | 2015-04-16 | 2016-10-20 | Hewlett-Packard Development Company, L.P. | Business service discovery |
US10382566B2 (en) * | 2015-04-16 | 2019-08-13 | Entit Software Llc | Business service discovery |
Also Published As
Publication number | Publication date |
---|---|
GB2370720B (en) | 2005-01-05 |
GB0124940D0 (en) | 2001-12-05 |
US7003559B1 (en) | 2006-02-21 |
GB2370720A (en) | 2002-07-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20020091857A1 (en) | System and method for determining network status along specific paths between nodes in a network topology | |
US5572640A (en) | Batch transfer system and method for high performance graphic display of network topology | |
EP0720329B1 (en) | Persistence specification system and method for high performance on-demand submaps | |
US7200122B2 (en) | Using link state information to discover IP network topology | |
US7069343B2 (en) | Topology discovery by partitioning multiple discovery techniques | |
US7752024B2 (en) | Systems and methods for constructing multi-layer topological models of computer networks | |
KR100793530B1 (en) | Using link state information to discover ip network topology | |
US7158486B2 (en) | Method and system for fast computation of routes under multiple network states with communication continuation | |
US7548540B2 (en) | Dynamic discovery of ISO layer-2 topology | |
US7706300B2 (en) | Method for providing topology awareness information within an IP network | |
US5675741A (en) | Method and apparatus for determining a communications path between two nodes in an Internet Protocol (IP) network | |
US20150271034A1 (en) | System and method for accurately displaying communications traffic information | |
US20050047350A1 (en) | Apparatus and methods for discovery of network elements in a network | |
US20070274227A1 (en) | Network latency analysis packet and method | |
US20050108379A1 (en) | System and methods for simulating traffic generation | |
JP2010515366A (en) | Effective performance monitoring using IPv6 functionality | |
WO2001086844A1 (en) | Systems and methods for constructing multi-layer topological models of computer networks | |
US8392548B1 (en) | Method and apparatus for generating diagnostic information for errors detected in a network management protocol | |
WO2020244550A1 (en) | Path computing method, storage medium, and electronic device | |
US6931441B1 (en) | Method and apparatus for managing a network using link state information | |
US7995497B2 (en) | Spontaneous topology discovery in a multi-node computer system | |
EP1440529B1 (en) | System and method for information object routing in computer networks | |
US20100153551A1 (en) | Method of managing non-ip based sensor network using simple network management protocol | |
CN117176639B (en) | Multi-protocol-based network topology automatic discovery method and device | |
Raspall | Building Nemo, a system to monitor IP routing and traffic paths in real time |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HEWLETT-PACKARD COMPANY, COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CONRAD, JEFFREY R.;NATARAJAN, SRIKANTH;REEL/FRAME:012761/0018 Effective date: 20011025 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:014061/0492 Effective date: 20030926 Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY L.P.,TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:014061/0492 Effective date: 20030926 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |