Shared Hash Table for Protocol-Independent Packet Routing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current high-speed networking chips are limited by fixed flow table designs and varying lookup key sizes, leading to inefficiencies in packet routing, particularly when dealing with unpredictable combinations of protocol headers, resulting in slowed performance and resource underutilization.
Innovation Solution
A system utilizing a shared hash table accessible by multiple flow tables, where each table generates a secure signature of its lookup key by detecting protocol headers, constructing a header n-tuple vector, and hashing it with a secret key, allowing for protocol-independent routing and dynamic allocation of memory resources.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If dedicated memory is allocated to each flow table, then lookup operations can be performed independently and quickly, but memory resources are underutilized when certain protocols are not present in the traffic mix
Solution Approach 1:
The patent merges multiple dedicated flow table memories into a single shared hash table memory structure. Different flow tables (L2, L3, MPLS, L4) share the same physical memory pool, allowing dynamic allocation of memory space based on actual traffic requirements. This eliminates the waste of allocating fixed memory to each protocol type when certain protocols may not be present or have low traffic volume.
Solution Approach 2:
The patent implements dynamic memory allocation within the shared hash table, where memory resources are dynamically assigned to different flow tables based on the actual protocol distribution in the traffic stream. The system can adaptively adjust which protocols are supported and allocate memory accordingly, rather than maintaining static dedicated memory for all possible protocols.
2Adaptability or versatility
If fixed lookup key sizes are used for each flow table, then hardware routing can be simplified, but the system cannot accommodate unpredictable combinations of protocol headers
Solution Approach 1:
The patent creates a universal hash table structure that can handle multiple protocol types (L2, L3, MPLS, L4) with varying header formats and sizes. The shared memory structure uses a unified lookup mechanism that adapts to different protocol combinations, allowing the same hardware routing infrastructure to support arbitrary protocol stacks without requiring separate dedicated tables for each protocol type.
Solution Approach 2:
The patent changes the parameter of lookup key size from fixed to variable, allowing the hash table to accommodate different protocol header combinations. The system dynamically adjusts the lookup key parameters based on the detected protocol headers in incoming packets, enabling support for unpredictable protocol stacks while maintaining efficient hardware-based routing.
3Adaptability or versatility
If software-based packet decoding is used for packets not matching dedicated routing tables, then protocol flexibility is improved, but routing performance is significantly slowed
Solution Approach 1:
The patent performs preliminary classification of packet protocols using the shared hash table before routing decisions are made. By detecting protocol headers and pre-computing the appropriate lookup key for the shared table, the system ensures that packets can be routed through hardware at line rate regardless of their protocol combination, eliminating the need for slower software-based decoding.
Data Source
AI summary
A system and method for protocol independent multi-flow table routing includes a first flow table, a second flow table, and a shared hash table accessible by both the first flow table and the second flow table. Upon receipt of a packet, a first secure signature of a first lookup key is generated for the first flow table, and a second secure signature of a second lookup key is generated for the second flow table. The shared hash table stores both the first secure signature in association with a first value corresponding to the first secure signature, and the second secure signature along with a second value corresponding to the second secure signature. The first and second values indicate destination information for the packet.