IPv6 Multicast RPF Checks Using Shorter Routing Identifiers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The reverse path forwarding (RPF) check in an IPv6 network is complex due to the need to compare two 128-bit addresses, leading to increased computational complexity and storage requirements.
Innovation Solution
The RPF check method involves generating and using first and second identifiers, each less than 128 bits, to simplify the comparison process by establishing correspondences based on multicast source and group addresses, and encapsulation information.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional RPF check method is used in IPv6 network, then the RPF check can be performed to ensure multicast packet correctness, but the computational complexity and storage requirements increase due to comparing two 128-bit addresses
Solution Approach 1:
The patent segments the 128-bit IPv6 address comparison task into two separate identifier comparisons: a first identifier (less than 128 bits) extracted from the multicast data packet and a second identifier obtained from the tail node's routing information. This segmentation reduces the computational complexity by breaking down a single complex 128-bit address comparison into two simpler identifier comparisons.
Solution Approach 2:
The patent introduces first and second identifiers as intermediary elements that mediate the RPF check process. Instead of directly comparing two 128-bit IPv6 addresses, the system uses these shorter identifiers as intermediaries to represent and compare the essential routing information, thereby reducing computational burden while maintaining check correctness.
2Reliability
If conventional RPF check method is used in IPv6 network, then the RPF check can be performed to ensure multicast packet correctness, but the storage requirements increase for maintaining 128-bit address information
Solution Approach 1:
The patent extracts essential routing information from the full 128-bit IPv6 addresses and stores it in compressed form as first and second identifiers. The first identifier is extracted from the multicast data packet, and the second identifier is extracted from the tail node's routing information. This extraction process reduces storage requirements by maintaining only the critical identifying elements rather than full address information.
Solution Approach 2:
The patent changes the parameter representation from full 128-bit IPv6 addresses to shorter first and second identifiers. This parameter transformation maintains the essential distinguishing characteristics needed for RPF check correctness while significantly reducing the storage space required to maintain routing information and perform comparisons.
Data Source
Figure 1~2
Figure 3
Figure 4
AI summary
Embodiments of this application disclose an RPF check method. After receiving a multicast data packet from a head node, a tail node may obtain a multicast source address, a multicast group address, and encapsulation information that are carried in the multicast data packet. Then, the tail node obtains, based on the multicast source address, the multicast group address, and a first correspondence, a first identifier used to identify an upstream multicast next-hop UMH node corresponding to the multicast data packet. In addition, the tail node may further obtain, based on the encapsulation information of the multicast data packet and a second correspondence, a second identifier used to identify the head node corresponding to the multicast data packet. After obtaining the first identifier and the second identifier, the tail node may perform an RPF check based on the first identifier and the second identifier. In the embodiments of this application, data lengths of the first identifier and the second identifier each are less than 128 bits. Therefore, in the embodiments of this application, the two pieces of data less than 128 bits may be compared, to simplify the RPF check.