CLD Network Testing System for Line-Speed DPI Validation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current testing solutions for content-aware network devices are inadequate, as they fail to rigorously test performance and security under real-world conditions, especially at line speeds, and do not adequately simulate realistic application workloads and security attacks, leading to deployment challenges and potential failures.
Innovation Solution
A network testing system that includes configurable logic devices (CLDs) to process and route network packets, simulate traffic, and perform security testing at high speeds, capable of generating and analyzing packets at line rate while capturing traffic and performing application simulation and security testing simultaneously.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If traditional testing tools are used for content-aware network devices, then device complexity is reduced, but testing precision and reliability deteriorate due to inability to properly test DPI functionality and Layers 4-7 protocols
Solution Approach 1:
The testing system is divided into multiple specialized CLD modules, each handling specific testing functions (packet generation, DPI simulation, protocol validation, traffic analysis). This segmentation allows each module to be optimized for its specific function while collectively providing comprehensive testing capability for complex content-aware devices.
Solution Approach 2:
The patent introduces a specialized testing system as an intermediary between test engineers and content-aware network devices. This intermediary system translates high-level testing requirements into low-level packet manipulations and device interactions, enabling precise testing of DPI functionality and Layers 4-7 protocols without requiring engineers to directly manage device complexity.
2Reliability
If testing is performed at line speed with realistic workloads, then reliability of testing results improves, but productivity decreases due to increased resource requirements and testing time
Solution Approach 1:
The system performs preliminary actions by pre-generating realistic traffic patterns, pre-configuring test scenarios, and pre-warming caching mechanisms before actual testing begins. This allows the system to maintain line-speed testing with realistic workloads without excessive resource consumption during the actual testing phase.
Solution Approach 2:
The testing system maintains continuous operation at line speed through parallel packet processing pipelines and efficient resource management. Multiple CLD modules operate simultaneously to generate, send, and analyze packets without interruption, ensuring continuous useful action while maintaining high reliability through comprehensive coverage of test scenarios.
3Measurement precision
If comprehensive testing of Layers 4-7 protocols is implemented, then measurement precision improves, but device complexity increases due to additional testing infrastructure requirements
Solution Approach 1:
The CLD-based testing system is designed with universal, multi-functional modules that can handle multiple protocol layers and testing scenarios. The same infrastructure can test Layers 2-3 routing, Layers 4-7 application protocols, DPI functionality, and security features, eliminating the need for separate specialized testing equipment for each function.
Solution Approach 2:
The system achieves comprehensive protocol testing by dynamically changing parameters such as packet headers, payload content, protocol sequences, and traffic patterns rather than requiring separate physical testing infrastructure for each protocol. This parameter-based approach allows a single flexible infrastructure to adapt to testing requirements for different Layers 4-7 protocols.
Data Source
AI summary
A method of processing network traffic within a computing system, comprises at a first configurable logic device (CLD), receiving an ingress network packet from an external network interface, associating the ingress network packet with a timestamp indicating the time of receipt, parsing the ingress network packet to locate a link-layer checksum value and a routing-layer checksum value, determining whether the link-layer and routing-layer checksum values are correct based on the ingress network packet contents, and transmitting the ingress network packet to a second CLD via a high-speed interconnection; and at the second CLD receiving the ingress network packet, parsing the ingress network packet to locate a source address and a destination address, determining a destination and a route for the ingress network packet based at least in part on the source and destination addresses, and transmitting the ingress network packet to the determined destination via the determined route.