Automated ASON Domain Merging and Splitting

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current ASON networks lack an efficient and automatic method for merging or splitting routing domains, which is typically done manually and is time-intensive, error-prone, and not standardized by IETF or ITU-T standards.

Innovation Solution

The implementation of a method that automatically merges or splits ASON domains by identifying a new routing controller, notifying nodes, sending old routing topology information, computing a new routing topology, and distributing it to nodes in the merged or split domains, using a network management system to facilitate these processes without disrupting traffic.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Extent of automation

If manual methods are used to split or merge routing domains, then domain reconfiguration can be performed, but the process is time-intensive and error-prone

Engineering Contradiction:
Improveautomation of domain merging/splittingVSAvoidtime required for domain reconfiguration
Core Design Contradiction:
Extent of automationVSLoss of time

Solution Approach 1:

The system enables self-service automation where the network management system automatically performs domain merging and splitting operations without manual intervention. The system identifies domains, computes topology changes, and executes reconfiguration automatically, transforming a manual labor-intensive process into an autonomous self-service operation.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary actions by pre-identifying candidate domains for merging or splitting, pre-computing the impact on network topology, and pre-validating configuration changes before actual reconfiguration occurs. This preliminary analysis phase reduces the time required during actual execution and prevents errors.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If manual reconfiguration is performed one node at a time, then domain structure can be changed, but the process is error-prone and time-intensive

Engineering Contradiction:
Improveaccuracy of domain reconfigurationVSAvoidduration of reconfiguration process
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system merges multiple individual node reconfiguration operations into a single automated domain-level operation. Instead of manually configuring each node sequentially, the system computes the domain topology change once and applies it atomically across all affected nodes, significantly reducing both time and error probability.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The system implements feedback mechanisms by continuously monitoring the reconfiguration process, validating each step against the computed topology, and automatically correcting deviations. This closed-loop control ensures high reliability while maintaining rapid execution speed.

Inventive Principle:
Principle #23Feedback

3Productivity

If automated domain merging/splitting is implemented, then reconfiguration efficiency improves, but system complexity increases

Engineering Contradiction:
Improvespeed of domain reconfigurationVSAvoidcomplexity of reconfiguration system
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The system introduces an intermediary network management system that sits between the operator and the network elements. This intermediary handles the complexity of automated domain merging and splitting by providing a simplified interface to operators while managing the complex computations and coordination required for rapid reconfiguration behind the scenes.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system segments the domain reconfiguration process into distinct modular components: domain identification, topology computation, validation, and execution. Each segment is independently manageable and can be implemented as separate software modules, reducing overall system complexity while enabling high-speed automated operation.

Inventive Principle:
Principle #1Segmentation

4Adaptability or versatility

If domains are reconfigured to optimize network structure, then routing efficiency improves, but traffic disruption may occur

Engineering Contradiction:
Improveflexibility of network topologyVSAvoidtraffic disruption during reconfiguration
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The system employs periodic action by scheduling domain reconfiguration operations during off-peak traffic periods or using periodic traffic engineering techniques to migrate traffic away from affected paths before reconfiguration and restore it afterward. This rhythmic approach to traffic management minimizes disruption while enabling necessary topology changes.

Inventive Principle:
Principle #19Periodic action

Solution Approach 2:

The system provides beforehand cushioning by pre-computing alternative routing paths and pre-establishing traffic engineering policies that cushion against potential disruptions. Before actual reconfiguration occurs, the system prepares backup routes and adjusts traffic distribution to minimize the impact of upcoming topology changes.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

Data Source

PatentUS8572485B2Splitting and merging routing domains
Publication Date: 2013.10.29 CIENA CORP
  • US8572485B2 patent drawing
  • US8572485B2 patent drawing
  • US8572485B2 patent drawing

AI summary

Apparatuses and methods for merging multiple domains into a merged domain and splitting a single domain into multiple domains in an Automatically Switched Optical Network (ASON) are disclosed. For merging, a node in a first domain can be identified to be a new Routing Controller (RC) for the merged domain. A second domain can be identified to be merged with the first domain. Nodes, including old RCs, in the first domain and the second domain are notified of the identity of the new RC in the merged domain. The topology of the old RC's domain is sent to the new RC. The new topology is computed by the new RC from the topology information given by the old RCs. The updated topology is distributed to nodes in the merged domain via the new RC.