NETCONF Sub-Transaction Merging for Concurrent Device Configuration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current network configuration protocols, such as NETCONF, are inefficient in managing multiple configuration changes across network devices, particularly in large-scale network environments like hub-and-spoke VPNs, as they require serial processing of configuration changes, which can lead to bottlenecks and slow down the activation of network services.
Innovation Solution
The introduction of a new form of NETCONF configuration transaction request that allows multiple sub-transactions to be specified in a single message, enabling concurrent commitment of configuration changes and a unified reply message indicating the success or failure of each sub-transaction, along with extensions to the service model for controlling and formatting these sub-transactions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If multiple configuration changes are sent as separate NETCONF requests, then each configuration change can be individually committed, but the total configuration time increases and network resources are overutilized
Solution Approach 1:
The patent combines multiple separate configuration transactions into a single NETCONF request message that contains multiple sub-transactions. Each sub-transaction is identified by a unique sub-transaction identifier and can be individually committed or rolled back, while the entire batch is transmitted in one network message. This merging approach reduces network overhead and total configuration time while maintaining individual transaction reliability through separate commit/rollback capabilities for each sub-transaction.
2Reliability
If multiple configuration changes are sent as separate NETCONF requests, then each configuration change can be individually committed, but network resource utilization increases
Solution Approach 1:
The patent merges multiple configuration transactions into a single network message, reducing the number of network round trips and protocol overhead. The single NETCONF request contains multiple sub-transactions, each with its own commit/rollback capability, allowing individual configuration changes to be reliably applied while minimizing network resource consumption through batched transmission.
3Productivity
If a single NETCONF request contains multiple configuration changes, then configuration time is reduced, but it becomes difficult to track and manage individual sub-transactions
Solution Approach 1:
The patent segments a single configuration request into multiple sub-transactions, each identified by a unique sub-transaction identifier (sub-transaction ID). This segmentation allows the system to process and track individual sub-transactions within the batch, enabling selective commit or rollback of specific sub-transactions while maintaining overall batch processing efficiency. The sub-transaction IDs provide a mechanism to track and manage individual changes without sacrificing the productivity gains of batched processing.
4Ease of operation
If configuration changes are processed serially, then transaction management is simpler, but service activation speed decreases
Solution Approach 1:
The patent combines multiple configuration transactions into a single batched NETCONF request that can be processed concurrently by the network device. The device receives one message containing multiple sub-transactions and processes them in parallel rather than sequentially, significantly improving service activation speed. The sub-transaction identifiers maintain transaction management simplicity by allowing individual tracking and control of each sub-transaction within the concurrent processing framework.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
Techniques are disclosed for managing a network. In one example, a device configuration manager is configured to generate, in accordance with a device management protocol, a configuration change request representing a transaction having a first sub-transaction specifying a first configuration change for a network device of the network and a second sub-transaction specifying a second configuration change for the same network device. The device configuration manager is further configured to output the configuration change request to the network device and receive a reply message from the network device. The reply message includes a first response element specifying whether the first configuration change is successfully committed at the network device and a second response element specifying whether the second configuration change is successfully committed at the network device.