Master-Client Routing Protocol for Rapid Network Failure Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional routing protocols are cumbersome and take too long to detect and reroute traffic around network failures, especially in high-speed communication networks used for mission-critical applications, leading to significant data loss and prolonged recovery times.
Innovation Solution
A routing protocol that employs a master node maintaining a link state database (LSD) with client nodes storing copies, allowing for quick detection and rerouting by sending incremental and full LSD update messages via UDP multicasting, enabling rapid synchronization and recomputation of forwarding tables.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If conventional routing protocols are used, then routing information can be exchanged between nodes, but the detection and rerouting time is too long causing significant data loss
Solution Approach 1:
The patent segments the routing protocol into two distinct roles: master nodes that maintain the complete link state database (LSD) and client nodes that store copies of the LSD. This segmentation allows for more efficient failure detection and rerouting by distributing the routing intelligence across multiple nodes rather than relying on a single centralized protocol process.
Solution Approach 2:
Client nodes perform preliminary actions by maintaining local copies of the link state database and pre-computing forwarding tables. When a failure is detected, these pre-prepared routing information can be immediately activated without waiting for lengthy protocol exchanges, significantly reducing detection and rerouting time while maintaining network reliability.
2Loss of information
If full LSD update messages are sent frequently to ensure synchronization, then client nodes can maintain accurate routing information, but network bandwidth is consumed and message size may exceed UDP packet limits
Solution Approach 1:
Instead of sending complete LSD update messages every time, the patent implements a mechanism where only partial updates (incremental changes) are transmitted when the full message would exceed UDP packet size limits. This partial action approach maintains synchronization accuracy by sending just the necessary portions of routing information while avoiding the overhead of repeatedly transmitting complete datasets, thus reducing overall network message volume.
3Loss of information
If the full LSD update message is large and does not fit in a single UDP packet, then routing information completeness is maintained, but the message cannot be transmitted efficiently and may require deferral
Solution Approach 1:
The patent segments large LSD update messages into multiple smaller UDP packets for transmission. When the complete routing information exceeds a single packet's capacity, it is divided into fragments that can be transmitted efficiently over the network and reassembled at the destination, maintaining information completeness while significantly improving transmission efficiency and avoiding deferral.
4Loss of information
If client nodes perform network discovery to learn topology, then complete network information can be obtained, but the discovery process is time-consuming and adds complexity
Solution Approach 1:
The patent implements preliminary action by having client nodes receive and store network topology information in advance through configuration files during boot-up, rather than performing time-consuming network discovery protocols at runtime. This pre-loaded topology information is then used in conjunction with incremental LSD updates to maintain current routing state, significantly reducing the time required to obtain complete network information while eliminating the complexity of runtime discovery protocols.
Data Source
AI summary
During operation, a client node can receive a network's topology. Next, the client node can detect a change in an interface's state. The client node can then create an interface state change message which indicates the change in the interface's state. Next, the client node can send the interface state change message to the master node, which can cause the master node to notify other client nodes about the change in the interface's state. If a client node's copy of the link state database (LSD) is out of sync with the master node's LSD, the client node can request the master node to send a full LSD update message to the client node. The master node can multicast messages to the client nodes, and each node in the network can include one or more interfaces that are dedicated for sending and receiving control messages, thereby creating a separate control network.