A programmable network beacon implantation method and apparatus based on matching action pipelines

Abstract

This invention specifically relates to a programmable network beacon implantation method and apparatus based on a matching action pipeline. The method includes: generating matching rules and action instructions on the software side and sending them to the hardware; inputting the parsed packet header vector (PHV) into the programmable matching action pipeline, extracting key fields, and performing multi-layer protocol rule matching; upon a successful match, executing a single customized instruction, and using inverse butterfly network hardware to modify specific reserved bits of multiple different protocol fields in the PHV in parallel within a single cycle to achieve beacon implantation; finally, reordering and reassembling the data into a complete packet for forwarding. The corresponding apparatus includes modules for tag identification, field extraction, rule matching, beacon implantation, reordering, and configuration management. This invention, through software and hardware collaboration, achieves proactive network beacon implantation capabilities with nanosecond-level latency and line-speed processing while ensuring protocol compatibility and stealth, supporting dynamic configuration and flexible operation of multi-layer protocols.

Description

Technical Field

[0001] This invention relates to the field of network switching processing technology, and specifically to a programmable network beacon implantation method and apparatus based on a matching action pipeline. Background Technology

[0002] With the rapid development of internet and mobile communication technologies, the network has become a crucial infrastructure for social life and economic development. However, while enjoying the convenience it brings, cybersecurity issues are becoming increasingly prominent. For their own benefit, network intruders often use multi-level jump servers and anonymous communication to conceal the source of their attacks, illegally seizing network resources and stealing private information. This poses a serious threat to personal property security, social harmony and stability, and even national security, presenting unprecedented challenges to cybersecurity defense.

[0003] Early research in this field widely employed passive network flow analysis, which identifies malicious traffic by extracting statistical features of traffic and combining them with machine learning algorithms. However, this method requires complex algorithms and relies on a large number of samples to train the model, making it difficult to balance scalability and detection accuracy. To overcome the limitations of passive analysis, researchers have drawn inspiration from digital watermarking and proposed Active Network Flow Watermarking (ANFW) technology. This technology embeds a watermark (i.e., a network beacon) by actively modifying network flow features at the sending end, and then uses the beacon detection at the receiving end to determine flow associations, enabling the tracking and behavioral analysis of specific traffic. For example, Lusha Mo et al. proposed a network flow watermarking implementation system, the core idea of ​​which is as follows: Figure 1 As shown, watermarking and encrypted transmission are achieved by controlling the transmission time interval between different data packets. This active watermarking technology is more adaptable than traditional passive watermarking technology. It can exist in anonymous communication networks or other network environments, and is highly effective in detecting illegal communications. In recent years, this technology has gradually become a hot topic in the field of network security research.

[0004] Early network watermarking systems were mostly implemented using general-purpose CPUs. While they offered good flexibility and scalability, their processing performance was limited and could not meet the real-time processing requirements of high-speed network environments. Application-specific integrated circuits (ASICs), on the other hand, provided high performance but lacked reconfigurability, had long development cycles, and were costly, making them unable to adapt to rapidly evolving network protocols and watermarking algorithms. Finding a balance between high performance and high flexibility has become crucial for driving the practical deployment of active watermarking technology.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] This invention provides a programmable network beacon implantation method and apparatus based on a matching action pipeline, aiming to solve the shortcomings of existing network beacon implantation technologies, which are difficult to balance high-speed network line-speed processing, flexible programmability of multi-layer protocols and beacon covert compatibility, high latency of traditional software implementation, lack of reconfigurability of application-specific integrated circuits, and inability to adapt to high-speed networks and changing protocol environments.

[0007] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0008] According to a first aspect of the present invention, a programmable network beacon implantation method based on a matching action pipeline is provided, the method comprising: The software generates corresponding matching rules and action instructions based on the beacon implantation information. These matching rules and action instructions are then sent to the hardware device through a standard control plane interface to pre-configure the hardware behavior. The matching rules can be defined for any field in the network protocol stack, including layers 2, 3, 4, and even the application layer. The packet header vector (PHV) obtained by the parser is input into the programmable matching action pipeline. The key fields related to the current beacon implantation rule are aggregated from the PHV through a configurable field extraction unit. The key fields include, but are not limited to, MAC, IP, and port information fields. In the matching action level of the pipeline, the issued matching rules are used to match and judge the aggregated key fields; When a match is found, the action instruction associated with the matching rule is executed. The action instruction, through a single customized instruction, combined with the inverse butterfly network hardware structure, simultaneously modifies and implants beacons into specific reserved bits of multiple different protocol fields in the PHV. The specific reserved bits include the identification field and fragment offset field related to network layer and IP fragmentation in the PHV, as well as the reserved field of the transport layer TCP protocol. The PHV after beacon implantation is reordered and output. The header is reassembled by the reverse parser and combined with the buffered payload to generate a complete data packet, which is then forwarded and output.

[0009] In some exemplary embodiments, the hardware device supports beacon implantation for any key field of a network protocol at any level contained in the PHV vector.

[0010] In some exemplary embodiments, the field extraction unit uses a two-stage inverse butterfly network to extract key fields at byte-level and bit-level granularity, respectively. The first level is divided into 256 groups according to the byte-level inverse butterfly network, and a total of 1024 switching units are used; The second stage will extract the longest 256-bit field and then perform a bit-level inverse butterfly network, using a maximum of 1024 switching units.

[0011] In some exemplary embodiments, the aggregated key fields are matched and judged using the issued matching rules, specifically as follows: Extract matching keys from key fields, and select the beacon implantation command code required for the PHV by mapping the matching keys to pre-prepared matching rules in some way.

[0012] In some exemplary embodiments, the matching process is divided into three steps: precoding, bit vector storage, and matching lookup; First, the rule bit values ​​are pre-encoded into bit vectors, and the encoded rules are stored. Finally, the bit values ​​of the subfields in the matching key to be matched are matched with the corresponding bit vectors, and the matching rules are obtained through AND operation.

[0013] In some exemplary embodiments, the single customized instruction specifically includes: "Add" means adding a field to the PHV; Delete means deleting a portion of the field content in the PHV; "Change" indicates that a certain segment of data in PHV has been modified.

[0014] A programmable network beacon implantation device based on a matching action pipeline, the device comprising: The field extraction unit uses an extraction network to obtain key fields from the input PHV and passes them to the subsequent matching module; The rule matching module supports beacon implantation rules with optional key fields of multi-layer protocols to match the input PHV and obtain the instruction code number corresponding to the hit rule; The beacon implantation unit, associated with the rule matching module, responds to a match hit and is used to perform beacon implantation actions; it retrieves predefined instructions based on the number obtained from the match, parses and executes customized instructions, and completes the modification of specific reserved bits of multiple different protocol fields in PHV within a single operation cycle; The reordering module reads valid PHV data from RAM in ascending order of ID number, ensuring the output order of PHV data after pipeline processing and bypass channels.

[0015] In some exemplary embodiments, the apparatus further includes: The tag determination module extracts the tag field from the input PHV and determines whether the data packet needs to beacon implantation based on the tag field.

[0016] In some exemplary embodiments, the apparatus further includes: The configuration system divides the address space of the inverse butterfly network, matching rules, and action instructions into configurable information to realize the internal configurable hardware path; it realizes the protocol conversion between the AHB protocol and the internal configuration channel and cross-clock domain processing, providing a hardware southbound interface for CPU software programming.

[0017] The programmable network beacon implantation method and apparatus based on a matching action pipeline provided in the embodiments of the present invention achieve a unity of high performance, high flexibility, and strong concealment by combining software-defined beacon implantation strategies with rapid execution via a hardware pipeline. Its core lies in utilizing a programmable matching action pipeline to support flexible rule matching of multiple layers of fields in the network protocol stack, and innovatively employing a single customized instruction combined with inverse butterfly network hardware to modify specific reserved bits of multiple protocol fields in parallel within a single clock cycle. This compresses the latency of complex cross-protocol layer beacon implantation operations to the nanosecond level, ensuring line-speed processing capabilities. This scheme not only ensures high concealment and compatibility by distributing beacons into reserved fields at various layers, but also enables dynamic reconfiguration through a standard configuration interface, allowing it to quickly adapt to diverse network security needs. It provides an efficient hardware foundation for building a real-time, accurate, and traceable proactive network defense system.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0020] Figure 1 This is a schematic diagram of a network watermark injection principle provided by existing technology; Figure 2 This is a schematic diagram of a matching action pipeline implemented using an RMT model based on the PISA structure, provided by existing technology. Figure 3 This is a flowchart of the programmable network beacon implantation method based on a matching action pipeline provided in this invention. Figure 4 This is a schematic diagram illustrating the beacon implantation of multiple protocol fields provided in this invention. Figure 5 This is an architecture diagram of the beacon implantation pipeline hardware device provided in this invention. Figure 6 This is an architecture diagram of a beacon-embedded dedicated network switch provided by an embodiment of the present invention; Figure 7 This is a schematic diagram of the rule matching module in the hardware device provided in this invention. Figure 8 This is a schematic diagram illustrating the implementation of time-slot beacon implantation using the hardware device provided in this invention. Figure 9 This is a schematic diagram of the configuration system in the hardware device provided in this invention; Figure 10 This is a diagram of the automated simulation platform in the hardware device provided in this invention. Figure 11 This is a verification waveform diagram of the beacon implantation pipeline in the hardware device provided in this invention. Figure 12 This is a schematic diagram of the hardware device provided in this invention performing FPGA board-level verification testing. Detailed Implementation

[0021] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the invention will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0022] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0023] In recent years, the development of programmable switches and Software-Defined Networking (SDN) has provided new solutions to the aforementioned problems. SDN, by separating the control plane and data plane, endows networks with higher programmability and centralized management capabilities. In the data plane, the emergence of Protocol Independent Network Switching (PISA) architecture has brought about significant changes. Its core idea is to abstract the packet processing flow into a general, protocol-independent pipeline operation, thereby supporting flexible and programmable packet parsing, matching, and modification functions while maintaining hardware-level processing performance. For example, the RMT model based on this architecture proposed by Professor Nick McKeown's team at Stanford University has a processing flow as follows... Figure 2 As shown, this architecture starts with a programmable parser, dynamically parsing data packets into fixed-length packet header vectors. The vectors then flow through a series of flexibly configurable logical matching stages, each of which can define matching fields and entry sizes as needed, and update its status in real time through parallel action units. The processed vectors are then reassembled and encapsulated into data packets, ultimately outputting through a queue system with a definable queuing strategy. The entire process achieves fully pipelined software programmability from parsing, matching, action to scheduling, maintaining hardware-level processing performance while providing high flexibility and reconfigurability for the data plane.

[0024] Therefore, implementing network beacon implantation units based on programmable switching chip architecture can effectively enhance the network router's capabilities for network monitoring, security analysis, and threat detection. By implanting beacons in the router, network traffic data can be collected in real time, abnormal behavior can be identified, potential network attack sources can be traced, and precise intelligence support can be provided for network security defense.

[0025] To address the shortcomings and deficiencies of existing technologies, this example embodiment provides a programmable network beacon implantation method based on a matching action pipeline. (Reference) Figure 3 As shown, the specific steps may include: In step S101, the software generates configuration information such as extracted network nodes, matching rules, and action command codes based on the beacon implantation information, and sends it down through the control plane to complete the predefinition of hardware behavior; Step S102: Input the PHV header vector of the data packet obtained by the parser into the programmable matching action pipeline, and aggregate the key fields therein through the field extraction unit; Step S103: In the matching action level of the pipeline, the PHV key field is matched based on the preset beacon implantation rules that support optional key fields of multi-layer protocols; Step S104: When a match is found, execute the beacon implantation action associated with the rule. The action is performed by modifying and implanting beacons into specific reserved bits of multiple different protocol fields in PHV simultaneously through a single customized instruction combined with the inverse butterfly network hardware structure. Step S105: Reorder and output the packet header vector after beacon insertion, reassemble the header using the inverse parser, combine it with the cached payload to generate a complete data packet, and forward it.

[0026] The beacon implantation rule supports matching any field in the network protocol stack. The selectable range is determined by the parsing graph of the preceding parser and the PHV packet header vector information, ensuring the flexibility of the matching rule.

[0027] The beacon implantation rules support matching and actions with reserved or optional fields of protocols at the IP layer and above in the network protocol stack, thereby ensuring the concealment and compatibility of beacon implantation.

[0028] The execution unit of the single customized instruction is integrated into the hardware of the matching action pipeline. Through configuration, multiple protocol field reserved bits of any combination can be modified in parallel, thereby compressing the complex operation that originally required multiple pipeline stages into a single stage.

[0029] The method is implemented in programmable hardware, and the beacon matching, decision-making and implantation operations are completed in a fixed number of cycles in the pipeline, ensuring high real-time performance and line-speed processing capabilities compared with software implementation with nanosecond-level processing latency.

[0030] The beacon implantation actions include, but are not limited to, adding, deleting, and modifying fields, and the modification locations are distributed across multiple protocol layers in the data packet header.

[0031] The matching rules and action instructions of the programmable matching action pipeline can be dynamically configured and updated through the control plane interface to adapt to different beacon implantation strategies and protocol environments.

[0032] The steps in this exemplary embodiment will now be described in more detail with reference to the accompanying drawings and embodiments.

[0033] S101. Software Predefinition and Configuration Distribution: On the software side, a corresponding set of matching rules and action instructions are generated based on specific beacon implantation requirements (such as tracking targets, implantation strategies, and stealth requirements). These rules and instructions are distributed to the hardware device through the standard control plane interface to complete the preconfiguration of hardware behavior.

[0034] It should be noted that the hardware device of the present invention supports beacon implantation into any key field of any level of network protocol contained in the PHV vector. However, when selecting beacon implantation fields, the present invention conducts in-depth analysis of the message structure of each protocol layer and selects those fields that have minimal or no impact in actual communication as beacon carriers, fully considering not affecting the original structure and function of the data packet, maintaining protocol compatibility and implantation concealment.

[0035] Table 1 IP packet header information

[0036] Table 2 TCP Protocol Header Information

[0037] Specifically, for typical network packets, at the data link layer, the MAC header contains core fields such as source MAC address, destination MAC address, and protocol type. Each field performs a fixed link layer communication function, with no redundant or customizable field space, thus lacking the conditions for beacon implantation. In the network layer IP protocol, its header structure contains multiple functional fields, as shown in Table 1. Among them, the Identification field is used to identify the datagram sent by the host. Combined with the Flags field, it can distinguish IP fragmentation of different data packets. Related research data shows that the probability of data packet fragmentation during network transmission does not exceed 0.25%, and path MTU discovery technology can effectively prevent IP packets from being fragmented at intermediate routers, providing feasibility for the reloading of the Identification field. Meanwhile, the information in the Fragment Offset field has no substantial impact on data packet transmission in non-fragmented scenarios and can be used in conjunction with beacon marking. Based on this, the network layer can select the Identification field and Fragment Offset field related to IP fragmentation, totaling 32 bits of field space for the implantation of network beacons, which will not affect the normal function of the IP protocol and can ensure the stability of beacon transmission.

[0038] At the transport layer, the core protocols are TCP and UDP, which differ in their beacon implantation adaptability: the UDP header structure is simple and compact, with all fields being essential for transmission, lacking redundancy or scalability, making it unsuitable for beacon implantation; the TCP header, however, possesses good scalability, as shown in Table 2. Its Options field is a variable-length field used to store custom control information. While the maximum TCP header length is 60 bytes, the Options field can be expanded to a maximum of 40 bytes, capable of carrying more beacon information. However, actual network packet capture tests have verified that most TCP frames do not enable the Options field, making beacon implantation with this field only applicable to specific scenarios. Furthermore, the Reserved field (6 bits) in the TCP header is always idle regardless of the application scenario of the TCP frame, possessing full-scenario adaptability and serving as a general field choice for beacon implantation. At the application layer, common protocols such as HTTP and DNS provide user-defined fields. These fields lack unified and fixed usage specifications, offering flexibility for beacon implantation. Their specific implantation methods can be further designed according to actual application scenarios, which will not be detailed in this section.

[0039] S102. Packet Processing and Key Field Aggregation: After the data packet is processed by the front-end programmable parser, a packet header vector (PHV) containing multi-layer protocol header information is generated. This PHV is then input into the programmable matching action pipeline. First, a configurable field extraction unit efficiently aggregates the set of key fields related to the current beacon implantation rule from the wide-bit PHV.

[0040] Specifically, this example uses a reverse butterfly network to aggregate key fields. The address span that the reverse butterfly network can exchange increases with the number of stages. Different exchange address spans in different stages enable data extraction and exchange operations between arbitrary positions in the reverse butterfly network. The input data bit width and output data bit width of each stage of the reverse butterfly network need to be consistent, which means that the number of exchange units contained in each stage also needs to remain constant. The operation in each stage of the reverse butterfly network involves exchanging or holding N input data. Therefore, for an N-input reverse butterfly network, the number of exchange units in each stage is N / 2, the number of network stages is log2N, and the total number of exchange units required for the entire network is N / 2 × log2N. The PHV field length used here is 2048 bits. The first stage is divided into 256 groups according to the byte-level reverse butterfly network, so the total number of exchange units used is 1024. The second stage will extract the longest 256-bit field and then perform a bit-level reverse butterfly network. The total number of exchange units used here is also at most 1024.

[0041] S103. Flexible Matching of Multi-Layer Protocols: In the matching stage of the pipeline, the matching rules issued in step S101, which support optional key fields of multi-layer protocols, are used to match and judge the aggregated key fields. The matching rules can be flexibly defined for fields in the network protocol stack at layers 2 (such as MAC), 3 (such as IP), 4 (such as TCP / UDP), and even the application layer, ensuring the breadth of matching target selection and the flexibility of the strategy.

[0042] Specifically, the matching phase primarily uses different matching modes to classify the features of the PHV (Prognostics and Victims), and determines the processing operation to be performed on the PHV based on the different matching results. In the current scenario, matching involves mapping the matching key to pre-prepared matching rules in a certain way to select the beacon implantation command code required for the PHV. Different matching algorithms represent different mapping methods between the matching key and the rules. This example uses the Stride BV algorithm for rule matching. As one of the most classic matching algorithms, it originates from the FSBV algorithm. The entire matching process can be roughly divided into three steps: pre-encoding, bit vector storage, and match lookup. First, the key bit values ​​of the rule are pre-encoded into a bit vector, and the encoded rules are stored. Finally, based on the bit values ​​of the subfields in the matching key to be matched, the matching rules are obtained by mapping them to the corresponding bit vectors and performing an AND operation. The difference between the two lies in the pre-encoding stage, specifically the different methods of segmenting the matching field. FSBV stores rules by treating fields as 1-bit units, while Stride BV introduces a stepping technique to divide fields into steps according to specific needs, resulting in two different rule encoding and storage methods.

[0043] S104, Single-Instruction Multi-Field Parallel Implantation: When a match is found, the beacon implantation action associated with the rule is triggered. This action is driven by a customized composite instruction. After decoding, the instruction precisely modifies specific reserved bits of multiple different protocol fields in the PHV within a single operation cycle, completing the beacon implantation. This mechanism compresses the cross-protocol layer modification operation, which traditionally requires multi-stage pipeline relay, into a single stage, greatly improving implantation efficiency and real-time performance.

[0044] Specifically, the commands used can be categorized into three main types: "Add" adds a field to the PHV; "Delete" deletes a field from the PHV; and "Modify" modifies a segment of data in the PHV. All operations can be broken down into these three types. While any operation can be decomposed using these three commands, each operation occupies one stage of the reconfigurable pipeline. If the protocol implantation beacon algorithm is too complex, it will be mapped to multiple matching action pipeline stages, increasing the complexity of software configuration. To address this, a key field aggregation network is used to achieve a single command that modifies specific reserved bits of multiple protocol fields. The specific operational principle is as follows: Figure 4 As shown, multiple implantation fields from different protocols are aggregated together using an inverse butterfly network, and then beacon implantation is performed using byte-level implantation operation units, thereby improving the efficiency of protocol beacon implantation.

[0045] S105, Data Reassembly and Output: The modified PHV data is reordered to ensure the processing order, and finally reassembled into a complete data packet by the reverse parser and forwarded for output.

[0046] The following describes a hardware device for implementing the above method provided by the present invention, namely a programmable network beacon implantation device based on a matching action pipeline, referring to... Figure 5 The structural diagram of the entire device includes: Tag detection and bypass module: Used for initial screening of PHVs, it determines whether data packets need beacon implantation based on the tag field, and supports bypass channels to reduce the processing overhead of irrelevant traffic.

[0047] Configurable field extraction unit: Employs a multi-level inverse butterfly network to dynamically and efficiently extract key fields for rule matching from the input PHV according to the configuration, reducing data bandwidth pressure.

[0048] Programmable rule matching module: Contains multiple matching engines, used to load and execute matching rules issued by the software that support multi-level protocol fields, and output the matching results and the corresponding action instruction code storage address.

[0049] Beacon Implantation Unit: Contains built-in SRAM to store pre-configured beacon implantation custom instructions. It parses these instructions to obtain control information such as operation type (add, delete, modify, etc.), source / destination operand positions in the PHV, bitmask, and immediate values. Based on the decoding results, it retrieves data from the PHV or immediate values. The core control inverse butterfly network execution hardware generates modification results for multiple target field bits within one cycle, according to the instruction requirements.

[0050] Reordering and Output Module: Reorders the data that has been processed by the pipeline and bypassed to ensure the timing correctness of the output PHV.

[0051] Configuration Management System: As the southbound interface of the device, it is responsible for receiving and parsing configuration information sent by the control plane through the general-purpose bus. It performs unified address space allocation and management of all programmable resources, such as hardware inverse butterfly network connections, matching rule tables, and action instruction codes, to achieve dynamic reconfiguration of hardware behavior.

[0052] Specifically, the beacon implantation pipeline provided in this example is deployed in relevant network switches in actual application scenarios. Its input and output ends need to be equipped with an adapted parser and a reverse parser, respectively. The parser is used to receive network data packets and extract the header vector and metadata. The reverse parser is used to reverse parse the modified header vector and metadata to reconstruct a new data packet and send it out.

[0053] refer to Figure 6This paper presents a schematic diagram of the architecture for beacon implantation in a dedicated network switch. The following describes the data flow of a network packet within the dedicated network switch. First, the packet enters the switch through the network port. The PHY chip and MAC processing convert the differential signal into a packet format specific to a given width. Next, the parser separates the data header and payload. Key fields from each network protocol layer are extracted from the header to form a PHV vector, which is then sent to the subsequent beacon implantation pipeline. The payload passes through a buffer module. After processing by the beacon implantation pipeline, the new PHV is sent to a reverse parser for reassembly to obtain a new network header. This new header is then assembled with the original payload to form a new network packet, which is subsequently sent to the corresponding Ethernet port for output from the switch via scheduling and other modules.

[0054] For the rule matching module, the Stride BV algorithm is specifically used for matching, combined with focusing and stepping techniques to achieve a bidirectional pipelined BV matching mode in both the horizontal and vertical directions. Since FSBV is divided into 1-bit units, the required SRAM is equal to the number of bits in the input matching field. If the matching field is large, excessive SRAM is needed; for example, matching a 256-bit field requires 256 independent parameter SRAM resources. This not only leads to excessive power consumption in the backend implementation but also increases placement and routing complexity and timing convergence difficulties. (Reference) Figure 7 This diagram illustrates a bidirectional pipelined matching module. Horizontally, matching rules are segmented; in this example, up to 32 rules are supported, grouped into sets of 8. Vertically, key matching fields are segmented. It's worth noting that assuming the total length of the key field is M, and segmentation is done with a step size of N, the required number of processing unit blocks is M / N. The rule depth within each processing engine block is 2N, resulting in a total storage unit depth of M / N*2N. This depth decreases as N decreases, but it increases the pipeline length, the number of storage blocks, and the number of hardware processing cycles, increasing absolute processing latency. Therefore, careful planning is needed to achieve a balance between storage and processing latency.

[0055] For the beacon implantation unit, once the action execution module is activated, the decoded information obtained from the input instruction code includes: operation type, destination operand address, source operand address, mask, and mask length. It should be noted that the operands come from three sources: first, the source operands are derived from fields within the PHV itself, directly using the PHV fields as the source operands; second, they come from a pre-configured register file, where data primarily originates from a series of corresponding information sent by the software based on the current network environment; and third, they come from bypass channel data. Since the message processing unit contains multiple matching cores performing different matching actions, there are dependencies between the cores, requiring bypass information to transmit the processing results of the preceding cores to correct any deviations in operand selection by the subsequent cores. Specifically, when the source and destination operands are first obtained, because the original PHV has not yet been modified, operand retrieval is unaffected by address offsets and requires obtaining the operands based on the address information contained in the original instruction code. However, once the first core obtains the original operands, it immediately executes the operation and obtains the result. The result of this operation is bypassed into the other cores. The other cores will also perform the first bypass data judgment at the same time, that is, determine whether the retrieved data needs to be replaced with the result of the first core operation based on the operand address after the offset.

[0056] based on Figure 5 The hardware architecture diagram illustrates that PHV employs two distinct data flow paths: one via a bypass module and the other through the core processing pipeline. Assuming their delays are Tbypass and Tm, respectively, the typical order is Tm >> Tbypass. Specifically, Tm is primarily determined by the rule matching and beacon implantation modules, and is approximately 40 clock cycles. A hardware FPGA system achieving an 8ns clock cycle can reach latency in the hundreds of nanoseconds range. Based on the different delays of these two paths, and in conjunction with a subsequent reordering module, software control can be combined to achieve a system similar to... Figure 1 The method involves delaying the data packet stream to achieve the function of implanting a time-slot beacon. For detailed instructions, please refer to [link / reference]. Figure 8 For a stream of network packets, certain packets can be selectively passed through the core processing module without actual content beacon injection; only latency control is applied. Due to the reordering module, the delayed packets and subsequent packets are blocked, creating a time difference with the preceding packets. Time slot beacons can be implanted through specific software algorithms. Since the latency of each processing core is fixed at Tm, the implanted latency information can only be a multiple of TM.

[0057] For a specific diagram of the configuration management system, please refer to [link / reference]. Figure 9It should be noted that the CPU software access interface provided by this device is the AHB bus. If you want to use buses such as AXI for configuration, you can add a protocol conversion bridge module in series at the front end according to the actual usage requirements. To ensure clock compatibility between hardware and software, the configuration management system includes a cross-clock domain processing module, which processes based on the handshake protocol. Among them, acess_det completes the transmission handshake and response determination between fast and slow clock domains, and the cdc_ctl module completes the cross-clock domain sampling and transmission of data, which can ensure the stable transmission of configuration data across clock domains. In addition, there is an address layer decoding and management module. For the address allocation of the hardware configuration space, the large RAM address is first divided, such as the BV matching rule table, instruction code SRAM, inverse butterfly network node data, register file used by the arithmetic unit, etc., and then the address is allocated to some discrete registers from the gaps between them, which ensures the compactness of the address space. Regarding the actual configuration distribution process, configuration data enters the configuration management system via the AHB bus. First, it undergoes cross-clock domain processing and protocol width conversion, followed by layered decoding. The high-order address information is used to distinguish the module to be configured, and then the data is distributed to the specific operation module. Finally, the remaining address is used for address decoding of the internal RAM storage space to obtain the address of the RAM to be written, completing a full configuration process. It should be noted that the internal configuration system data width of this hardware device is 32 bits. This invention proposes a configuration system capable of distributing one configuration item per clock cycle. Combined with the system's 125MHz clock frequency, the throughput of the configuration system can reach 4000Mbps. With subsequent increases in the system frequency limit, the throughput of the configuration section will become even more impressive, offering a significant advantage in throughput compared to traditional serial configuration interfaces such as UART or JTAG.

[0058] The following experimental verification of a programmable network beacon implantation device based on a matching action pipeline in this embodiment was carried out through circuit simulation experiments and FPGA board-level verification.

[0059] This invention employs System Verilog to build an automated simulation platform for network beacon implantation units; the simulation tool used is Modelsim to verify the correctness of the circuit waveforms. FPGA board-level verification and functional testing of the hardware device are performed using the xcvu9p development board.

[0060] a) Simulation status The input interface of this invention includes a PHV input and a configuration channel input, and the output interface includes a PHV output and a configuration channel output. See the overall simulation platform block diagram for reference. Figure 10The Generator is used to generate stimulus content, primarily producing PHV test vectors containing information from different network protocol layers. The Driver is used to inject the input stimuli into the DUT according to the timing sequence of the DUT's input interfaces; simultaneously, different Monitor components are used to sample information from the input and output ports, and finally, the simulation results are compared using ScoreBoard. The additional config is used to mimic the configuration operations on the CPU software side, extracting pre-set rules and opcodes from text, and driving the DUT's configuration management system based on the AHB bus timing sequence; golden_model provides reference beacon implantation results.

[0061] Table 3. Information on a set of simulation test cases

[0062] This test verification example uses source MAC address matching based on PHV vectors for rule matching and beacon implantation for reserved bits in the TCP protocol layer. Detailed test information is shown in Table 3. Simulation waveform results are as follows. Figure 11 As shown, the matching action pipeline hardware implants different beacon information in the TCP protocol reserved field based on the PHV vector of different source MAC addresses.

[0063] b) Board-level verification This invention uses a relevant FPGA development board for hardware function testing. The overall test block diagram is shown below. Figure 12 To simulate the working scenario of a real network switch, a complete network packet forwarding and processing system was built by combining the project's related parser and reverse parser modules, with a system clock frequency of 125MHz. It should be noted that this FPGA development board does not currently have a CPU core that supports software programming; therefore, the configuration of the entire hardware device is achieved by pre-storing various configuration information in ROM, and then automatically configuring the hardware upon power-up to define the data plane's operating conditions. Simultaneously, the Spirent Test Center network tester was used to construct relevant test network data frames for verification testing, validating the network beacon implantation function in a gigabit test scenario.

[0064] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0065] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0066] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is defined only by the appended claims.

Claims

1. A programmable network beacon implantation method based on a matching action pipeline, characterized in that, The method includes: The software generates corresponding matching rules and action instructions based on the beacon implantation information. These matching rules and action instructions are then sent to the hardware device through a standard control plane interface to pre-configure the hardware behavior. The matching rules can be defined for any field in the network protocol stack, including layers 2, 3, 4, and even the application layer. The packet header vector (PHV) obtained by the parser is input into the programmable matching action pipeline. The key fields related to the current beacon implantation rule are aggregated from the PHV through a configurable field extraction unit. The key fields include, but are not limited to, MAC, IP, and port information fields. In the matching action level of the pipeline, the issued matching rules are used to match and judge the aggregated key fields; When a match is found, the action instruction associated with the matching rule is executed. The action instruction, through a single customized instruction, combined with the inverse butterfly network hardware structure, simultaneously modifies and implants beacons into specific reserved bits of multiple different protocol fields in the PHV. The specific reserved bits include the identification field and fragment offset field related to network layer and IP fragmentation in the PHV, as well as the reserved field of the transport layer TCP protocol. The PHV after beacon implantation is reordered and output. The header is reassembled by the reverse parser and combined with the buffered payload to generate a complete data packet, which is then forwarded and output.

2. The programmable network beacon implantation method based on a matching action pipeline according to claim 1, characterized in that, The hardware device supports the implantation of beacons into any key field of any level of network protocol contained in the PHV vector.

3. The programmable network beacon implantation method based on a matching action pipeline according to claim 1, characterized in that, The field extraction unit uses a two-level inverse butterfly network to extract key fields at byte-level and bit-level granularity, respectively. The first level is divided into 256 groups according to the byte-level inverse butterfly network, and a total of 1024 switching units are used; The second stage will extract the longest 256-bit field and then perform a bit-level inverse butterfly network, using a maximum of 1024 switching units.

4. The programmable network beacon implantation method based on a matching action pipeline according to claim 1, characterized in that, The key fields after aggregation are matched and judged using the issued matching rules, specifically as follows: Extract matching keys from key fields, and select the beacon implantation command code required for the PHV by mapping the matching keys to pre-prepared matching rules in some way.

5. The programmable network beacon implantation method based on a matching action pipeline according to claim 4, characterized in that, The matching process is divided into three steps: precoding, bit vector storage, and matching search; First, the rule bit values ​​are pre-encoded into bit vectors, and the encoded rules are stored. Finally, the bit values ​​of the subfields in the matching key to be matched are matched with the corresponding bit vectors, and the matching rules are obtained through AND operation.

6. The method according to claim 1, characterized in that, The single customized instruction specifically includes: "Add" means adding a field to the PHV; Delete means deleting a portion of the field content in the PHV; "Change" indicates that a certain segment of data in PHV has been modified.

7. A programmable network beacon implantation device based on a matching action pipeline, characterized in that, The device includes: The field extraction unit uses an extraction network to obtain key fields from the input PHV and passes them to the subsequent matching module; The rule matching module supports beacon implantation rules with optional key fields of multi-layer protocols to match the input PHV and obtain the instruction code number corresponding to the hit rule; The beacon implantation unit, associated with the rule matching module, responds to a match hit and is used to perform beacon implantation actions; it retrieves predefined instructions based on the number obtained from the match, parses and executes customized instructions, and completes the modification of specific reserved bits of multiple different protocol fields in PHV within a single operation cycle; The reordering module reads valid PHV data from RAM in ascending order of ID number, ensuring the output order of PHV data after pipeline processing and bypass channels.

8. A programmable network beacon implantation device based on a matching action pipeline, characterized in that, The device further includes: The tag determination module extracts the tag field from the input PHV and determines whether the data packet needs to beacon implantation based on the tag field.

9. A programmable network beacon implantation device based on a matching action pipeline, characterized in that, The device further includes: The configuration system divides the address space of the inverse butterfly network, matching rules, and action instructions into configurable information to realize the internal configurable hardware path; it realizes the protocol conversion between the AHB protocol and the internal configuration channel and cross-clock domain processing, providing a hardware southbound interface for CPU software programming.

Images