ICMP Redirect Message for Overlay Tunnel Traffic Rerouting
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The current Internet Control Message Protocol (ICMP) cannot redirect overlay traffic or tunnel packet transmissions, as it lacks visibility of overlay protocols and tunnel payloads, preventing it from rerouting traffic via a tunnel or facilitating tunnel transport over networks.
Innovation Solution
Enhancements to the ICMP protocol allow routers to redirect traffic via a tunnel by encapsulating packets with new headers, enabling rerouting of overlay traffic to different routers while maintaining other traffic paths, and supporting tunnel properties and encapsulation protocols like VXLAN, MPLS, and UDP.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the current ICMP protocol is used, then the protocol structure remains simple and compatible with existing networks, but it cannot redirect overlay traffic or tunnel packet transmissions due to lack of visibility of overlay protocols and tunnel payloads
Solution Approach 1:
The patent embeds tunnel-specific information (Tunnel Endpoint Address, Tunnel Type, Encapsulation Type) within the existing ICMP Redirect Message structure. This nesting approach allows the ICMP protocol to carry overlay network routing information without fundamentally changing its external structure, enabling it to redirect tunnel traffic while maintaining protocol compatibility.
Solution Approach 2:
The patent segments the routing information into distinct fields within the ICMP message: Tunnel Endpoint Address field for the destination router, Tunnel Type field for identifying the tunnel protocol, and Encapsulation Type field for the overlay protocol. This segmentation allows the ICMP protocol to handle multiple types of tunnel traffic independently while maintaining a unified protocol structure.
2Adaptability or versatility
If the ICMP protocol is enhanced to redirect overlay traffic, then traffic routing flexibility improves, but protocol complexity increases
Solution Approach 1:
The patent makes the ICMP Redirect Message universally applicable to both traditional IP traffic and overlay tunnel traffic by adding optional tunnel information fields. The same ICMP message structure can serve multiple functions: standard IP redirection, VXLAN tunnel redirection, GRE tunnel redirection, and other overlay protocol redirections, eliminating the need for separate protocols for different traffic types.
Solution Approach 2:
The patent applies local quality by making tunnel-related fields optional and context-dependent. The Tunnel Endpoint Address, Tunnel Type, and Encapsulation Type fields are only populated when redirecting overlay traffic, while standard ICMP messages continue to use the traditional structure. This allows different parts of the protocol to have different characteristics based on the traffic type being handled.
3Adaptability or versatility
If ICMP redirect messages include tunnel endpoint addresses and tunnel types, then redirect capability for tunnel traffic improves, but message size and processing complexity increase
Solution Approach 1:
The patent implements partial action by only including tunnel-specific fields (Tunnel Endpoint Address, Tunnel Type, Encapsulation Type) when redirecting overlay tunnel traffic. For standard IP traffic redirection, these fields are omitted, keeping the message size minimal. This selective inclusion of fields based on traffic type optimizes message size while maintaining full redirect capability when needed.
Data Source
AI summary
A first network element (NE) comprises a receiver configured to receive a tunnel redirection request message from a second NE, wherein the tunnel redirection request message is a request to re-route packets to a third NE instead of the second NE, wherein the tunnel redirection request message comprises an address of the third NE and a first destination address, wherein the packets comprise the first destination address. A processor of the NE is coupled to the receiver and configured to add an outer header and an encapsulation header to a first subset of the packets, wherein the outer header comprises the address of the third NE, and wherein the encapsulation header comprises an identifier of an encapsulation protocol supported by the third NE, and a transmitter coupled to the processor and configured to transmit the first subset of the packets to the third NE via an overlay tunnel, and transmit a second subset of packets to the second NE.