NFV Compute Element Image Upgrade via Active TCP Push
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for managing image upgrades on compute elements in software-defined networks with network function virtualization (NFV) are inefficient, involving lengthy reboots, high latency due to microservice calls, duplicated polling logic across subsystems, potential security risks, IP address changes, and firewall configuration requirements.
Innovation Solution
The compute element initiates a TCP connection with the SDN controller upon reboot, accepting cryptographic and network management protocol connections to receive and respond to status commands, eliminating the need for polling and reducing latency, while ensuring secure communication through authentication and dynamic IP address handling.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the controller polls the compute element to check image installation status, then the controller can verify upgrade completion, but this causes high latency and requires synchronized timeouts and retry mechanisms
Solution Approach 1:
Instead of the controller polling the compute element to check installation status, the compute element proactively pushes status information to the controller. The compute element establishes a TCP connection to the controller and transmits status data, inverting the traditional client-server communication pattern to eliminate polling latency and timeout synchronization requirements.
Solution Approach 2:
The compute element provides feedback about its image installation status to the controller through active TCP connections. The compute element transmits status information including installation completion state, enabling the controller to receive real-time updates without continuous polling, thus reducing latency while maintaining reliable verification.
2Productivity
If the compute element reboots to install the image, then the new image can be activated, but this causes lengthy reboots and potential IP address changes
Solution Approach 1:
The compute element is configured with pre-stored connection information including the controller's IP address and port numbers before the reboot process. This preliminary configuration allows the compute element to immediately establish TCP connections to the correct controller addresses after rebooting, eliminating delays caused by IP address changes or connection establishment time.
3Reliability
If multiple subsystems implement polling logic, then image status can be monitored, but this duplicates logic and increases device complexity
Solution Approach 1:
The patent consolidates image status monitoring functionality into a single centralized mechanism where the compute element pushes status information to the controller. This eliminates the need for multiple subsystems to implement separate polling logic, reducing device complexity while maintaining comprehensive monitoring capability through a unified approach.
4Object-affected harmful factors
If the compute element uses cryptographic protocols for communication, then security is enhanced, but this increases the complexity of connection establishment
Solution Approach 1:
The compute element autonomously performs cryptographic authentication and establishes secure TCP connections to the controller using pre-configured credentials and certificates. The compute element self-manages the cryptographic handshake and status information transmission, eliminating the need for complex centralized authentication mechanisms while maintaining strong security through distributed cryptographic operations.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A network function virtualization (NFV) compute element installs an image supporting a virtualized network function (VNF) on the element. The image includes instructions/data to initiate a TCP connection between the element and a Software Defined Network (SDN) controller upon reboot of the element. Upon rebooting, the element establishes, as client in accordance with the instructions/data, a TCP connection with the controller. The element then accepts, as a cryptographic network protocol server, a connection via the TCP connection from the controller as a client in accordance with the instructions. Next, the element accepts, as a network management protocol server, a connection via the cryptographic network protocol connection from the controller as network management protocol client. The element receives, from the controller over the network management protocol connection, commands regarding the status of the rebooted compute element, and then transmits, to the controller over the network management protocol connection, responses to the commands.