VPN Tunnel Duplication for Fast Failover Between Peer Sessions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing VPN tunneling protocols like IPSec, SSL, and PPTP/L2TP require complete re-establishment of tunnels upon disruption, leading to significant downtime during transactions due to the transient nature of tunnels and lack of real-time tunnel identification and redirection.
Innovation Solution
Implementing a tunnelling protocol that allows for duplicate data packet transmission over multiple tunnels, with critical data packets being duplicated and sent through different paths, and using keep-alive and routing table packets to maintain tunnel integrity and detect route changes, ensuring rapid re-establishment or redirection of tunnels.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional VPN tunneling protocols (IPSec, SSL, PPTP/L2TP) are used, then encryption and authentication are provided, but the tunnel must be completely re-established upon disruption causing significant downtime
Solution Approach 1:
The patent establishes multiple pre-configured tunnels between peer devices before any disruption occurs. When a tunnel disruption is detected, the system can immediately switch to a pre-established alternative tunnel without needing to re-negotiate or re-authenticate, thereby eliminating the time-consuming re-establishment process and maintaining continuous connectivity.
Solution Approach 2:
The system creates redundant tunnel paths in advance as a buffer against potential disruptions. These backup tunnels remain dormant until needed, providing a safety cushion that allows instant failover when primary tunnel failures occur, thus preventing service interruption and maintaining reliability.
2Reliability
If a tunnel disruption occurs, then security is maintained through existing protocols, but the client cannot provide information to the server for rapid re-establishment
Solution Approach 1:
The patent implements a feedback mechanism where the client device continuously monitors tunnel health and immediately communicates disruption status to the server. This real-time feedback allows the server to detect failures and initiate re-establishment procedures without waiting for timeout periods, significantly improving recovery speed while maintaining security through authenticated communication channels.
Solution Approach 2:
The system introduces a tunnel management component that acts as an intermediary between the client and server during disruption events. This intermediary coordinates the re-establishment process, managing authentication and tunnel configuration updates, which streamlines the recovery procedure and reduces the time required to restore secure connectivity.
3Adaptability or versatility
If tunnel routing changes occur, then network flexibility is improved, but there is no method to advise the local end of the change
Solution Approach 1:
The patent implements a bidirectional feedback mechanism where routing changes detected at one end of the tunnel are immediately communicated to the other end. This ensures both peers have synchronized information about current tunnel routing status, allowing them to adapt their forwarding decisions accordingly and maintain optimal path selection despite network changes.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
An aspect of the invention provides a data network (100) configured to transmit data from a first peer (105). The network comprises a ranking module (155) associated to the first peer, the ranking module configured to measure the data against an importance threshold. A duplication engine (160) is configured, on determining that the data satisfies an importance threshold, to: assemble a first data packet having a first tunnel identifier associated to the first tunnelling session (130), a first primary packet sequence identifier, and a secondary packet sequence identifier; and assemble a second data packet having a second tunnel identifier associated to the second tunnelling session (135), a second primary packet sequence identifier, and the secondary packet sequence identifier. The first peer (105) is configured to: transmit the first data packet from the first peer (105) within the first tunnelling session (130); and transmit the second data packet from the first peer (105) within the second tunnelling session (135).