Route Cost Computation Using Path Type Preferences
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing network routing technologies lack the ability to perform traffic engineering and failover in a granular and specific manner, particularly when less desirable paths through preferred data centers are available, leading to inefficient network resource utilization.
Innovation Solution
A computing system computes a cost of a route to a next-hop network device based on route metrics and path preferences, allowing for route advertisements that reflect path type and latency, enabling more precise traffic engineering and failover.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If traditional routing protocols are used that only consider basic metrics, then routing is simple, but traffic engineering precision is insufficient and network resources are not optimized
Solution Approach 1:
The patent changes the parameter set used in routing decisions by introducing path type preferences (e.g., MPLS vs broadband, low-latency paths) as additional dimensions beyond traditional metrics like bandwidth and latency. This allows the routing system to differentiate between multiple paths to the same destination based on their characteristics, enabling precise traffic engineering while maintaining compatibility with existing routing protocols through modified cost computations.
Solution Approach 2:
The patent segments the routing decision process into distinct components: base cost calculation from traditional metrics, path type preference assignment, and combined cost computation. This segmentation allows network administrators to independently configure preferences for different path types (e.g., preferring MPLS over broadband for certain traffic) without affecting the underlying routing protocol or basic metric collection, thus improving control granularity without proportionally increasing system complexity.
2Measurement precision
If path preferences are configured for traffic engineering, then routing precision is improved, but configuration complexity increases
Solution Approach 1:
The patent creates a universal path preference mechanism that can be applied across multiple routing protocols and path types through a unified configuration interface. The same preference framework works for different path types (MPLS, broadband, low-latency) and can be configured at various levels (global defaults, protocol-specific, destination-specific), reducing the learning curve and configuration effort while maintaining high precision in route selection.
Solution Approach 2:
The patent allows administrators to configure path preferences selectively rather than requiring complete configuration for all scenarios. Default preferences provide reasonable baseline behavior, and administrators can override or add specific preferences only where needed, reducing configuration effort while achieving precise traffic engineering for critical paths. The system accepts partial configuration and applies defaults elsewhere, maintaining precision where configured without requiring exhaustive setup.
3Adaptability or versatility
If multiple path types are considered in route cost computation, then traffic engineering capability is enhanced, but routing protocol overhead increases
Solution Approach 1:
The patent extracts the path type preference information from the core routing protocol messages and handles it separately in the cost computation logic. The routing protocol continues to exchange standard metrics (bandwidth, latency, next-hop information), while the path type preferences are configured locally and applied during route selection without requiring additional protocol messages or modifications to the routing protocol specification, thus avoiding increased overhead.
Solution Approach 2:
The patent introduces an intermediary cost computation layer that translates multiple path type preferences and traditional metrics into a single combined route cost. This intermediary layer processes the diverse input parameters (path types, preferences, metrics) and produces a unified cost value that can be directly used by standard routing protocols, enabling enhanced traffic engineering capability without requiring the routing protocol itself to handle multiple parameter types or increase message overhead.
Data Source
AI summary
Techniques are disclosed for computing a cost of an advertised route to a next-hop network device along a path to a destination based at least in part on a preference for the path. In one example, a computing system computes a cost of a route to a next-hop network device along a path to a destination. The computed cost is based at least in part on (1) a metric for the route and (2) a preconfigured preference for the path. In some examples, the preference for the path is based at least in part on (a) a type of the path as compared to other types of other paths to the destination or (b) a latency of the path as compared to other latencies of the other paths. The computing system sends a route advertisement for the route that includes data indicative of the cost of the route.