Opnet Technologies, Inc.

Riverbed Technology, Inc.

Edward A Sykes

Gordon Bolt

Alain J Cohen

Yevgeny Gurevich

Bobby Ninan

Scott Glasser

Yu Liu

Michael Ernst

Flush valve cover

Disclosed herein are system, method, and computer program product embodiments for performing distributed correlation to determine a probable cause for a performance problem detected in an application. An embodiment operates by triggering an alert for a performance metric of an application executing on a local-level node. The alert may be sent to a higher-level node. Upon receiving the alert, the higher-level node may send a distributed correlation request, used to determine a root cause of the alert, to the lower-level node. Upon receiving the distributed correlation request, the lower-level node may produce and send a correlation result to the higher-level node. Upon receiving the correlation result, the higher-level node may select the probable cause of triggering the alert based on the correlation result. The probable cause may then be presented to the user.

Large-scale distributed correlation

Traffic flow between each pair of nodes in a network may be modeled based on loads measured at each link and based on gravity measures associated with each node. Gravity measures correspond to a relative likelihood of the node being a source or a sink of traffic. Gravity objectives are assigned to nodes to serve as an objective for a node's performance. These gravity objectives may be based on qualitative characteristics associated with each node. Because the assigned gravity objectives may be subjective, the gravity measures are used to generate a quantitative function for determining whether a network can achieve these gravity objectives. In one embodiment, link loads are allocated to traffic flows between nodes and current gravity measures are determined. Changes to link loads and traffic flows may then be modeled to minimize a difference between the assigned gravity measures and the gravity measures.

Traffic flow inference based on link loads and gravity measures

Traffic flow between each pair of nodes in a network are determined based on loads measured at each link and based on gravity measures. The gravity measures correspond to a likelihood of the node being a source or a sink of traffic and may be assigned based on characteristics associated with each node, such as the demographics of the region in which the node is located, prior sinking and sourcing statistics, and so on. The gravity measures are used to generate an objective function for solving a system of linear equations, rather than as criteria that must be satisfied in the solution. The measured link loads are allocated among the traffic flows between nodes to at least a given allocation efficiency criteria by solving a system of linear equations with an objective of minimizing a difference between the assigned gravities and the resultant gravities corresponding to the determined flows.

Traffic flow between each pair of nodes in a network are determined based on loads measured at each link and based on gravity measures associated with each node. The gravity measures correspond to a relative likelihood of the node being a source or a sink of traffic, and may be assigned based on 'soft' characteristics associated with each node, such as the demographics of the region in which the node is located, prior sinking and sourcing statistics, and so on. Because the assigned gravities are relatively subjective, the gravity measures are used to generate an objective function for solving a system of linear equations, rather than as criteria that must be satisfied in the solution. The measured link loads are allocated among the traffic flows between nodes to at least a given allocation efficiency criteria by solving a system of linear equations with an objective of minimizing a difference between the assigned gravities and the resultant gravities corresponding to the determined flows.

A path-flow formulation of defining MPLS FRR bypass LSPs is presented. The path-flow formulation comprises first identifying a set of candidate bypass LSPs, each of which meets various network constraints and has an explicit route around a network facility to be protected. The constraints may include Quality of Service (QoS) guarantees, implementation requirements, network element resource limitations, and resiliency requirements. The constraints may be user-selected, and may be non-linear. The set of candidate bypass LSPs form a linear programming (LP) problem, or an integer linear programming (ILP) problem if the allowable number of bypass LSPs is constrained. In an optimization step, LP solutions are used to select the bypass LSPs from among the candidate bypass LSPs by allocating bandwidth to them.

Path flow formulation for fast reroute bypass tunnels in MPLS networks

An interactive system and method automates the control and management of routing changes that are focused on specific routes or particular network hot spots. Based on the premise that the user is aware of a particular problem that needs to be solved, the system leads the user through an end-to-end process from the identification of the problem to the generation of configuration instructions for effecting a selected solution. A graphic user interface provides a visualization of the current routing and alternative routings, to facilitate the analysis and selection of an improved routing, if any. Throughout the process, the effect of each proposed routing change on the overall network performance is determined, so that the selection of a preferred solution can be made in the appropriate context, and globally sub-optimal solutions can be avoided.

Interactive MPLS traffic engineering

An existing network configuration is assessed, and potential changes to the existing configuration are identified that provide the greatest incremental improvements to the performance of the network. In a preferred embodiment, the user of the system identifies the maximum number (N) of changes that may be implemented in an existing network, and the system provides a set of possible reconfigurations, each requiring fewer than N changes. The user is presented a display of the potential improvement provided by each set as a function of the number of changes in the set, so that the relative incremental gain can be easily visualized. The objective function of the optimization may include conventional load-balancing objectives, or other objectives, such as a global minimization of path lengths.

Growing community of inventors

Cary, NC, United States of America

Edward A Sykes