Declarative Automation for Software-Defined Network Deployment
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional tools for software-defined network (SDN) automation differentiate between initial deployment and updates, requiring manual configuration, external programming, and persistent storage, leading to increased complexity and time in deployment and delivery, and are error-prone.
Innovation Solution
A platform and language agnostic intent-based declarative automation module that views deployment as data, captures the current state for validation, and integrates initial deployment and lifecycle management, allowing users to specify the desired end-state in high-level declarations, which are translated and executed automatically, ensuring consistency with business policies and infrastructure constraints.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If conventional tools use manual configuration and imperative models for SDN deployment, then users can control the deployment process in detail, but the complexity and time in deployment and delivery increase significantly
Solution Approach 1:
The system enables self-service deployment by automatically discovering the current SDN state through probes and agents, validating service orders against policies, and executing deployment steps without manual intervention. The declarative model allows the system to self-manage the entire deployment lifecycle from service order receipt to completion, eliminating the need for users to manually configure each component.
Solution Approach 2:
The deployment process is segmented into distinct phases: service order validation, dependency resolution, step generation, and execution. Each phase is handled by dedicated modules that work independently but coordinate through the declarative model, reducing overall complexity by breaking down the monolithic deployment process into manageable, automated segments.
2Reliability
If conventional tools require persistent storage to maintain deployment state, then state can be tracked, but infrastructure complexity and deployment time increase
Solution Approach 1:
The system introduces an intermediary declarative model that acts as a mediator between the service order and the underlying infrastructure. This model captures the desired end state and current state in memory, allowing the system to track deployment state without requiring persistent storage. The intermediary model enables state validation and comparison operations while avoiding the complexity of file systems or databases.
Solution Approach 2:
The patent replaces the mechanical persistent storage system (files or databases) with an in-memory data structure approach. The declarative model maintains deployment state in volatile memory, using software-based state management instead of physical storage infrastructure, thereby reducing infrastructure complexity while maintaining state tracking capability throughout the deployment process.
3Productivity
If conventional tools use imperative models requiring detailed command sequences, then precise control is achieved, but error probability and deployment time increase
Solution Approach 1:
The system inverts the traditional imperative approach by using declarative modeling. Instead of specifying the sequence of commands to reach the desired state, users declare the end state, and the system automatically determines the necessary steps. This inversion reduces errors by eliminating manual command sequencing while maintaining deployment accuracy through automated validation against the declarative model and policy constraints.
Solution Approach 2:
The system implements feedback mechanisms by continuously comparing the current deployment state (discovered through probes and agents) with the desired state defined in the declarative model. This feedback loop enables automated validation at each step, ensuring deployment accuracy while maintaining high speed through systematic error detection and correction without requiring manual verification.
4Adaptability or versatility
If conventional tools differentiate between initial deployment and updates, then each phase can be optimized, but overall process complexity increases
Solution Approach 1:
The declarative model provides a universal framework that handles both initial deployment and updates through the same process. The model captures the desired end state regardless of whether it's a new service or a modification to an existing one, allowing the system to apply the same validation, dependency resolution, and execution mechanisms for all deployment scenarios, thereby reducing process complexity while maintaining flexibility.
Solution Approach 2:
The system dynamically adapts to different deployment scenarios (initial deployment, updates, rollbacks) by interpreting the declarative model and generating appropriate execution steps. The declarative nature allows the same model to represent different states and transitions, enabling the system to handle diverse deployment situations with a single unified process rather than separate rigid procedures.
Data Source
AI summary
Various methods, apparatuses/systems, and media for automatically deploying an SDN are disclosed. A processor implements a declarative model for an SDN deployment and receives, in the declarative model, service order data from a user corresponding to the SDN deployment. The service order data includes high-level declarative statement data specifying a desired end-state of the SDN deployment. The processor translates the high-level declarative statement data into a low-level specification data that includes data corresponding to a topology and how the SDN should be deployed; creates a run-time topology model based on the low-level specification data; determines whether the service order is valid or not by comparing the low-level specification data against predefined policies and infrastructure constraints data corresponding to execution of the SDN deployment; and automatically executes deployment of the SDN based on a determination that the service order is valid in response to the run-time topology model.