Pseudowire Status Request Mechanism with Retry Timers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current pseudowire (PW) status mechanisms, as described in RFC6478, do not ensure that receiving nodes actually receive status messages, leading to stale or inaccurate status information, and lack a method for requesting peer PW status updates, particularly during configuration or reboot scenarios, resulting in potential loops in forwarding paths and control plane congestion.
Innovation Solution
Incorporating a message ID and request flag in PW status messages to ensure acknowledgment and enable a request for return status reports, using timers to manage retries and determine peer node status, and extending the PW protocol with parameters like RetryTimer, RequestTimer, and TimeoutMultiplier to handle status requests and refreshes reliably.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If current PW status mechanisms are used, then the system is simple, but status information becomes stale or inaccurate because receiving nodes cannot confirm message receipt
Solution Approach 1:
The patent implements a feedback mechanism where the receiving node sends an acknowledgment message back to the sending node to confirm receipt of status messages. This feedback loop ensures that the sending node can verify whether its status updates were successfully received, preventing stale or inaccurate status information while maintaining protocol manageability through structured acknowledgment exchanges.
Solution Approach 2:
The patent employs preliminary actions by implementing retry timers and request timers that proactively handle potential message delivery failures before they cause status information to become stale. The system pre-configures timeout values and retry mechanisms to ensure status information remains current without requiring complex real-time negotiation protocols.
2Reliability
If no request mechanism for peer PW status updates is implemented, then the protocol remains simple, but loops in forwarding paths and control plane congestion occur during configuration or reboot scenarios
Solution Approach 1:
The patent implements preliminary actions by having nodes send status request messages proactively during configuration or reboot scenarios before forwarding paths are established. This prevents loops and control plane congestion by ensuring both peer nodes have consistent status information beforehand, avoiding the need for complex reactive loop-detection and resolution mechanisms.
Solution Approach 2:
The patent establishes a feedback mechanism where nodes can request peer PW status updates and receive acknowledgments. This feedback loop ensures forwarding path consistency by allowing nodes to verify peer status before establishing forwarding paths, preventing loops while maintaining protocol simplicity through structured request-response exchanges.
3Reliability
If status messages are sent without confirmation mechanism, then message exchange is frequent and simple, but receiving nodes may not actually receive status messages leading to blackholing
Solution Approach 1:
The patent implements a feedback mechanism where receiving nodes send acknowledgment messages to confirm receipt of status messages. This ensures reliable message delivery by allowing sending nodes to verify that their status updates were successfully received, preventing blackholing while maintaining manageable message exchange through structured acknowledgment protocols.
Solution Approach 2:
The patent introduces an intermediary acknowledgment message that mediates between the status message sending and the verification of successful delivery. This intermediary mechanism provides reliable message delivery assurance without requiring complex direct verification protocols, as the acknowledgment serves as a neutral confirmation of receipt.
Data Source
AI summary
Various exemplary embodiments relate to a method for determining peer status in a pseudowire (PW) node, the method including: sending a first PW status request message to a peer node including a PW node local message ID, PW node remote message ID, and request flag; starting a first retry timer; starting a second retry timer when the first retry timer expires and no response to the first PW status request message is received; starting a first request timer when the second retry timer expires and no response to the first PW status request message is received; and starting a third retry timer when the first request timer expires and no response to the first PW status request message is received.