Parameterized Routing Policy Configuration for Modular Network Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional routing systems face challenges with large and complex configuration files that require repetitive blocks of code for minor variations, limiting modularity and ease of maintenance, and lack direct access to non-route attribute information like traffic statistics for creating effective routing policies.

Innovation Solution

The introduction of parameterization and hierarchical constructs in routing policy configuration allows for modular reuse of common policy blocks, mathematical functions to modify route attributes, and integration of traffic engineering information, enabling more efficient and flexible policy management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional configuration files are used to specify routing policy, then routing decisions can be made, but the configuration files become very large and complex requiring repetitive blocks of code

Engineering Contradiction:
Improverouting policy enforcementVSAvoidconfiguration file size and complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The configuration is segmented into modular policy blocks that can be independently defined and reused. Each policy block represents a discrete unit of routing logic that can be applied to specific routes or route sets, eliminating the need for repetitive configuration code while maintaining complete routing policy enforcement capability

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Policy blocks are designed to be universal and reusable across multiple routing scenarios. A single policy block can be applied to different routes, route sets, or peer groups through parameters and variables, allowing the same configuration logic to serve multiple functions without repetition

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If conventional configuration files are used, then routing policy can be applied, but varying a single value requires repeating whole blocks of configuration lines

Engineering Contradiction:
Improverouting policy flexibilityVSAvoidconfiguration maintenance effort
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The configuration system uses parameters and variables to allow easy modification of specific values within policy blocks. By defining policies with parameterized values (such as peer identifiers, route sets, and attribute values), administrators can vary single parameters without repeating entire configuration blocks, significantly reducing maintenance effort while preserving policy flexibility

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

Instead of copying and pasting configuration blocks to accommodate variations, the system uses template-based policy definitions where a single master policy block serves as the source. Variations are achieved through parameter substitution rather than physical copying, eliminating the need to maintain multiple copies of similar configuration

Inventive Principle:
Principle #26Copying

3Loss of information

If conventional routing systems are used, then route attributes can be managed, but direct access to non-route attribute information like traffic statistics is inhibited

Engineering Contradiction:
Improveaccess to traffic statisticsVSAvoidsystem architecture
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The system introduces an intermediary mechanism (such as a database or information repository) that bridges route attribute management and non-route attribute information like traffic statistics. This intermediary allows routing policies to access and respond to traffic engineering information without directly complicating the core routing system architecture, enabling informed routing decisions based on network conditions

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS8285874B2Routing systems and methods for implementing routing policy with reduced configuration and new configuration capabilities
Publication Date: 2012.10.09 CISCO TECHNOLOGY INC
  • US8285874B2 patent drawing
  • US8285874B2 patent drawing
  • US8285874B2 patent drawing

AI summary

In some embodiments, a method and routing system parameterize a routing policy and apply the parameterized-routing policy to a route. Parameters are assigned to at least some policy statements of the policy. The parameterized policy may be called with parameters stored in a parameter table. In some embodiments, common blocks of the policy may be identified and assigned parameter sets. A commonized routing policy may be reused within more than one policy.In some embodiments, a method and routing system may evaluate a configuration file to determine relationships between route attributes. The relationships may be expressed in one or more mathematical functions, and when a route is received from a peer, the attributes of the route may be modified based on the mathematical functions.In some embodiments, a router and method for implementing routing policy and traffic engineering are provided. Routing policy may be implemented by performing a policy translation on a policy configuration to generate an internal-policy representation. Attribute-operator pairings of the internal-policy representation may be verified with one or more client dynamic load libraries (DLLs). When the attribute-operator pairings have been verified, the internal-policy representation may be compiled and stored in a system database. A client protocol may be notified that the routing policy has been modified.