Software-Assisted Multicast Filtering for Network Devices
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing hardware filtering mechanisms in network devices, such as those in MFH3 systems, are inadequate for handling unwanted packets, particularly during multicast operations, leading to increased CPU load and performance issues like channel changes and gaming speeds, due to software filtering being performed at the task/application layer instead of the faster interrupt/driver/data link layer.
Innovation Solution
Implementing a software-assisted multicast filter at the interrupt handler/driver/data link layer to filter out unwanted packets, which are then passed to the application/task layer for final filtering, utilizing specific criteria like packet length, destination address, and payload type to determine if a packet should be dropped.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If software filtering is performed at the task/application layer, then packet filtering can be implemented, but CPU load increases and performance deteriorates
Solution Approach 1:
The patent segments the packet filtering function into two parts: hardware filtering at the data link layer (interrupt handler) and software filtering at the application layer. The hardware filter handles the bulk of filtering operations using packet length, destination address, and port number criteria, while the software layer performs final filtering. This segmentation moves heavy processing to hardware, reducing CPU load while maintaining filtering reliability.
2Speed
If hardware filtering is used, then packet filtering speed is improved, but filtering accuracy is insufficient for unwanted packets
Solution Approach 1:
The patent introduces an intermediary software filter layer that bridges hardware filtering and application-level processing. This intermediary layer receives packets from the hardware filter, performs additional filtering based on packet content and attributes, and then passes filtered packets to the application layer. The intermediary ensures both speed (by using hardware filter) and accuracy (by adding software validation) requirements are met.
3Speed
If software filtering is moved to interrupt/driver layer, then processing speed is improved, but packet reassembly complexity increases due to USB partitioning
Solution Approach 1:
The patent extracts the packet reassembly function from the filtering process and handles it separately in the USB driver layer. The interrupt handler focuses solely on filtering operations using extracted packet attributes (length, destination address, port number), while the USB partitioning and reassembly are managed by the driver's existing mechanisms. This extraction allows the filtering to benefit from hardware acceleration without being bogged down by reassembly complexity.
Data Source
AI summary
A method is described including determining if a packet length parameter included in received data matches a first pre-determined value, determining if an address parameter included in received data matches an address of a receiving device, determining if a length parameter included in received data matches a second pre-determined value, determining if a packet destination port number parameter included in received data matches a third pre-determined value, determining if a packet payload type parameter included in received data matches a fourth pre-determined value and dropping the packet responsive to the matches.