Multicast mtrace for Diverse Path Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Mtrace is ineffective in networks with Multicast only Fast Re-Route (MoFRR) or Live-Live deployments, as it struggles to trace and detect multiple multicast routing paths and merge points, leading to difficulties in troubleshooting and ensuring zero loss delivery.
Innovation Solution
Enhancements to mtrace allow for tracing two or more Reverse Path Forwarding (RPF) paths simultaneously, with extended query and response message formats that include augmented response blocks to provide topology and merge point information, enabling delayed and asynchronous responses to handle networks with multiple paths.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If mtrace is used to trace a single IP multicast routing path, then the tracing function is simple and straightforward, but it becomes ineffective in networks with multiple multicast routing paths (MoFRR/Live-Live deployments) and cannot detect multiple paths or merge points
Solution Approach 1:
The patent segments the tracing function by introducing separate augmented response blocks for different path types (primary path, secondary path, merge point information). Each block handles a specific aspect of multi-path tracing, allowing the system to trace multiple paths simultaneously while maintaining organized and manageable message structures.
Solution Approach 2:
The mtrace protocol is enhanced with multi-functionality to handle both single-path and multi-path scenarios. The extended message formats can universally trace any combination of primary and secondary paths, detect merge points, and provide comprehensive topology information, making the protocol adaptable to various network configurations including MoFRR and Live-Live deployments.
2Speed
If mtrace sends immediate response messages, then the response time is fast, but it cannot handle networks with multiple paths where delayed and asynchronous responses are needed
Solution Approach 1:
The patent introduces dynamic response timing where routers can send responses immediately or delay them based on network conditions and path tracing requirements. This dynamic approach allows the system to maintain fast response times when appropriate while also handling delayed asynchronous responses needed for comprehensive multi-path tracing, particularly for detecting merge points and verifying path convergence.
3Ease of operation
If mtrace uses standard query and response message formats, then the protocol is simple and easy to implement, but it lacks the capability to provide detailed topology and merge point information in multi-path networks
Solution Approach 1:
The patent nests augmented response blocks within the standard mtrace message structure. The augmented blocks contain detailed topology information, merge point data, and path identification information, while the overall message format remains compatible with standard mtrace protocols. This nested structure allows comprehensive information gathering while maintaining protocol simplicity and ease of implementation.
Data Source
AI summary
In one embodiment, a network device may receive an mtrace query, where the mtrace query identifies two or more multicast routing paths. The network device may generate two or more mtrace requests using at least a portion of information obtained from the mtrace query such that each of the two or more mtrace requests identifies a different one of the two or more multicast routing paths. The network device may send each of the two or more mtrace requests via a different one of the two or more multicast routing paths. The network device may then receive at least one response including information pertaining to the two or more multicast routing paths.