The present invention, generally, relates to network communication methods, systems and computer program products and, more particularly, to methods, systems and computer program products for evaluating such computer networks.
Companies are often dependent on mission-critical network applications to stay productive and competitive. To achieve this, information technology (IT) organizations preferably provide reliable application performance on a 24-hour, 7-day-a-week basis. One known approach to network performance testing to aid in this task is described in U.S. Pat. No. 5,881,237 (“the 237 patent”) entitled Methods, Systems and Computer Program Products for Test Scenario Based Communications Network Performance Testing. As described in the U.S. Pat. No. '237 patent, a test scenario simulating actual applications communication traffic on the network is defined. Various performance characteristics are measured while the test is executing. The resultant data may be provided to a console node, coupled to the network, which may also initiate execution of the test scenario by the various endpoint nodes.
One application area of particular interest currently is in the use of a computer network to support voice communications. More particularly, packetized voice communications are now available using data communication networks, such as the Internet and intranets, to support voice communications typically handled in the past over a conventional switched telecommunications network (such as the public switched telephone network (PSTN)). Calls over a data network typically rely on codec hardware and/or software for voice digitization so as to provide the packetized voice communications.
From a network perspective, evaluation for voice communications may differ from conventional data standards, particularly as throughput and/or response time may not be the critical measures. A VoIP phone call generally consists of two flows, one in each direction. Such a call typically does not need much bandwidth. However, the quality of a call (how it sounds) generally depends on three things: the one-way delay from end to end, how many packets are lost and whether that loss is in bursts, and the variation in arrival times, herein referred to as jitter.
In light of these differences, it may be desirable to determine if a network is even capable of supporting VoIP before deployment of such a capability. If the initial evaluation indicates that performance will be unsatisfactory or that existing traffic will be disrupted, it would be helpful to determine what to change in the network architecture to provide an improvement in performance for both VoIP and the existing communications traffic. As the impact of changes to various network components may not be predictable, thus requiring empirical test results, it would also be desirable to provide a repeatable means for iteratively testing a network to isolate the impact of individual changes to the network configuration.
Embodiments of the present invention provide methods, systems and computer program products for evaluating suitability of a network for packetized communications. Devices on the network are identified. A plurality of assessment rules selected to evaluate the suitability of the network are obtained. Configuration data is obtained from the identified devices. The plurality of assessment rules are automatically evaluated using the obtained configuration data to evaluate the suitability of the network. The packetized communications may be packetized voice communications and/or packetized video communications.
In other embodiments, obtaining a plurality of assessment rules includes obtaining a rules data file and validating the obtained rules data file based on a predetermined schema. An error notification is generated when the obtained rules data file is not validated and the obtained rules data file is provided as the plurality of assessment rules when the obtained rules data file is validated. Evaluating the plurality of assessment rules may only be performed if the obtained rules data file is validated.
In further embodiments, the rules data file is an extensible markup language (XML) file and the predetermined schema is an XML schema definition. The assessment rules may be based on device type, device model, device operating system version, device installed memory and/or device installed modules and obtaining configuration data may include obtaining device type, device model, device operating system version, device installed memory and/or device installed modules data from the identified devices. The configuration data may be obtained using a simple network management protocol (SNMP) and/or an application program interface (API) supported by at least one of the identified devices.
In other embodiments, a sort order is determined based on device, result and/or rule and results from evaluating the plurality of assessment rules are reported in a format based on the determined sort order. Determining the sort order may include providing a graphic user interface (GUI) including a sort selection field configured to receive a user designation of the sort order and a results reporting field configured to display the formatted results and receiving a user designation of the sort order from the GUI.
In further embodiments, obtaining a plurality of assessment rules includes determining version information for a current set of assessment rules. An assessment rules source is queried to determine if updates are available for the current set of assessment rules based on the determined version information. Available updates are obtained to obtain the plurality of assessment rules. Obtaining available updates is performed before evaluating the plurality of assessment rules. Identifying devices on the network may include identifying devices not included in the current set of assessment rules and obtaining a plurality of assessment rules may include obtaining available assessment rules for identified devices not included in the current set of assessment rules from the assessment rules source. The assessment rules source may be a rules server and querying the assessment rules source and obtaining available updates may include communicating with the rules server using an internet protocol (IP) communication channel.
In yet other embodiments, the plurality of assessment rules include rules identifying devices with down-level operating system versions, identifying devices with insufficient memory and/or identifying devices without specified installed cards. Evaluating the plurality of assessment rules may be preceded by receiving a request to evaluate the network. Obtaining the plurality of assessment rules may include receiving an identification of a file and importing the identified file as the plurality of assessment rules.
In further embodiments, methods, systems and computer program products for providing assessment rules for evaluating suitability of a network for packetized communications include obtaining a plurality of device type associated assessment rules. A request for a plurality of assessment rules is received from a client device. The received request includes an identification of device types for which assessment rules are requested. Ones of the obtained plurality of device type associated assessment rules are identified that are associated with the device types identified in the received request. The identified ones of the obtained plurality of device type associated assessment rules are automatically provided to the client device responsive to the received request.
In other embodiments, ones of the obtained plurality of device type associated assessment rules have an associated rule identifier and rule version and the received request includes a rule identifier and a version of an assessment rule already available to the requesting client device. Identifying one of the obtained plurality of device type associated assessment rules includes only identifying an assessment rule having an associated rule identifier matching the received rule identifier when the rule version of the respective obtained assessment rule is greater than the version identified in the request for that rule identifier.
In further embodiments, obtaining a plurality of device type associated assessment rules includes obtaining assessment rules from a plurality of device vendors. Updated assessment rules are received from ones of the plurality of device vendors.
In yet other embodiments, systems for evaluating suitability of a network for packetized communications include a device identification module configured to identifying devices on the network. An input module of the systems is configured to obtain a plurality of assessment rules selected to evaluate the suitability of the network. A data acquisition module is configured to obtain configuration data from the identified devices and an evaluation module is configured to evaluate the plurality of assessment rules using the obtained configuration data to evaluate the suitability of the network.
In further embodiments, the input module is configured to obtain a rules data file. The system may further include a validation module configured to validate the obtained rules data file based on a predetermined schema and to generate an error notification when the obtained rules data file is not validated and provide the obtained rules data file as the plurality of assessment rules when the obtained rules data file is validated.
In other embodiments, systems for providing assessment rules for evaluating suitability of a network for packetized communications include an interface module and a rules identification module. The interface module is configured to obtain a plurality of device type associated assessment rules and to receive a request for a plurality of assessment rules from a client device. The received request includes an identification of device types for which assessment rules are requested. The rule identification module is configured to identify ones of the obtained plurality of device type associated assessment rules that are associated with the device types identified in the received request. The interface module is configured to provide the identified ones of the obtained plurality of device type associated assessment rules to the client device responsive to the received request.
While described above in part above with reference to methods, systems and computer program products are also provided in accordance with further embodiments of the present invention.
The invention now will be described more fully hereinafter with reference to the accompanying drawings, in which illustrative embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
As will be appreciated by one of skill in the art, the present invention may be embodied as a method, data processing system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Furthermore, the present invention may take the form of a computer program product on a computer usable storage medium having computer-usable program code means embodied in the medium. Any suitable computer readable medium may be utilized including hard disks, CD-ROMs, optical storage devices, a transmission media such as those supporting the Internet or an intranet, or magnetic storage devices.
Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as Java® or C++. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language or assembly language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the acts specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the acts specified in the flowchart and/or block diagram block or blocks.
Some embodiments of the present invention will now be described with respect to
Referring first to
As will be understood by those having skill in the art, a communications network 12 may include of a plurality of separate linked physical communication networks, which, using a protocol such as the Internet protocol (IP), may appear to be a single seamless communications network to user application programs. For example, as illustrated in
It is further to be understood that, while for illustration purposes in
Console node 20, or other means for controlling evaluation of the network 12, may obtain user input, for example, by keyed input to a computer terminal or through a passive monitor, to determine a desired test. Console node 20, or other control means may further identify devices on the network 12, obtain assessment rules for evaluating the network and evaluate identified devices based on the assessment rules. Console node 20 may initiate execution of network assessment and/or identification of network devices.
As shown in
It will be understood that
As illustrated in the embodiments of
As illustrated in
Additional application programs 354 illustrated in the embodiments of
The configuration data may be obtained from some or all of the devices on the network, for example, routers and switches. This data may be obtained from the network devices, for example, by simple network management protocol (SNMP) polling and/or an application program interface (API) supported by one or more of the network devices.
The data 356 illustrated in the embodiments of
Referring now to
The interface module 367 is configured to obtain a plurality of device type associated assessment rules and to receive a request for a plurality of assessment rules from a client device. For example, the device type associated assessment rules may be obtained from respective manufacturers and/or vendors of the different device types and the requests for assessment rules or updates to assessment rules may be received from an administrator of a network subscribing to services from the system for providing assessment rules illustrated in
The rules identification module 368 is configured to identify ones of the obtained device type associated assessment rules that are associated with the device types identified in the received request. The interface module 367 may be configured to provide the identified ones of the obtained plurality of device type associated assessment rules to the client device responsive to received requests.
The data 356 illustrated for the embodiments of
While the present invention is illustrated, for example, with reference to the device identification module 360 and the other modules discussed above being application programs in
Operations for evaluating suitability of a network for packetized voice communications according to some embodiments of the present invention will now be further described with reference to the flowchart illustrations of
Obtaining assessment rules at block 410 may include obtaining a rules data file that may be an extensible markup language (XML) file. The assessment rules obtained at block 410 may be based, for example, on device type, device model, device operating system version and/or device installed memory. The obtained configuration data at block 420 may similarly include device type, device model, device operating system version and/or device installed memory data obtained from the identified devices. For example, the configuration data may be obtained from network devices using a simple network management protocol (SNMP) and/or an application program interface (API) supported by respective identified devices. It will be understood, however, that other types of configuration data may be obtained from a management information base (MIB) of a network device, such as a router or switch, as will be further described with reference to various examples provided herein may be obtained. The assessment rules may include rules, such as a rule identifying devices with down-level operating system versions, identifying devices with insufficient memory, identifying devices without specified installed cards, identifying devices having a security vulnerability and/or the like.
Methods of evaluating suitability of a network for packetized communications according to further embodiments of the present invention will now be described with reference to the flowchart illustration of
In some embodiments of the present invention not involving automatic updating of assessment rules through a rules server or the like (block 505), an identification of a rules file is received (block 510). The identified file is imported for use as the network assessment rules (block 515).
For some embodiments of the present invention including automated rule updates through a rules server or the like (block 505), version information for a current set of assessment rules is determined (block 520). An assessment rules source, such as a rules server as illustrated in
The obtained assessment rules may be validated based on a predetermined schema (block 540). For example, the assessment rules may be an extensible markup language (XML) rules data file and the predetermined schema may be an XML schema definition. An error notification may be generated when the obtained rules data file is not validated (block 545). For the embodiments in
When the obtained rules data file is validated (block 540), the plurality of assessment rules are automatically evaluated using the obtained configuration data to evaluate the suitability of the network (block 550). It will be understood that obtaining of the configuration data as described with reference to block 420 of
The embodiments illustrated in
Methods for providing assessment rules for evaluating suitability of a network or packetized communications, such as packetized voice communications and/or packetized video communications, according to some embodiments of the present invention will now be described with reference to the flowchart illustration of
Ones of the obtained plurality of device types associated assessment rules from block 600 that are associated with the device types identified in the received request at block 610 are identified (block 620). In some embodiments, identifying operations at block 620 include identifying ones of the device type associated assessment rules obtained at block 600 that include a rule version newer than the version identified in the request received at block 610 for a given rule identifier associated assessment rule. In other words, the rule identifier included in the request may be a unique rule identifier and its associated version number can be matched to a corresponding identified rule obtained at block 600 to determine if an updated, later rule version number version of a given rule is available that has a more recent release version number than the version already available to the requesting client device. For example, a rules server that obtains device type based assessment rules at block 600 may obtain the assessment rules from a plurality of different device vendors and receive updated assessment rules from one or more of the device vendors on a periodic and/or otherwise scheduled basis. The updated version numbers may increase with each update so that a client device that last received assessment rules from the rules server before new updates were provided by device vendors may receive newer versions of the rules responsive to a request. Such a selective provision of new rules may limit the amount of traffic between the client device and the rules server.
Embodiments of the present invention for evaluating suitability of a network may provide many user configurable options for evaluating an existing network. The network may be assessed on an ongoing basis, may be assessed before initial deployment of the desired traffic on the network and/or may be assessed when devices on the network are changed, removed and/or new devices are added. Embodiments of the present invention may provide a user-friendly graphical user interface (GUI) that walks the user through the operations of the present invention as will be discussed with respect to
As illustrated in
As illustrated in the exemplary window of
While each of these operations may be beneficially applied to network analysis, the GUI illustrated in
As shown in
The Report button 725 is located below the analysis operation buttons 705, 730, 710, 715 and 720. The Report button 725 may provide a single interface for user initiated reports based on information from any of the provided assessments. Thus, some embodiments of the present invention may provide a result summary providing a synopsis of the results of the network assessment. The result summary may include, but is not limited to, an indication of overall network suitability and evaluation results as will be described further herein. The summary may be provided in a format, for example, a text format, that may be displayed on a computer screen or printed on a printer and/or photocopier. These result summaries or reports may provide a simplified method of explaining and summarizing the results of a network performance test.
In addition, a results field 925 is shown in the embodiments of
A rule may “fail” because it does not apply to the device being evaluated or because it applies but the device fails to meet a criterion for that device. As such, each property that can be checked by a rule (e.g. vendor, device type, operating system version, etc.) can, in some embodiments, have an attribute specified in the XML rules file that determines whether or not the property is checked for purposes of being flagged as “failed” during an evaluation. For example, a “FilterOn” keyword may added to the XML rules file for a particular property. If the FilterOn keyword is “true,” then this particular property will not cause the entire rule to be classified as failed for the evaluation. By way of more particular example, devices from multiple vendors may be included in a network being evaluated. A user may want to perform certain checks for one vendor device and other checks for another vendor. As such, the user generally will not want the vendor property check to fail, otherwise all of vendor A devices would fail the rules associated with vendor B and vice versa. Specifying FilterOn=true, allows these vendor checks to be filtered so they do not fail.
Another rule checking comparison included in some embodiments is a “Find” comparison operator. The Find comparison may be used to allow a user to search for certain text strings within a property value. For example, some of the installed module property values for a device may have serial numbers in the value. A user may not know or care about a particular serial number, but may want to find certain types of cards. The Find operator may be configured to look for a specific substring within the entire property value string.
As noted above, in some embodiments of the present invention, the rules data file may be an XML file.
As described above, some embodiments of the present invention provide methods, systems and computer programs for automatically applying a rules-based approach to analyzing configuration properties of network devices, such as routers and switches, for a network to be used for packetized communications. The network device information itself may be collected during an initial discovery phase and different configuration properties can be automatically assessed to determine if the devices are ready for packetized communications, for example, VoIP service deployment on the network.
As further described above, an XML schema definition may be provided to give users a framework for creating simple rules and combinations of rules. A user provided XML file may then specify the rules to be applied to each device type and the rules may be chained together using logical operators. Some example scenarios may include identifying devices with down-level operating system (OS) versions or insufficient memory; identifying device models and their OS or memory requirements; and/or identifying devices with certain hardware installed.
Thus, tools may be provided for automatically assessing the readiness of a network by checking each network device to determine if the device is ready for packetized communications, such as VoIP communications, if a network provider wishes to ensure effective traffic performance before introducing such capabilities. The automated approach as provided by various embodiments of the present invention may greatly expedite the preparation and analysis of a network before deployment of such new services over the network.
The rules can be simple or complicated, for example, as simple as checking a single property of a particular device. For example, all routers may be required to be using an OS level greater than 12.0. Other checks could be very complicated, involving multiple properties. For example, checks could be run to determine if all devices with a model of 3640 and OS level 12.0 have a memory greater than at least 64 MB.
In addition, the rules information may be changed and/or updated on a regular basis. The rules update may be user driven and/or may be provided by a rules server or the like that provides a central tracking point for rules update distribution from a plurality of different equipment vendors to make the rules update process even more expeditious for users in assessing and evaluating their networks.
Accordingly, an infrastructure may be provided by some embodiments of the present invention for automatically assessing, using a rules-based approach, any number of configuration properties for a number of devices. Rules files can be modified as rules change or get updated. The rules can be applied automatically to some or all designated devices via a user interface. The user interface may then graphically show which device has passed or failed and the associated rules tested resulting in either pass or fail results.
As described above with respect to
It will be understood that the block diagram of
Accordingly, blocks of the block diagrams of
The foregoing is illustrative of the present invention and is not to be construed as limiting thereof. Although a few exemplary embodiments of this invention have been described, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of this invention. Accordingly, all such modifications are intended to be included within the scope of this invention as defined in the claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents but also equivalent structures. Therefore, it is to be understood that the foregoing is illustrative of the present invention and is not to be construed as limited to the specific embodiments disclosed, and that modifications to the disclosed embodiments, as well as other embodiments, are intended to be included within the scope of the appended claims. The invention is defined by the following claims, with equivalents of the claims to be included therein.