Multicast Traceroute Inline Failure Replies for Faster Node Detection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing multicast traceroute methods in wide area networks are time-intensive and inefficient due to the inability to quickly identify failing nodes, leading to network congestion and delayed or failed replies to multicast trace queries.

Innovation Solution

Implementing an inline failure reply mechanism where each router in the network edits the multicast trace query, starts a timer, and sends an acknowledgment message to the previous router, allowing for immediate detection of non-operational nodes and facilitating a retransmission of the query along a different path.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If traditional multicast traceroute methods are used, then the traceroute can be performed, but the process is time-intensive and inefficient due to inability to quickly identify failing nodes

Engineering Contradiction:
Improvetraceroute efficiencyVSAvoidtime to identify failing nodes
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent applies preliminary action by having routers proactively send acknowledgment messages along the multicast trace query path before the complete traceroute process finishes. Each router sends an acknowledgment to its predecessor as it processes the query, enabling early detection of failing nodes without waiting for the entire traceroute to complete, thus reducing the time to identify failures.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements feedback by introducing acknowledgment messages that flow back upstream along the multicast trace query path. Each router provides feedback to its predecessor about whether it successfully received and processed the query, creating a feedback loop that enables rapid identification of where failures occur in the multicast distribution tree.

Inventive Principle:
Principle #23Feedback

2Reliability

If traditional multicast traceroute methods are used, then the network can operate, but network congestion occurs and replies are delayed or failed

Engineering Contradiction:
Improvereply delivery reliabilityVSAvoidnetwork congestion
Core Design Contradiction:
ReliabilityVSObject-generated harmful factors

Solution Approach 1:

The patent applies taking out by extracting the acknowledgment functionality from the traditional wait-for-end response model. Instead of waiting for the complete traceroute to finish before sending any responses, the system extracts intermediate acknowledgment messages that are sent at each hop along the path, removing the bottleneck of centralized response collection and reducing network congestion.

Inventive Principle:
Principle #2Taking out (Extraction)

3Loss of time

If inline failure reply mechanism is implemented, then failing nodes are quickly identified, but the router complexity increases due to timer management and acknowledgment processing

Engineering Contradiction:
Improvetime to detect non-operational nodesVSAvoidrouter processing complexity
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The patent uses preliminary action by having routers pre-configure timers and acknowledgment mechanisms before processing multicast trace queries. Each router is pre-programmed with the logic to start timers, send acknowledgments, and handle failure detection, distributing the complexity across all routers rather than requiring complex centralized control, thus reducing individual router processing burden.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS12355663B2Enhanced multicast traceroute to receive inline failure reply
Publication Date: 2025.07.08 CISCO TECHNOLOGY INC
  • US12355663B2 patent drawing
  • US12355663B2 patent drawing
  • US12355663B2 patent drawing

AI summary

In one embodiment, a method by a router in a multicast network includes receiving a multicast trace query comprising a data packet, editing the multicast trace query to include data corresponding to the data packet, transmitting the edited multicast trace query to a subsequent router, transmitting a first message indicating the edited multicast trace query was transmitted to the subsequent router, and starting a timer for a determined period of time.