Concurrent OS Component Validation in Disaggregated Networks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for upgrading network routing and switching operating system components require extensive lab testing, which is time-consuming and costly, and do not effectively validate new software or hardware configurations in real-time production networks due to differences in performance across various network topologies.
Innovation Solution
A method to validate new OS components by running them concurrently with existing components in a live production network, comparing functionality and convergence times using a validation template to determine whether to replace the existing components, thereby eliminating the need for lab testing and minimizing network downtime.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If new OS components are tested in lab environments before deployment, then reliability of the upgrade is improved, but loss of time and productivity deteriorate due to months of testing required
Solution Approach 1:
The patent applies preliminary action by deploying the new OS component version alongside the current version in the production network before fully committing to the upgrade. This allows the new version to be pre-tested in the actual production environment with real traffic patterns, eliminating the need for months of separate lab testing while maintaining reliability through gradual validation.
Solution Approach 2:
The patent uses an intermediary approach by introducing a new OS component version as a parallel service that coexists with the current version. The load balancer acts as a mediator, gradually shifting traffic between versions, allowing comparative validation without disrupting production operations or requiring complete system downtime.
2Productivity
If new OS components are deployed directly in production network, then productivity is improved by eliminating lab testing, but reliability deteriorates due to risk of disrupting live network
Solution Approach 1:
The patent applies dynamics by making the system configurable and adaptable during the transition period. The load balancer dynamically adjusts traffic distribution between old and new OS component versions based on performance monitoring and validation results. This allows the system to evolve from 100% old version to 100% new version gradually, maintaining stability while enabling rapid deployment.
Solution Approach 2:
The patent implements beforehand cushioning by maintaining the current OS component version running alongside the new version during the transition. This creates a safety buffer where if the new version proves problematic, traffic can be immediately redirected back to the proven stable version, cushioning against potential disruptions while still enabling fast deployment.
3Adaptability or versatility
If multiple network topologies are supported with same OS version, then adaptability is improved, but manufacturing precision deteriorates as optimal performance cannot be achieved for each topology
Solution Approach 1:
The patent applies local quality by allowing different OS component versions to be deployed to different network devices or different topologies within the same production network. Each topology can be assigned the OS version that performs optimally for its specific requirements, rather than forcing a single version across all diverse network configurations. This enables precise performance optimization for each local topology while maintaining overall network adaptability.
Data Source
AI summary
A network device has a first OS component, a second OS component is added to run concurrently with the first. The first OS component transmits routing information to the second OS component where it is stored in memory. The second OS component registers with a routing infrastructure to receive packets that are routed to the first OS component. A timestamp and a first ID are added to a first instance of a packet and transmitted to the first OS component. The timestamp and a second ID are added to a second instance of the packet and transmitted to the second OS component. First functionality data for the first OS component is transmitted to a controller. Second functionality data for the second OS component is transmitted to the controller. The first and second functionality data are compared to determine whether to replace the first OS component with the second OS component.