Network Device Key Format Segmentation for Legacy Compatibility
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current network switching systems face challenges in efficiently processing packets across a large number of ports while maintaining backwards compatibility with legacy systems, as they struggle to handle extended logical ports and virtual domains efficiently without requiring hardware or software reconfiguration.
Innovation Solution
The implementation of a network device with a forwarding engine and policy engine that determines key formats based on a key extension indicator, allowing for both standard and extended key formats to be used, enabling efficient packet processing and compatibility with legacy systems by utilizing a configuration table to populate keys and determine processing actions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If network switching systems use standard key formats for packet processing, then backwards compatibility with legacy systems is maintained, but the ability to handle extended logical ports and virtual domains is limited
Solution Approach 1:
The key format is segmented into two distinct parts: a standard field (e.g., 12 bits for VLAN ID) and an extension field (e.g., 16 bits). The standard field maintains compatibility with legacy systems, while the extension field enables support for extended logical ports and virtual domains. This segmentation allows the system to handle both traditional and extended networking requirements simultaneously without compromising backwards compatibility.
2Adaptability or versatility
If network devices are reconfigured to support extended logical ports, then handling of diverse communication scenarios is improved, but operational overhead and complexity increase
Solution Approach 1:
The extended key format serves multiple functions: it maintains support for standard VLANs through the standard field, enables extended logical port identification through the extension field, and provides a unified structure that works across different communication scenarios. This multi-functionality eliminates the need for separate configuration mechanisms for standard and extended port handling, reducing operational overhead.
3Adaptability or versatility
If hardware or software reconfiguration is required to support extended ports, then extended functionality is achieved, but system stability and compatibility are compromised
Solution Approach 1:
The extended key format is designed with the standard field and extension field structure in advance, allowing the system to accommodate both standard and extended port requirements from the outset. This preliminary design ensures that legacy systems continue to operate with the standard field while extended functionality is enabled through the extension field, maintaining system stability and backwards compatibility without requiring reconfiguration.
Data Source
AI summary
Techniques for processing packets in a network device include using a configuration table to determine a key corresponding to a packet. The configuration table may be indexed based on contents of a field of the packet (e.g., e/port or e/VLAN) to find a corresponding entry indicating a key format. When a key extension indicator has a first pre-determined value, a key extension field is added to the key format, and when the key extension indicator has a second pre-determined value, the key extension indicator is excluded from the key format. The populated key format or key (including any key extension field, if so determined) is used to determine a processing action for the packet. Key extension indicators support compatibility with non-legacy devices that utilize extended fields in packets, and with legacy devices. Embodiments of methods and network devices that support standard and extended keys are disclosed.