Source: http://www.google.com/patents/US7616579?dq=6,910,205
Timestamp: 2015-05-05 06:32:44
Document Index: 611741662

Matched Legal Cases: ['art 100', 'art 100', 'art 100', 'art 600', 'art 600', 'art 600', 'art 900', 'art 900', 'art 900']

Patent US7616579 - Voice over IP analysis system and method - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA path diagnosis method and system for a VoIP network includes obtaining information on VoIP calls from the VoIP network using either Call Data Records (CDRs) or active testing, or both. A VoIP call that has a problem is determined between a source and a destination device on the VoIP network, based...http://www.google.com/patents/US7616579?utm_source=gb-gplus-sharePatent US7616579 - Voice over IP analysis system and methodAdvanced Patent SearchPublication numberUS7616579 B2Publication typeGrantApplication numberUS 11/185,881Publication dateNov 10, 2009Filing dateJul 21, 2005Priority dateJul 21, 2005Fee statusPaidAlso published asUS20070019559, WO2007015818A2, WO2007015818A3Publication number11185881, 185881, US 7616579 B2, US 7616579B2, US-B2-7616579, US7616579 B2, US7616579B2InventorsTerrance C. Slattery, Frank M. PittelliOriginal AssigneeNetcordia, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (9), Referenced by (3), Classifications (23), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetVoice over IP analysis system and method
Cisco Systems' Service Assurance Agent� is a conventional active testing mechanism. In addition to basic network performance data of a simulated call, it provides data on the routers that were traversed in the path between two test nodes. The data is similar to that provided by a Traceroute program. Once the routers in the path are identified by the active testing system, any switches that interconnect the routers can also be identified and the layer-2 connectivity between routers (which are layer-3 devices).
The first embodiment generates a path diagnostics chart by retrieving various data from a network database, including routing tables, ARP tables, and switch forwarding tables, which have been collected over a period of time. The retrieving of this information is preferably performed at periodic intervals, such as every 10 minutes. The routers and switches in the network are periodically queried to provide their relevant network data, and that data is collected in order to create the path diagnostics chart. The generation process does not require direct connection to the network, unlike the active testing that is performed by conventional VoIP analysis tools. That way, information can be collected �off-network� by consultants analyzing data from networks that they can no longer access. Also, missing and/or inconsistent data is dealt with in the creation of a path diagnostics chart, using data from neighboring devices as needed to overcome such data deficiencies.
The path diagnostics chart 100 is capable of showing �Layer 3 Only� paths that include only the routers located along the path, or �Layer 2 and 3� paths that include all routers and all intermediate switches between those routers. The Layer 2 and 3 path can be used to quickly determine all of the managed devices traversed by a path, as well as all of the interfaces and switch ports used. This can significantly reduce the time needed to troubleshoot a wide range of network problems. FIG. 1 shows a Layer 2 and 3 path, with switch swA4 provided between source telephone 110 and router vpn1, router rtr2 provided between router vpn 1 and router ts 1, a VPN path provided between router vpn1 and router ts 1, and a switch sw134 provided between router ts 1 and destination device 120, whereby destination device 120 is a gateway.
In addition to showing the connections between devices along the path and identification information for all devices, interfaces, switch ports and VLANs, the path diagnostics chart 100 can be configured to display the results of all analysis activities performed for such components over a selected time period (e.g., over a particular one hour time interval). The analysis results (or �issues�) show all of the possible problems associated with each of the path components, allowing a network engineer or network administrator to focus on the most likely cause of the problem being investigated. In FIG. 1, a �Route Loop�No Routes Buffers� issue 130 is identified at router rtr2, a �Configuration Differences� issue 140 is identified at router ts 1, �No Loopback Buffers and Configuration Differences� issues 150 are identified at router vpn1, a �Top Changes� issue 160 is identified at switch sw134, and a �Call Errors� issue 170 is identified at source device (telephone) 110. Furthermore, packet discards 180, 185 are identified on the path diagnostics chart 100 between router vpn1 and rtr2.
The gateway field 230 can be used to enter a value as a �hint� to the path diagnostics tool, if it cannot automatically determine a first hop taken from a source IP address. This is most commonly needed when a PC or workstation IP address is specified as the source address and no default gateway can be determined. The user is allowed to leave the gateway field 230 defaulted to 0.0.0.0 initially, whereby if no first hop can be determined, one can then add the required information and regenerate the path diagnostics chart.
Also shown in FIG. 2 is a display area 260 where the user selects either �Layer 3 Only� or �Layer 2 and 3�, to determine the level of detail to be provided on the path diagnostics chart that is to be created. Further, FIG. 2 shows a display area 270 where the user enters a time period (01-05-2005) to be used to show all possible routes that exist during that time period. The time period is also selected in the display area 260. Once all of that information has been entered, the user selects �OK� 280 to save and enter that information, whereby a path diagnostics chart is now created based on the user selections.
When the path diagnostics process has completed, a pop-up window is displayed, containing the path diagnostics chart. The path diagnostic chart is a graphical representation of the results determined by the path diagnostics tool. By default, the path diagnostics chart shows all routers and/or switch-routers along the path from the given source and target IP addresses, which is called a �Layer 3 Only� chart. Such a Layer 3 Only chart is shown as a Path Diagnostics Chart 600 in FIG. 6. In FIG. 6, three routers 610, 620, 630 are included in the Path Diagnostics Chart 600, whereby a source IP address corresponds to the first router 610, and a target IP address corresponds to a router-switch 630. The Path Diagnostics Chart 600 also includes the issues determined for each of those routers 610, 620, 630, whereby the issues are provided as text regions 615, 625, 635 adjacent to each of the routers 610, 620, 630.
Any pair of addresses can be defined as the source and target IP addresses. If those addresses are associated with a given device in the network database, then the path diagnostics tool displays the names of the device (or �unknown�) and the management address for that device. Additionally, an appropriate icon is displayed based on the device type, on the path diagnostics chart. If the device type cannot be determined or no icon exists for the device type, then �???� is displayed for the icon.
Furthermore, each device shown on the path diagnostics chart is preferably color-coded, for ease in reviewing the path diagnostics chart by an operator. For example, �green� indicates that no �device� issues were associated with that device during the given time period, while �red� indicates that at least one issue existed for that device during the given time period. If the device is colored red, then the list of issues associated with that device are preferably shown in a yellow callout adjacent to the device. As seen in FIG. 7, which shows a portion 700 of the path diagnostics chart of FIG. 6, the callout 625 shows abbreviations for the issues, in order to save display space.
FIG. 9 shows a Layer 2 and Layer 3 Path Diagnostics Chart 900, in accordance with the first embodiment of the invention. If the Display Depth choice on the Settings form is set to �Layer 2 and 3�, then the Path Diagnostics Chart that is subsequently generated will include all of the intermediate switches, if any, between each set of routers along the path from source to target. For example, the Layer 2 and 3 version of the previous path shown in FIG. 6 would look like the Path Diagnostics Chart 900 shown in FIG. 9.
In this case, the first hop traversed two intermediate switches, tr3-c-6509-c and B2-dist-6509-1. For each switch shown in FIG. 9, the inbound and outbound interfaces are displayed, including the interface name, speed and trunking status. If the interface is currently trunking, the abbreviation �TR� is provided adjacent to that interface. In FIG. 9, the link between the switches tr3-c-6509-c and B2-dist-6509-1 is not currently trunking.
The switches can be displayed in different colors depending if issues have or have not been identified for them during the specific time period (�green� means no issues, �red� means at least one issue has been identified).
In addition to displaying the switches along the path, the Layer 2 and 3 Path Diagnostics Chart 900 also can graphically depict all VLANs traversed along the path. FIG. 9 shows VLAN 873 provided between router tr3-c-rsm-2 and router B2-dist-rsm-1. The VLAN information includes the ID, name, root bridge and subnet information, if available. If any of this information cannot be determined from the network database, then �???� is displayed for that piece of information. The VLAN information can be implemented as a hyperlink, allowing the user to drill down for more detailed information on the VLAN. When selected, a pop-up display appears, providing more detailed information that is known about the VLAN.
The Path Diagnostic process uses the following heuristic to determine all of the routes possible during the given time period. The process proceeds by �hopping� from one device to another until the destination is reached. Each hop decision is based on the following steps:
1) If the target device was previously reached from the source device, then the information stored in the �hop cache� will be used. 2) If the source and target devices are in the same subnet, then the target itself is used as the next hop 3) If a route table is found for the source device and at least one route entry is found that matches the target device, then the hop(s) defined is(are) used 4) If a configuration file is stored for the source device and a default gateway is defined, then the default gateway will be used as the next hop 5) If there is at least one HSRP router interface in the same subnet as the source device, then the router associated with the lowest HSRP IP address in the subnet is used as the next hop 6) If there is at least one router interface in the same subnet as the source device, then the router associated with the lowest IP address in the subnet is used as the next hop 7) If the user provided a default gateway IP address and it is in the same subnet as the source device, then the user-provided default gateway is used as the next hop A Layer 2 and 3 Path Diagnostic chart attempts to show all of the intermediate switches for each �hop� along the path. That is, for each pair of source and target devices along the path an attempt is made to determine if there are one or more switches between those devices over which any packets transmitted between those devices will traverse. Since it is not always possible to determine such switches (due to insufficient or inaccurate network data) the following heuristic is used:
1) If the source and target devices are �neighbors�, as indicated by the CDP or equivalent data collected for either the source or target devices (or both), then no intermediate switches are displayed 2) The physical address (e.g., MAC) is determined for the source interface corresponding to the route entry previously determined for the hop. If no physical address can be determined, then an error message is displayed indicating such. 3) The physical address (e.g., MAC) is determined for the target interface corresponding to the route entry previously determined for the hop. If no physical address can be determined, then an error message is displayed indicating such.
5) A VLAN can be represented as a �tree� of switches, with a �root bridge� switch at the top, one or more �member� switches below the root bridge, one or more member switches below each of those member switches, etc. (See FIG. 10, which shows an example tree representation having a VLAN root bridge 1010 and a plurality of VLAN members including a source device 1020 and a target device 1030). Steps 1-4 determine the VLAN that contains both the source and target devices as VLAN members.
6) For each VLAN member, the �source port� (the port facing the source device), the �target port� (the port facing the target device) and the �root port� (the port facing the root bridge) are determined. (See FIG. 11, which shows the key port designations for a first VLAN member that corresponds to the source device 1020, and a second VLAN member that corresponds to the target device 1030). 7) All VLAN members that have identical source and target ports are known to be outside of the path between the source and target devices, so they are ignored for subsequent processing. (See FIG. 12, whereby the ignored VLAN members are shown with an �ignore symbol� 1210 provided thereon. In FIG. 12, VLAN members with identical source and target ports are not along path and can be ignored). 8) Of the remaining VLAN members, the member with the lowest root cost is deemed the �lowest common ancestor� of the source and target devices. (See FIG. 13, whereby the lowest common ancestor is the VLAN root bridge 1010 has a root cost equal to zero). 9) All VLAN members, if any, with identical target and root ports are on the �uphill� path 1310 (as seen in FIG. 13) from the source device to the lowest common ancestor. 10) All VLAN members, if any, with identical source and root ports are on the �downhill� path 1320 (as seen in FIG. 13) from the lowest common ancestor to the target device. 11) In the current implementation, Steps 6-10 are performed solely with database commands (e.g., SQL commands), thereby eliminating all custom programming and decreasing the overall processing time of the computation. With one set of SQL commands, an ordered list of intermediate VLAN member switches between the source and target devices is determined. 12) After all intermediate VLAN members have been determined, the physical interfaces used by the source and target devices to connect to the VLAN can be accurately determined, overwriting any virtual interfaces that were initially used to determine the VLAN. Such physical interface information is more valuable for trouble-shooting purposes, but may not otherwise be determined until after the intermediate VLAN members have been determined. The embodiments described above have been set forth herein for the purpose of illustration. This description, however, should not be deemed to be a limitation on the scope of the invention. Various modifications, adaptations, and alternatives may occur to one skilled in the art without departing from the claimed inventive concept. The scope and spirit of the invention are indicated by the following claims.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6598183Jan 4, 2000Jul 22, 2003Cisco Systems, Inc.Software tool for automated diagnosis and resolution of problems of voice, data and VoIP communications networksUS6738353Mar 20, 2002May 18, 2004Sunrise Telecom IncorporatedSystem and method for monitoring a packet networkUS6816464 *Sep 13, 2000Nov 9, 2004Array Telecom CorporationMethod, system, and computer program product for route quality checking and managementUS7120122 *Sep 8, 2000Oct 10, 2006Comdial CorporationSystem and method for diagnostic supervision of internet transmissions with quality of service controlUS20020145979Apr 5, 2001Oct 10, 2002Michael BajQOS testing of a hardware device or a software clientUS20030086425 *Oct 15, 2002May 8, 2003Bearden Mark J.Network traffic generation and monitoring systems and methods for their use in testing frameworks for determining suitability of a network for target applicationsUS20030202462Apr 29, 2002Oct 30, 2003Smith David B.Method and apparatus for fail over protection in a voice over internet communication systemUS20050152339Nov 2, 2004Jul 14, 2005Scott Mark D.Method, system, and computer program product for route quality checking and managementUS20060156086 *Jun 21, 2005Jul 13, 2006Peter FlynnSystem and method for integrating multiple data sources into service-centric computer networking services diagnostic conclusions* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7974219 *Sep 26, 2008Jul 5, 2011Hewlett-Packard Development Company, L.P.Network troubleshooting using path topologyUS8064352 *Nov 30, 2007Nov 22, 2011Huawei Technologies Co., Ltd.Method for implementing online maintenance in communication networkWO2012110817A1Feb 15, 2012Aug 23, 2012Metaswitch Networks LtdSystem and method for monitoring network link quality* Cited by examinerClassifications U.S. Classification370/241, 370/248International ClassificationH04L12/26Cooperative ClassificationH04L43/50, H04L41/5087, H04L43/106, H04L43/087, H04L41/22, H04L43/0852, H04L43/0829, H04L43/065, H04L43/12, H04L41/5003, H04L41/5035, H04L41/0213, H04L12/2697, H04L43/045European ClassificationH04L43/04A, H04L41/50E, H04L43/06B, H04L43/50, H04L41/50M2, H04L12/26TLegal EventsDateCodeEventDescriptionJan 29, 2014ASAssignmentEffective date: 20130531Owner name: INFOBLOX INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NETCORDIA, INC.;REEL/FRAME:032077/0618Mar 7, 2013FPAYFee paymentYear of fee payment: 4Jul 21, 2005ASAssignmentOwner name: NETCORDIA, INC., MARYLANDFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SLATTERY, TERRANCE C.;PITTELLI, FRANK M.;REEL/FRAME:016802/0744Effective date: 20050718RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services