Delayed Network Topology Recomputation for Multi-Domain Workloads

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Generating and deploying network topologies across multiple workload resource domains is complex and costly due to functional disparities and dynamic changes in computing environments, requiring efficient recomputation strategies to maintain functional equivalence and performance.

Innovation Solution

A topology deployment system that analyzes modifications to deployed network topologies using rules engines and trained machine-learning models to determine when recomputation of the network topology model is necessary, storing pending modifications to minimize overhead and optimize resource usage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If network topology model is recomputed frequently to maintain functional equivalence after modifications, then reliability is improved, but productivity deteriorates due to computational overhead

Engineering Contradiction:
Improvefunctional equivalenceVSAvoidrecomputation frequency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system changes the parameter of recomputation timing from frequent/immediate to delayed/conditional. Modifications are queued and recomputation is triggered only when specific conditions are met (multiple modifications accumulated, threshold reached, or scheduled time), thereby reducing the frequency of expensive recomputation operations while maintaining functional equivalence.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The system performs preliminary actions by accumulating and queueing modifications before triggering recomputation. Instead of immediately recomputing after each modification, the system preliminarily stores modifications in a queue and processes them in batches, reducing the overall computational overhead while ensuring the topology model eventually reflects all necessary changes.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If network topology model is recomputed immediately after each modification, then functional equivalence is maintained, but loss of time increases due to computational overhead

Engineering Contradiction:
Improvefunctional equivalenceVSAvoidrecomputation time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system implements periodic action by scheduling recomputation at intervals rather than immediately after each modification. A delayed recomputation mechanism accumulates modifications and triggers recomputation periodically or when a threshold is reached, reducing the time lost to frequent recomputation operations while still maintaining functional equivalence over time.

Inventive Principle:
Principle #19Periodic action

Solution Approach 2:

The system performs preliminary queuing of modifications before recomputation. By preliminarily storing modifications in a queue and processing them in batches rather than immediately, the system reduces the total time spent on recomputation operations while ensuring the topology model eventually reflects all necessary changes.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If network topology model is not recomputed after modifications, then productivity is improved by avoiding overhead, but reliability deteriorates due to functional equivalence loss

Engineering Contradiction:
Improveoperational efficiencyVSAvoidfunctional equivalence
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system changes the parameter of recomputation from mandatory/immediate to conditional/delayed. By introducing conditions for triggering recomputation (accumulated modifications, thresholds, scheduled times), the system maintains operational efficiency by avoiding unnecessary recomputations while still ensuring functional equivalence is restored when appropriate conditions are met.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The system implements feedback mechanisms to monitor the state of the network topology and determine when recomputation is necessary. By tracking modifications and evaluating conditions (such as accumulation thresholds or scheduled intervals), the system provides feedback on when recomputation should occur, balancing operational efficiency with maintaining functional equivalence.

Inventive Principle:
Principle #23Feedback

4Adaptability or versatility

If network topology spans multiple workload resource domains, then adaptability is improved, but device complexity increases due to management distribution

Engineering Contradiction:
Improvemulti-domain deploymentVSAvoidtopology management
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system applies segmentation by dividing the complex multi-domain topology management into separate components: modification detection, modification queuing, condition evaluation, and recomputation triggering. This segmentation allows each component to handle specific aspects independently, reducing the overall complexity of managing topologies across multiple workload resource domains while maintaining adaptability.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS11283688B2Delayed recomputation of formal network topology models based on modifications to deployed network topologies
Publication Date: 2022.03.22 CISCO TECHNOLOGY INC
  • US11283688B2 patent drawing
  • US11283688B2 patent drawing
  • US11283688B2 patent drawing

AI summary

Techniques are described herein for generating and modifying formal network topology models, and deploying network topologies based on the formal models across multiple workload resource domains. A topology deployment system may receive modification data for a deployed network topology, and analyze the modification data to determine whether the associated formal network topology model is to be recomputed. In some examples, modifications to a deployed network topology that do not impact operational performance or compromise functional equivalence with the underlying logical model, need not trigger a recomputation of the network topology model immediately and could be delayed. Modifications to deployed network topologies that do not trigger recomputations of the formal network topology model may be stored and tracked, so that subsequent recomputations of the model may incorporate the pending modifications.