A multi-modal network collaborative processing method and device and a storage medium

Abstract

The application discloses a multi-modal network cooperative processing method and device and a storage medium, and is applied to a multi-modal network coexistence system including a message processing module, multiple network mode processing modules and a cooperative control module. The cooperative control module is realized based on configurable hardware logic in an FPGA. The method comprises the following steps: determining an input network mode of an input message and a corresponding target network mode processing module; determining a forwarding strategy through the target network mode processing module, wherein the forwarding strategy comprises a target forwarding network mode; when the target forwarding network mode is inconsistent with the input network mode, controlling the corresponding network mode processing module to perform network mode conversion through the cooperative control module to obtain a target processing message; and performing output control on the target processing message according to the running states of the multiple network mode processing modules. Thus, parallel hardware processing and cross-modal cooperative forwarding of multi-modal messages are realized, the forwarding delay is reduced, and the throughput and determinacy are improved.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a multimodal network collaborative processing method, device and storage medium. Background Technology

[0002] With the continuous development of Internet applications, traditional Internet Protocol (IP) networks have gradually shown limitations in mobility support, content distribution, and adaptation to specific scenarios. Information-centric networks, mobile-first networks, geostationary Earth Orbit (GEO) satellite networks, and user-defined network modes have emerged one after another, and the demand for multimodal network coexistence is constantly increasing.

[0003] Currently, multimodal network coexistence is typically achieved using a software-programmable architecture. In this architecture, the packet processing unit executes instructions sequentially, and each network mode shares processing resources via time-division multiplexing. However, this approach struggles to achieve true parallel line-rate forwarding. Furthermore, packet identification, forwarding decisions, and resource scheduling rely on host software or drivers, which can easily lead to significant scheduling delays and insufficient forwarding determinism.

[0004] Therefore, how to achieve the coexistence of multimodal networks and reduce scheduling latency is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, one aspect of this application provides a multimodal network cooperative processing method applied to a multimodal network coexistence system, the system comprising: a message processing module, multiple network modality processing modules, and a cooperative control module implemented based on configurable hardware logic in an FPGA; the message processing module and the cooperative control module are respectively connected to the multiple network modality processing modules; the method comprises: The message processing module determines the input network mode of the acquired input message; From the plurality of network mode processing modules, determine the target network mode processing module corresponding to the input network mode; The forwarding strategy for the input packet is determined by the target network mode processing module; the forwarding strategy includes the target forwarding network mode. Based on the forwarding strategy, determine whether the target forwarding network mode is consistent with the input network mode; If there is a discrepancy, the corresponding network modality processing module is controlled by the collaborative control module to perform network modality conversion on the input message to obtain the target processing message; and the output control of the target processing message is performed by the collaborative control module according to the operating status of the multiple network modality processing modules.

[0006] Optionally, the plurality of network mode processing modules include at least two of the following: NDN network mode processing module, MobilityFirst network mode processing module, GEO network mode processing module, IPv4 network mode processing module, IPv6 network mode processing module, and custom network mode processing module; The multiple network modality processing modules are implemented based on dedicated hardware forwarding logic in the FPGA, and process the packets of the corresponding network modality in parallel.

[0007] Optionally, the message processing module includes a multimodal message recognition engine and a protocol parsing and reconstruction array; The step of determining the input network mode of the acquired input message through the message processing module includes: The multimodal message recognition engine extracts protocol feature fields from the input message; Based on the protocol feature fields, network mode matching is performed on the input message; If at least two candidate network modes are matched, the input network mode is determined from the at least two candidate network modes according to a preset mode priority.

[0008] Optionally, the preset modal priority includes a decreasing priority order of custom network modality, named data network modality, mobile-first network modality, geostationary orbit satellite network modality, IPv6 network modality, and IPv4 network modality.

[0009] Optionally, before determining the target network mode processing module corresponding to the input network mode from the plurality of network mode processing modules, the method further includes: The array is reconstructed by parsing the protocol, and the corresponding hardware parser is invoked according to the input network mode. The hardware parser extracts the structured forwarding fields required by the target network modality processing module to perform forwarding decisions from the input packet. The structured forwarding field is sent to the target network modality processing module.

[0010] Optionally, determining the forwarding strategy of the input packet through the target network modality processing module includes: When the target network mode processing module is the NDN network mode processing module, the name information of the input packet is matched by a two-level Bloom filter lookup structure; and the next hop information or content response mode of the input packet is determined by the undecided interest table hardware maintenance logic and content storage fast retrieval circuit, so as to determine the forwarding strategy. When the target network mode processing module is the MobilityFirst network mode processing module, the network address mapping relationship of the input packet is determined by binding the network address to a globally unique identifier and a cache; and the next-hop information is determined by an intra-domain routing lookup engine based on the network address, so as to determine the forwarding strategy.

[0011] Optionally, determining the forwarding strategy of the input packet through the target network modality processing module includes: When the target network mode processing module is the GEO network mode processing module, the transmission path and transmission time slot of the input packet are determined by the delay compensation submodule, the link budget submodule, and the routing calculation submodule, so as to determine the forwarding strategy; The delay compensation submodule calculates the link delay corresponding to the satellite link based on ephemeris data, and adjusts the transmission scheduling time slot of the input message according to the link delay.

[0012] Optionally, determining the forwarding strategy of the input packet through the target network modality processing module includes: When the target network mode processing module is the IPv4 network mode processing module or the IPv6 network mode processing module, the input packet is routed using a routing lookup engine based on TCAM or Bloom filter enhanced hash table to determine the forwarding strategy; The IPv4 network mode processing module and the IPv6 network mode processing module support bidirectional tunnel encapsulation conversion between IPv4 packets and IPv6 packets.

[0013] Optionally, determining the forwarding strategy of the input packet through the target network modality processing module includes: When the target network mode processing module is the custom network mode processing module, the forwarding pipeline processing is performed according to the preset forwarding atomic operation IP core and user configuration file to determine the forwarding strategy; The user configuration file is used to define the forwarding pipeline of the custom network mode and write it into the configuration register of the custom network mode processing module, and / or to trigger the cooperative control module to update the hardware logic corresponding to the custom network mode processing module.

[0014] Optionally, the step of controlling the output of the target processing message through the collaborative control module based on the operating status of the plurality of network modality processing modules includes: Obtain the buffer queue depth corresponding to each of the network modality processing modules; Based on the depth of each buffer queue, determine the scheduling weight and shared buffer allocation capacity corresponding to each network modality processing module; The target processing message is output and scheduled according to the scheduling weight; Specifically, when the depth of the buffer queue corresponding to the target network modality processing module exceeds a preset queue threshold, the scheduling weight corresponding to the target network modality processing module is increased, and / or the allocated capacity of the shared buffer corresponding to the target network modality processing module is increased.

[0015] Optionally, the multimodal network coexistence system includes multiple FPGA processing nodes, and the FPGA processing nodes are connected to each other through a chip interconnect module; The chip interconnect module is used to forward messages to be processed between different FPGA processing nodes; The collaborative control module determines the target FPGA processing node based on the operating status of each FPGA processing node, and controls the chip interconnect module to send the message to be processed to the target FPGA processing node.

[0016] Another aspect of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the computer program to implement the steps of the multimodal network cooperative processing method.

[0017] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the multimodal network cooperative processing method.

[0018] The multimodal network collaborative processing method, device, and storage medium provided in this application have the following beneficial effects: The message processing module identifies the network mode of the input message, and the corresponding network mode processing module in the FPGA determines the forwarding strategy, enabling messages of different network modes to be processed through corresponding hardware logic. When the target forwarding network mode is inconsistent with the input network mode, the collaborative control module implements network mode conversion and performs output control based on the operating status of each network mode processing module. This reduces the dependence of different network modes on shared message processing units and host software scheduling, enabling parallel processing and cross-modal collaborative forwarding of multimodal messages, reducing mode conversion and output scheduling latency, and improving message forwarding efficiency, system throughput, and forwarding determinism. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a multimodal network collaborative processing method provided in an embodiment of this application.

[0020] Figure 2This is a schematic diagram of the structure of a multimodal network coexistence system provided in an embodiment of this application.

[0021] Figure 3 This is a schematic diagram of a multimodal network coexistence system provided in another embodiment of this application.

[0022] Figure 4 This is a schematic diagram of the structure of a multimodal network coexistence system provided in another embodiment of this application.

[0023] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0024] The reference numerals in the attached diagram are as follows: 20 is the message processing module, 21 is the network modality processing module, 22 is the collaborative control module, 200 is the multimodal message recognition engine, 201 is the protocol parsing and reconstructing array, 210 is the dynamically reconfigurable area controller, 211 is the shared storage management unit, 212 is the unified scheduling arbitrator, 220 is the NDN network modality processing module, 221 is the MobilityFirst network modality processing module, 222 is the GEO network modality processing module, 223 is the IPv4 network modality processing module, 224 is the IPv6 network modality processing module, 225 is the custom network modality processing module, 50 is the memory, 51 is the processor, 52 is the display screen, 53 is the input / output interface, 54 is the communication interface, 55 is the power supply, 56 is the communication bus, 501 is the computer program, 502 is the operating system, and 503 is the data. Detailed Implementation

[0025] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0026] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0027] Figure 1This is a flowchart illustrating a multimodal network collaborative processing method provided in an embodiment of this application. Figure 2 This is a schematic diagram of a multimodal network coexistence system provided in an embodiment of this application. In an optional embodiment, the method provided in this application can be applied to... Figure 2 The multimodal network coexistence system shown is used to identify, parse, make forwarding decisions, perform cross-modal conversion, and schedule output for packets of different network modes within the same programmable hardware platform. Here, network modes can be understood as network protocol suites or network domains with different address formats, protocol fields, routing policies, and packet forwarding logic. Examples include Named Data Networking (NDN), MobilityFirst (MF), Geostationary Earth Orbit (GEO), Internet Protocol version 4 (IPv4), Internet Protocol version 6 (IPv6), and User Defined Modality (UDM).

[0028] like Figure 2 As shown, as an optional embodiment, the multimodal network coexistence system may include a message processing module 20, multiple network mode processing modules 21, and a cooperative control module 22. The cooperative control module 22 is implemented based on configurable hardware logic in a Field Programmable Gate Array (FPGA). Both the message processing module 20 and the cooperative control module 22 are connected to each of the network mode processing modules 21. Therefore, after an input message enters the system, the message processing module 20 first determines its input network mode, then the corresponding network mode processing module 21 executes the forwarding decision, and the cooperative control module 22 provides unified control when cross-modal forwarding or output resource scheduling is required.

[0029] based on Figure 2 The multimodal network coexistence system shown is as follows: Figure 1 As shown, the method includes: S10: Determine the input network mode of the acquired input message through the message processing module; First, it should be noted that, in specific embodiments, the execution subject of the method provided in this application can be an electronic device equipped with an FPGA chip or FPGA board, or a multimodal network coexistence system deployed in a communication node, network switching device, satellite-to-ground link gateway, or multimodal network experimental platform. This application does not limit the scope of the application.

[0030] In specific embodiments, the acquired input message may be a network message from an Ethernet interface, PCIe interface, inter-chip communication interface, or other high-speed network interface; this application does not limit this. After receiving the input message, the message processing module 20 can read the protocol feature field from the input message and determine the network mode to which the input message belongs based on the protocol feature field, i.e., determine the input network mode. Here, the input network mode refers to the original protocol type or original network domain type manifested by the input message when it enters the multimodal network coexistence system.

[0031] S11: Determine the target network mode processing module corresponding to the input network mode from multiple network mode processing modules; In a specific embodiment, multiple network mode processing modules 21 correspond to different network modes. Each network mode processing module 21 can be implemented based on dedicated hardware forwarding logic in the FPGA, and each has independent routing lookup, state maintenance, and packet encapsulation processing circuits.

[0032] Based on determining the input network mode of the input message in step S10, further, from multiple network mode processing modules 21, a target network mode processing module corresponding to the input network mode is selected, that is, a target network mode processing module that can be used to process the input network mode is determined.

[0033] For example, when the input network mode is NDN, the target network mode processing module can be NDN network mode processing module 220; when the input network mode is IPv4, the target network mode processing module can be IPv4 network mode processing module 223. This approach avoids having different mode packets executed instruction-by-instruction by a general-purpose processor core, reducing software scheduling latency during mode switching.

[0034] S12: Determine the forwarding strategy of the input packet through the target network mode processing module; the forwarding strategy includes the target forwarding network mode; In specific embodiments, the forwarding strategy may include one or more of the following: next-hop information, content response method, sending path, sending time slot, encapsulation method, target output port, and target forwarding network mode, which are not limited in this application.

[0035] The target forwarding network mode refers to the network mode or network domain that the input packet needs to enter, as determined by the forwarding strategy. For example, when the input packet is an NDN interest packet, the target network mode processing module can first look up the next hop corresponding to the name prefix. If the next hop is located in the IPv4 network domain or the GEO satellite link network domain, then the target forwarding network mode can correspond to the IPv4 network mode or the GEO network mode.

[0036] S13: Based on the forwarding strategy, determine whether the target forwarding network mode is consistent with the input network mode; Furthermore, determining whether the target forwarding network mode is consistent with the input network mode, in an optional embodiment, when the target forwarding network mode is consistent with the input network mode, it indicates that the input packet is still forwarded within the network domain of this mode, and the output scheduling can be directly performed according to the forwarding strategy output by the target network mode processing module.

[0037] In another optional embodiment, when the target forwarding network mode is inconsistent with the input network mode, it indicates that the input packet needs to be forwarded across the modality network domain. In this case, the cooperative control module 22 needs to control the corresponding network mode processing module to perform network mode conversion on the input packet.

[0038] S14: If there is a discrepancy, the corresponding network mode processing module is controlled by the collaborative control module to perform network mode conversion on the input message to obtain the target processing message; and the output control of the target processing message is performed by the collaborative control module according to the operating status of multiple network mode processing modules.

[0039] In specific embodiments, network mode conversion may include one or more of the following: packet re-encapsulation, packet decapsulation, address mapping, name prefix to identifier mapping, link frame header addition, field replacement, and check field recalculation. This application does not limit the specific implementation of these features.

[0040] The target processing message can be understood as a message that meets the target forwarding network mode output requirements after undergoing current mode forwarding decision or cross-mode conversion. When controlling the output of the target processing message, the cooperative control module 22 can obtain motion status information such as the buffer queue depth, output port occupancy status, scheduling weight, and shared buffer capacity of each network mode processing module 21, and determine the output timing and output path of the target processing message based on the above operating status.

[0041] Therefore, the message processing module identifies the network mode of the input message, and the corresponding network mode processing module in the FPGA determines the forwarding strategy. This allows messages of different network modes to be processed by the corresponding hardware logic. When the target forwarding network mode is inconsistent with the input network mode, the cooperative control module performs network mode conversion and performs output control based on the operating status of each network mode processing module. This reduces the dependence of different network modes on the shared message processing unit and host software scheduling, enabling parallel processing of multimodal messages and cross-modal cooperative forwarding, reducing mode conversion and output scheduling latency, and improving message forwarding efficiency, system throughput, and forwarding determinism.

[0042] In one alternative embodiment, such as Figure 2As shown, the multiple network modality processing modules 22 may include at least two of the following: NDN network modality processing module 220, MobilityFirst network modality processing module 221, GEO network modality processing module 222, IPv4 network modality processing module 223, IPv6 network modality processing module 224, and custom network modality processing module 225. These multiple network modality processing modules are implemented based on dedicated hardware forwarding logic in the FPGA, and process packets of the corresponding network modality in parallel.

[0043] In a specific embodiment, the NDN network mode processing module 220 is used to process interest packets and data packets with names as the core, the MobilityFirst network mode processing module 221 is used to process mobile network packets with separate Globally Unique Identifier (GUID) and Network Address (NA), the GEO network mode processing module 222 is used to process satellite link packets with satellite-to-ground propagation delay constraints and transmission time slot constraints, the IPv4 network mode processing module 223 and the IPv6 network mode processing module 224 are used to process traditional IP packets, respectively, and the custom network mode processing module 225 is used to process industry-customized protocol packets according to user configuration files.

[0044] In an optional embodiment, each network mode processing module 22 can be arranged as an independent hardware pipeline in spatial parallel within the FPGA, and the key forwarding logic of each mode does not depend on the software execution of the general-purpose processor core. For example, the NDN network mode processing module 220 can perform name lookup and pending interest state maintenance in parallel, the IPv4 network mode processing module 223 can perform longest prefix matching in parallel, and the GEO network mode processing module 222 can perform delay compensation and transmission time slot calculation in parallel. Thus, when packets of different modes arrive simultaneously, the system does not need to queue them on a general-purpose packet processing unit in a time-division multiplexing manner, but can instead send the packets to the hardware forwarding logic of the corresponding mode.

[0045] It should be noted that the above-mentioned at least two network modes can be combined according to the actual deployment scenario, and this application does not limit this. For example, in a terrestrial data center interconnection scenario, a combination of NDN network mode processing module 220, IPv4 network mode processing module 223, and IPv6 network mode processing module 224 can be selected. In a space-ground converged communication scenario, a combination of GEO network mode processing module 222, MobilityFirst network mode processing module 221, and NDN network mode processing module 220 can be selected.

[0046] Therefore, by mapping different network modes to dedicated hardware forwarding logic in the FPGA, packets of each mode can be processed in a parallel pipeline manner, reducing resource contention between modes and providing a hardware foundation for subsequent cross-mode conversion and unified scheduling.

[0047] Figure 3 This is a schematic diagram of a multimodal network coexistence system provided for another embodiment of this application. In an optional embodiment, such as... Figure 3 As shown, the message processing module 20 includes a multimodal message recognition engine 200 and a protocol parsing and reconstructing array 201.

[0048] Based on this, as an optional embodiment, the input network mode of the acquired input message is determined by the message processing module, including: The multimodal message recognition engine 200 extracts protocol feature fields from the input message; Based on the protocol feature fields, network mode matching is performed on the input message; If at least two candidate network modes are matched, the input network mode is determined from the at least two candidate network modes according to the preset mode priority.

[0049] In specific embodiments, the protocol feature fields may include one or more of the following: Ethernet frame type, network layer version field, protocol magic number, specific preamble sequence, header length, name field start position, GUID field, link control header field, and user-defined fields; this application does not limit the scope of these fields. For example, when the Ethernet frame type is 0x0800, it can be preliminarily identified as an IPv4 packet. When the Ethernet frame type is 0x86DD, it can be preliminarily identified as an IPv6 packet. When the Ethernet frame type is 0x8624, it can be identified as an NDN custom type packet. For MobilityFirst, GEO, and UDM packets, parallel matching can be performed using specific preamble sequences, link frame headers, or magic numbers.

[0050] In one optional embodiment, the multimodal packet recognition engine 200 can be implemented using a six-stage pipeline. The first stage extracts the Ethernet frame type, the second stage performs preliminary classification based on the Ethernet frame type, the third to fifth stages perform parallel matching of specific preamble sequences for MobilityFirst, GEO, and UDM, and the sixth stage outputs a unique modality label. In another optional embodiment, all six feature matchers can be implemented using pure combinational logic, and the critical path delay, after static timing analysis, can be 3.8 nanoseconds, thus meeting the single-cycle classification requirement.

[0051] It should be noted that when the same input message simultaneously meets the matching conditions of at least two candidate network modes, the input message is not directly copied to multiple network mode processing modules. Instead, a unique input network mode is determined based on a preset mode priority. This approach avoids issues such as overlapping protocol feature fields, user-defined fields overriding traditional protocol fields, or mis-splitting in tunnel encapsulation scenarios.

[0052] Based on the above embodiments, as an optional embodiment, the preset modal priority includes a priority order of decreasing priority for custom network modal, named data network modal, mobile-first network modal, geostationary orbit satellite network modal, IPv6 network modal and IPv4 network modal.

[0053] In a specific embodiment, the preset modality priority can be implemented through combinational logic encoding in the confidence arbitration level of the multimodal packet recognition engine 200. That is, when the UDM matcher outputs a positive decision, the confidence arbitration level outputs the UDM modality label first. When the UDM matcher does not output a positive decision but the NDN matcher outputs a positive decision, the confidence arbitration level outputs the NDN modality label. After this, the judgments are made sequentially in the order of MobilityFirst, GEO, IPv6, and IPv4.

[0054] It's important to note that UDM is set to the highest priority because it's typically used for industry-customized or experimental protocols, and its field positions and semantics may override or reuse traditional protocol fields. Placing NDN, MobilityFirst, and GEO before IPv6 and IPv4 ensures priority recognition of special encapsulation formats in information-centric networks, mobile-first networks, and satellite link networks. Prioritizing IPv6 over IPv4 prevents IPv6 packets from being downgraded in dual-stack or tunneled packets due to the presence of traditional IPv4 fields.

[0055] Furthermore, it should be noted that the aforementioned preset modal priorities can be embedded in FPGA combinational logic, or the corresponding priority encoding values ​​can be written into the configuration register without changing the priority protection range. For priority encoding implemented using pure combinational logic, the arbitration delay can be less than 4 nanoseconds in the specific implementation, thus matching the processing cycle of single-cycle modal classification.

[0056] Therefore, by determining a clear modality priority order, a unique input network modality can be output when multiple protocol features appear simultaneously, reducing the probability of misclassification in a multimodal protocol coexistence environment.

[0057] In an optional embodiment, before determining the target network mode processing module corresponding to the input network mode from a plurality of network mode processing modules, the method further includes: The array 201 is reconstructed through protocol parsing, and the corresponding hardware parser is invoked according to the input network mode. The hardware parser extracts the structured forwarding fields required by the target network mode processing module to perform forwarding decisions from the input packets. The structured forwarding field is sent to the target network modality processing module.

[0058] In a specific embodiment, the protocol parsing and reconstructing array 201 can include multiple hardware parsers, each corresponding to a different network mode. Specifically, for NDN packets, the hardware parser can extract fields such as name prefix, nonce, interest packet, or packet identifier. For MobilityFirst packets, the hardware parser can extract fields such as GUID, NA, service type, and path identifier. For GEO packets, the hardware parser can extract fields such as link ID, delay flag, sending window, and ephemeris index. For IPv4 or IPv6 packets, the hardware parser can extract fields such as destination address, source address, next header, port number, or flow label. For UDM packets, the hardware parser can extract custom fields according to the field offset and field length defined in the user configuration file.

[0059] Structured forwarding fields can be organized as key-value pairs or as fixed-width hardware bus field groups. For example, for IPv4 network mode processing module 223, structured forwarding fields may include a 32-bit destination address and protocol number. For IPv6 network mode processing module 224, structured forwarding fields may include a 128-bit destination address, flow label, and next header. For NDN network mode processing module 220, structured forwarding fields may include a name prefix hash, name component count, and a Nonce field. In specific embodiments, the above-mentioned structured forwarding fields can be directly input into the routing lookup engine or state maintenance logic of the corresponding mode.

[0060] It should be noted that the protocol parsing and reconstructing array 201 is not only used for field extraction, but also for packet field reconstruction in cross-modal conversion scenarios. For example, when using an NDN interest packet as an IPv4 tunnel payload, an IPv4 outer header can be generated for it. When encapsulating a MobilityFirst packet into a GEO link frame, a GEO control header and link ID can be added to it. Thus, the protocol parsing and reconstructing array 201 can simultaneously support intra-modal forwarding decisions and cross-modal packet reconstruction.

[0061] In one optional embodiment, the target network modality processing module determines the forwarding strategy of the input packet, including: When the target network mode processing module is the NDN network mode processing module 220, the name information of the input packet is matched by a two-level Bloom filter lookup structure; and the next-hop information or content response mode of the input packet is determined by the undecided interest table hardware maintenance logic and content storage fast retrieval circuit to determine the forwarding strategy. When the target network mode processing module is the MobilityFirst network mode processing module 221, the network address mapping relationship of the input packet is determined by binding the global unique identifier with the network address cache; and the next hop information is determined by the intra-domain routing lookup engine based on the network address, so as to determine the forwarding strategy.

[0062] In a specific embodiment, the two-stage Bloom filter lookup structure may include a first-stage Bloom filter and a second-stage Bloom filter. The first-stage Bloom filter is used to quickly exclude obviously missing name prefixes, and the second-stage Bloom filter is used to further filter hash collisions. A Bloom filter is a hardware-friendly lookup structure that uses multiple hash functions and bit arrays to determine whether an element is likely to exist. Its characteristic is that it can perform fast existence determination with relatively small storage resources. In an optional embodiment, the first-stage Bloom filter can have a depth of 8192 bits, and the second-stage Bloom filter can have a depth of 16384 bits, and it is constructed using the FPGA's internal Block Random Access Memory (BRAM).

[0063] The Pending Interest Table (PIT) hardware maintenance logic is used to maintain the status of NDN interest packets that have been forwarded but have not yet received a data response. The Content Store (CS) fast retrieval circuit is used to check whether the corresponding content already exists in the local cache. The PIT table can be implemented as a hash table, and each entry can include a nonce, a request interface, and a 64-bit hardware timer. The aging time can be set to 2 seconds, and it is periodically scanned and cleared by a 100 MHz hardware state machine. Thus, for an NDN interest packet, the NDN network modality processing module 220 can determine the next-hop information or directly determine the content response method when the CS is hit.

[0064] In a specific embodiment, the MobilityFirst network modality processing module 221 may include a GUID-NA binding cache, an NA-based intra-domain routing lookup engine, and a cache update state machine. The GUID-NA binding cache records the binding relationship between GUIDs and NAs, where the NA indicates the network address or currently reachable location. The GUID-NA binding cache can be implemented using a 4-way set-associative static random access memory (SRAM) with a capacity of 8192 entries. The cache update state machine can be maintained and replaced using a Least Recently Used (LRU) method. After obtaining the NA from the GUID-NA binding cache, the NA-based intra-domain routing lookup engine can determine the next-hop information.

[0065] Therefore, the NDN network mode processing module 220 can complete name lookup, PIT status maintenance and CS hit determination in hardware, and the MobilityFirst network mode processing module 221 can complete GUID to NA mapping and intra-domain route lookup in hardware, so that the forwarding decisions of the information center network and the mobile-first network do not depend on the software instruction execution of the general-purpose processor core.

[0066] In another optional embodiment, the forwarding strategy for the input packet is determined by the target network modality processing module, including: When the target network mode processing module is the GEO network mode processing module 222, the transmission path and transmission time slot of the input packet are determined through the delay compensation submodule, link budget submodule and routing calculation submodule, so as to determine the forwarding strategy; The delay compensation submodule calculates the link delay corresponding to the satellite link based on ephemeris data and adjusts the transmission scheduling time slot of the input message according to the link delay.

[0067] In a specific embodiment, ephemeris data may include satellite position, ground station position, orbital parameters, link visibility window, and satellite-to-ground distance variation information. The delay compensation submodule can utilize a digital signal processing (DSP) unit in the FPGA, such as a DSP48E2 unit, configured as a multiplier-accumulator to calculate the instantaneous link distance based on a pre-stored ephemeris table, and accordingly calculate the satellite link propagation delay. The link budget submodule can combine link quality, transmit power, path loss, available bandwidth, and bit error rate constraints to determine whether candidate transmission links meet the transmission conditions. The routing calculation submodule can determine the forwarding strategy for GEO packets based on the transmission path, link visibility window, and transmission time slot.

[0068] Therefore, the GEO network mode processing module 222 can incorporate the long-latency characteristics of satellite and ground into the hardware forwarding decision, so that GEO packets are not just routed as ordinary IP packets, but also take into account link latency, link budget and transmission time slot, thereby adapting to the deterministic transmission requirements in the integrated space-ground network.

[0069] In another optional embodiment, the target network modality processing module determines the forwarding strategy of the input packet, including: When the target network mode processing module is an IPv4 network mode processing module 223 or an IPv6 network mode processing module 224, the input packet is routed using a routing lookup engine based on TCAM or an enhanced hash table based on a Bloom filter to determine the forwarding strategy. Among them, the IPv4 network mode processing module 223 and the IPv6 network mode processing module 224 support bidirectional tunnel encapsulation conversion between IPv4 packets and IPv6 packets.

[0070] In specific embodiments, TCAM can be used to perform longest prefix matching, characterized by its ability to match routing entries with wildcard bits within a single lookup cycle. A routing lookup engine based on a Bloom filter-enhanced hash table can first quickly determine whether a target prefix might exist using a Bloom filter, and then read the corresponding routing entry from the hash table, thereby reducing the number of invalid hash lookups. For resource-constrained FPGA implementations or those requiring high lookup throughput, a Hybrid Memory Cube (HMC) can be used to assist in storing routing table entries to support concurrent access to IPv4 and IPv6 routing tables.

[0071] In one optional embodiment, bidirectional tunnel encapsulation conversion between IPv4 and IPv6 packets may include processes such as encapsulating IPv4 packets into IPv6 tunnels, encapsulating IPv6 packets into IPv4 tunnels, generating outer header fields, preserving inner packet information, filling tunnel endpoint addresses, and updating checksum fields. Through bidirectional tunnel encapsulation conversion, IPv4 network domains and IPv6 network domains can communicate with each other without changing the semantics of the original inner packets.

[0072] It should be noted that although both the IPv4 network mode processing module 223 and the IPv6 network mode processing module 224 belong to IP network modes, they differ in address length, header fields, extension header processing, and routing table organization. Therefore, corresponding hardware forwarding logic is set for each in this embodiment. Thus, IPv4 and IPv6 packets can enter the corresponding hardware lookup engine, and when cross-IP version forwarding is required, the conversion is completed through tunnel encapsulation.

[0073] In another optional embodiment, the target network modality processing module determines the forwarding strategy of the input packet, including: When the target network mode processing module is a custom network mode processing module 225, the forwarding pipeline processing is executed according to the preset forwarding atomic operation IP core and user configuration file to determine the forwarding strategy; The user configuration file is used to define the forwarding pipeline of the custom network mode and write it into the configuration register of the custom network mode processing module 225, and / or to trigger the cooperative control module to update the hardware logic corresponding to the custom network mode processing module 225.

[0074] In a specific embodiment, the forwarding atomic operation IP core may include hardware operation units such as exact matching, range matching, field replacement, multicast replication, field extraction, field insertion, checksum update, and port selection. The user configuration file can define the protocol magic number, number of fields, field offset, field length, semantic type, and action pipeline for custom network modalities. The configuration file can be received by the modal configuration interface module and written to the configuration random access memory or configuration register of the custom network modal processing module 225, causing the UDM parser and forwarding pipeline to execute according to the user-defined field rules.

[0075] Table 1 shows the general format of a UDM parser configuration descriptor.

[0076] Table 1 is a schematic table illustrating the overall format of a UDM parser configuration descriptor provided in the embodiments of this application. As shown in Table 1, the UDM parser configuration descriptor can use a 32-bit magic number as the entry identification field for a custom network modality, and the number of fields indicates the number of subsequent field definitions. Field 1, Field 2, Field 3, etc., can be added or removed according to specific industry protocols. The Cyclic Redundancy Check (CRC) field can be used to verify the integrity of the configuration descriptor.

[0077] Table 2 shows a UDM field definition format.

[0078] Table 2 is a schematic table of a UDM field definition format provided in the embodiments of this application. As shown in Table 2, each UDM field definition may include a field ID, a start offset, a field length, and a semantic type. The field ID is used to distinguish different custom fields. The start offset indicates the offset of the field relative to the start position of the message. The field length indicates the number of bytes or bits occupied by the field. The semantic type indicates whether the field participates in atomic operations such as exact matching, range matching, field replacement, or multicast replication.

[0079] In an alternative embodiment, the UDM configuration file can be represented in XML format: <udm_pipeline> <header name="magic" offset="0" length="4" value="0x55AA0001" match="exact">< / header> <field name="device_id" offset="4" length="4" type="exact" / > <field name="cmd" offset="8" length="2" type="range" range="0x01-0x0F" / > <action type="multicast" ports="2,3,4" / > < / udm_pipeline> In the configuration file described above, the `magic` field is used to identify UDM messages, the `device_id` field is used for precise device identification matching, the `cmd` field is used for command range matching, and the `action` field is used to define the multicast replication port. This configuration file can be written into the configuration RAM of the UDM parser through the modal configuration interface module. The parser updates the field definitions and action pipeline accordingly to achieve customized forwarding for industrial control modes, experimental network modes, or dedicated observation device protocols.

[0080] In specific embodiments, when the user configuration file only involves changes in field offsets, field lengths, or action combinations, updates can be completed by writing to the configuration register. For example... Figure 3 As shown, when the user configuration file involves a new hardware pipeline structure or a new forwarding atomic operation IP core, the dynamic reconfigurable area controller 210 in the cooperative control module 21 can be triggered to update the part of the hardware logic corresponding to the custom network mode processing module 225 online.

[0081] Therefore, the custom network modality processing module 225 can adapt to lightweight protocol changes through configuration registers, and also adapt to larger hardware logic changes through partial reconfiguration of the FPGA, enabling the multimodal network coexistence system to continuously expand for specific industry protocols.

[0082] In one optional embodiment, based on the operating status of multiple network modality processing modules, the output control of the target processing message is performed by a collaborative control module, including: Obtain the buffer queue depth corresponding to each network modality processing module; Based on the depth of each buffer queue, determine the scheduling weight and shared buffer allocation capacity corresponding to each network modality processing module; Based on the scheduling weight, the target processing message is output scheduled; when the buffer queue depth corresponding to the target network modality processing module exceeds the preset queue threshold, the scheduling weight corresponding to the target network modality processing module is increased, and / or the shared buffer allocation capacity corresponding to the target network modality processing module is increased.

[0083] In one alternative embodiment, such as Figure 3 As shown, the collaborative control module 21 may include a unified scheduling arbitrator 212 and a shared storage management unit 211. The unified scheduling arbitrator 212 is used to coordinate access to the output ports of each network mode processing module 22. The shared storage management unit 211 is used to divide each network mode processing module 22 into independent logical storage partitions and set up cross-mode shared buffers. Each network mode processing module 22 can report the buffer queue depth to the collaborative control module 22, and the collaborative control module 21 uses this information to determine whether a certain mode is showing a congestion trend.

[0084] Table 3 shows a hybrid priority polling time slot allocation table.

[0085] Table 3 shows a hybrid priority polling time slot allocation table provided in an embodiment of this application. As shown in Table 3, in an optional embodiment, the unified scheduling arbitrator 212 can adopt a hybrid priority polling mechanism. Each scheduling period can be 1 microsecond and divided into 10 time slots. Time slots Ts0 and Ts5 are fixedly reserved for the GEO mode to meet the deterministic transmission requirements of the GEO satellite link. The remaining time slots are allocated to the NDN, MobilityFirst, IPv4, IPv6, and UDM modes according to a weighted round-robin (WRR) method. The default weights can be set to NDN: 2, MobilityFirst: 1, IPv4: 1, IPv6: 1, and UDM: 1.

[0086] In one optional embodiment, when the buffer queue depth corresponding to a target network modality processing module exceeds a preset queue threshold, such as exceeding 64 packets, the unified scheduling arbitrator 212 can temporarily increase the scheduling weight corresponding to the target network modality processing module, and / or the shared storage management unit 211 can increase its shared buffer allocation capacity. In another optional embodiment, when the queue depth drops below a recovery threshold, such as less than 32 packets, the default weight can be restored. The above thresholds can be configured according to FPGA resources, port rates, and service models, and are not limited in this application.

[0087] In an optional embodiment, the shared storage management unit 211 can provide a 512KB cross-modal shared buffer, initially allocating 32KB of capacity to each modality, and checking the buffer occupancy of each modality every 10 microseconds. When a modality's occupancy exceeds 80% of its quota, 16KB can be transferred from the unoccupied modality's quota to that modality. The shared storage management unit 211 can be linked with the unified scheduling arbitrator 212 via a hardware handshake signal, so that the increase in scheduling weight and the increase in buffer capacity take effect simultaneously.

[0088] Therefore, the collaborative control module 22 can output control of the target processing message according to the real-time operating status of each mode, and while ensuring the retention of time slots in GEO, it can dynamically allocate and suppress local congestion caused by sudden traffic through WRR and shared buffer.

[0089] Figure 4 The schematic diagram of a multimodal network coexistence system provided in another embodiment of this application shows that, in an optional embodiment, the dynamic reconfigurable region controller 210 multimodal network coexistence system includes multiple FPGA processing nodes, and the FPGA processing nodes of the dynamic reconfigurable region controller 210 are connected to each other through a chip interconnect module. The Dynamically Reconfigurable Area Controller 210 chip interconnect module is used to forward messages to be processed between different FPGA processing nodes; The dynamic reconfigurable area controller 210 collaborative control module determines the target FPGA processing node based on the operating status of each FPGA processing node, and controls the dynamic reconfigurable area controller 210 chip interconnect module to send the dynamic reconfigurable area controller 210 message to be processed to the target FPGA processing node.

[0090] like Figure 4 As shown, based on the above embodiments, the collaborative control module 22 may further include a dynamic reconfigurable region controller 210. The dynamic reconfigurable region controller 210 is used to manage the reconfigurable regions of the FPGA and supports online loading or updating of the hardware forwarding logic module of any mode without interrupting the operation of other modes.

[0091] In a specific embodiment, the FPGA dynamic region can be divided into six reconfigurable partitions: RP_NDN, RP_MF, RP_GEO, RP_IP4, RP_IP6, and RP_UDM, each corresponding to a network mode. A portion of the bitstream file can be stored in QSPI Flash. When a certain mode logic needs to be updated, the dynamic reconfigurable region controller 210 reads the corresponding portion of the bitstream file via AXI DMA and then writes it to the configuration layer with an 8-bit, 16-bit, or 32-bit word width via the Internal Configuration Access Port (ICAP).

[0092] In one optional embodiment, the time for a complete reconfiguration of the UDM partition can be 8.7 milliseconds, meeting the requirement that the single reconfiguration time is less than 10 milliseconds. During the reconfiguration process, the reconfigurable partitions corresponding to the other five modes remain operational, and input packets can be temporarily stored in a shared buffer. Therefore, when a custom network mode needs to add a new forwarding atomic operation IP core, or when modes such as NDN and GEO need to update specific lookup logic, the corresponding partitions can be updated online without completely restarting the entire FPGA system.

[0093] like Figure 4 As shown, in some embodiments, the multimodal network coexistence system can also support the collaborative expansion of multiple FPGA chips through a high-speed switching chip. Multiple FPGA chips can be interconnected through a high-speed switching chip to form a multi-FPGA cluster. Each FPGA chip can internally contain a message processing module 20, multiple network modality processing modules 21, and a collaborative control module 22. The FPGA chips in the cluster can be configured as master node FPGAs and multiple slave node FPGAs. The master node FPGA is responsible for global load balancing, cross-FPGA task allocation, and distributed routing table synchronization, while the slave nodes are responsible for local message processing.

[0094] In one alternative embodiment, the high-speed switching chip can be an Ethernet switching chip or a PCIe switching chip, used to provide inter-chip data channels. Each FPGA chip can encapsulate an inter-chip communication protocol interface, supporting cross-chip packet forwarding, distributed routing table synchronization, and modal configuration consistency maintenance. The inter-chip communication protocol interface can employ lightweight pipelined encapsulation, supporting packet fragmentation and reassembly, distributed hash table synchronization, and heartbeat detection. For ease of understanding, an alternative embodiment of a 4-node cluster will be described below.

[0095] For example, in a specific embodiment of a 4-node cluster, the master node FPGA can be a Xilinx Virtex UltraScale+VU13P, responsible for global load balancing, distributed routing table synchronization, and cross-node task allocation. The master node also contains a complete six-modal processing pipeline. The three slave node FPGAs can be Xilinx Zynq UltraScale+XCZU9EG, each containing a six-modal processing pipeline, but configured to enable only some modes. For example, the first slave node FPGA uses NDN and IPv4, the second slave node FPGA uses GEO and MobilityFirst, and the third slave node FPGA uses UDM and IPv6. The high-speed switching chip can be a 12.8Tbps switching chip, connecting the four FPGAs through 28 100GbE ports. Each FPGA uses four 100GbE ports, resulting in a total inter-chip link bandwidth of 400Gbps and an end-to-end transmission latency of less than 200 nanoseconds.

[0096] After the system powers on, the master node FPGA can first complete its own configuration, and then broadcast configuration commands through the high-speed switching chip to load the corresponding bit streams of each slave node into their respective FPGAs in sequence. The master node FPGA can send a heartbeat packet every 1 millisecond through the inter-chip communication protocol to monitor the status of each slave node. The distributed routing table can initially be distributed by the master node, and each slave node maintains a local cache. When the routing table is updated, the master node can push incremental updates through multicast.

[0097] Based on the aforementioned 4-node cluster, in a specific implementation of cross-chip packet processing, an external network receives an NDN interest packet with the target content name prefixed with / ndn / camera / video. This interest packet is received by the master node FPGA. The multimodal packet recognition engine 200 in the master node FPGA determines that the packet is in NDN mode. Subsequently, the NDN network mode processing module 220 searches the forwarding information database and finds that the next-hop content source corresponding to this name prefix is ​​located in the NDN network connected to the first slave node FPGA. At this time, the unified scheduling arbitrator 212 of the master node FPGA identifies that the packet needs to be forwarded across chips, encapsulates the packet into an inter-chip communication protocol frame, adds the target node ID and sequence number, and sends it to the first slave node FPGA through a high-speed switching chip. After receiving the inter-chip frame, the first slave node FPGA decapsulates and restores the original NDN interest packet, and re-enters its internal multimodal packet recognition engine 200 for local NDN forwarding.

[0098] In a specific embodiment of a load balancing test, 100Gbps of mixed traffic was injected into a 4-node cluster, with randomized proportions of each modality. The master node FPGA monitored the queue depth of each slave node. Initially, tasks were evenly distributed. When the GEO modality queue depth of the second slave node FPGA exceeded 64 entries, the master node FPGA automatically distributed subsequent GEO tasks to both the master node FPGA and the third slave node FPGA, while simultaneously increasing the shared buffer weight of the second slave node FPGA. The adjustment period could be 10 microseconds. Test results showed that the queue depth of each node could be stably controlled between 32 and 96, the global throughput reached 360Gbps, and the cross-chip processing latency increase was less than 100 nanoseconds.

[0099] In a specific embodiment of a failover test, a power failure of the master node FPGA is simulated. After three consecutive heartbeat timeouts (3 milliseconds), the remaining slave nodes automatically initiate an election. The first slave FPGA node can be elected as the new master node based on a preset priority, such as the smallest node ID. The new master node broadcasts a takeover notification and redistributes the routing table. The entire failover process can take 0.8 milliseconds. During this time, incoming packets are temporarily stored in the buffer of the high-speed switching chip and continue processing after the failover is complete. Thus, the multi-FPGA collaborative expansion structure can improve overall throughput while maintaining high cluster availability.

[0100] In one optional embodiment, using the multimodal network collaborative processing method of this application, under multimodal mixed traffic injection conditions, NDN interest packets account for 20%, MobilityFirst data accounts for 30%, GEO telemetry flow accounts for 10%, IPv4 packets account for 20%, IPv6 packets account for 10%, and UDM customized control flow accounts for 10%. Under the above traffic model, the system has no packet loss, the buffer queue depth of all modalities does not exceed the threshold, and the scheduling fairness index Jain's index reaches 0.97.

[0101] In a specific embodiment of cross-modal cooperative forwarding, taking NDN over MobilityFirst over GEO as an example, after the Ethernet interface receives an NDN interest packet, the multimodal packet identification engine 200 determines that it is in NDN mode. The NDN parser extracts the name prefix, and the NDN network mode processing module 220 searches the forwarding information database to determine that the next-hop domain is the MobilityFirst network. Subsequently, the cross-modal forwarding cooperative submodule is started, encapsulating the entire NDN interest packet into a MobilityFirst datagram, setting the service type to content request, and the destination GUID can be generated as a 160-bit GUID by hashing the name prefix, while the source GUID can be mapped from the local device's NA.

[0102] The encapsulated message can re-enter the multimodal message recognition engine 200 and be identified as MobilityFirst mode. The MobilityFirst network mode processing module 221 performs a GUID-to-NA lookup to obtain the next-hop NA belonging to the GEO satellite node. At this point, cross-modal cooperation is triggered again, encapsulating the MobilityFirst message into a GEO link frame and adding a GEO control header, which may include a delay flag and a link ID. The GEO network mode processing module 222 performs delay buffering on the message and sends it in a reserved time slot. At the remote node, the encapsulation can be decapsulated layer by layer in reverse order to finally recover the NDN interest packet and forward it to the content provider. In the entire process, the hardware cooperation submodule completes three layers of encapsulation and address mapping, and the total processing latency can be increased by only about 30ns.

[0103] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 5 As shown, the electronic device includes: a memory 50 for storing computer programs; The processor 51 is used to implement the steps of the multimodal network collaborative processing method mentioned in the above embodiments when executing a computer program.

[0104] The electronic devices provided in this embodiment may include, but are not limited to, laptops or desktop computers.

[0105] The processor 51 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 51 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 51 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 51 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 51 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0106] The memory 50 may include one or more computer-readable storage media, which may be non-transitory. The memory 50 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 50 is used to store at least the following computer program 501, which, after being loaded and executed by the processor 51, can implement the relevant steps of the multimodal network cooperative processing method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 50 may also include an operating system 502 and data 503, and the storage method may be temporary or permanent storage. The operating system 502 may include Windows, Unix, Linux, etc. The data 503 may include, but is not limited to, the relevant data involved in the multimodal network cooperative processing method.

[0107] In some embodiments, the electronic device may further include a display screen 52, an input / output interface 53, a communication interface 54, a power supply 55, and a communication bus 56.

[0108] Those skilled in the art will understand that Figure 5 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0109] The electronic device provided in this application includes a memory and a processor. When the processor executes the program stored in the memory, it can implement the multimodal network collaborative processing method described in the above embodiments.

[0110] It should be noted that although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Claims

1. A multimodal network collaborative processing method, characterized in that, An application is made in a multimodal network coexistence system, the system comprising: a message processing module, multiple network mode processing modules, and a cooperative control module implemented based on configurable hardware logic in an FPGA; the message processing module and the cooperative control module are each connected to the multiple network mode processing modules; the method includes: The message processing module determines the input network mode of the acquired input message; From the plurality of network mode processing modules, determine the target network mode processing module corresponding to the input network mode; The forwarding strategy for the input packet is determined by the target network mode processing module; the forwarding strategy includes the target forwarding network mode. Based on the forwarding strategy, determine whether the target forwarding network mode is consistent with the input network mode; If there is a discrepancy, the corresponding network modality processing module is controlled by the collaborative control module to perform network modality conversion on the input message to obtain the target processing message; and the output control of the target processing message is performed by the collaborative control module according to the operating status of the multiple network modality processing modules.

2. The multimodal network collaborative processing method as described in claim 1, characterized in that, The plurality of network modality processing modules include at least two of the following: NDN network modality processing module, MobilityFirst network modality processing module, GEO network modality processing module, IPv4 network modality processing module, IPv6 network modality processing module, and custom network modality processing module; The multiple network modality processing modules are implemented based on dedicated hardware forwarding logic in the FPGA, and process the packets of the corresponding network modality in parallel.

3. The multimodal network collaborative processing method as described in claim 1, characterized in that, The message processing module includes a multimodal message recognition engine and a protocol parsing and reconstruction array; The step of determining the input network mode of the acquired input message through the message processing module includes: The multimodal message recognition engine extracts protocol feature fields from the input message; Based on the protocol feature fields, network mode matching is performed on the input message; If at least two candidate network modes are matched, the input network mode is determined from the at least two candidate network modes according to a preset mode priority.

4. The multimodal network collaborative processing method as described in claim 3, characterized in that, The preset modal priorities include a decreasing priority order of custom network modality, named data network modality, mobile-first network modality, geostationary orbit satellite network modality, IPv6 network modality, and IPv4 network modality.

5. The multimodal network collaborative processing method as described in claim 3, characterized in that, Before determining the target network mode processing module corresponding to the input network mode from the plurality of network mode processing modules, the method further includes: The array is reconstructed by parsing the protocol, and the corresponding hardware parser is invoked according to the input network mode. The hardware parser extracts the structured forwarding fields required by the target network modality processing module to perform forwarding decisions from the input packet. The structured forwarding field is sent to the target network modality processing module.

6. The multimodal network cooperative processing method as described in claim 2, characterized in that, The step of determining the forwarding strategy of the input packet through the target network modality processing module includes: When the target network mode processing module is the NDN network mode processing module, the name information of the input packet is matched by a two-level Bloom filter lookup structure; and the next hop information or content response mode of the input packet is determined by the undecided interest table hardware maintenance logic and content storage fast retrieval circuit, so as to determine the forwarding strategy. When the target network mode processing module is the MobilityFirst network mode processing module, the network address mapping relationship of the input packet is determined by binding the network address to a globally unique identifier and a cache; and the next-hop information is determined by an intra-domain routing lookup engine based on the network address, so as to determine the forwarding strategy.

7. The multimodal network cooperative processing method as described in claim 2, characterized in that, The step of determining the forwarding strategy of the input packet through the target network modality processing module includes: When the target network mode processing module is the GEO network mode processing module, the transmission path and transmission time slot of the input packet are determined by the delay compensation submodule, the link budget submodule, and the routing calculation submodule, so as to determine the forwarding strategy; The delay compensation submodule calculates the link delay corresponding to the satellite link based on ephemeris data, and adjusts the transmission scheduling time slot of the input message according to the link delay.

8. The multimodal network cooperative processing method as described in claim 2, characterized in that, The step of determining the forwarding strategy of the input packet through the target network modality processing module includes: When the target network mode processing module is the IPv4 network mode processing module or the IPv6 network mode processing module, the input packet is routed using a routing lookup engine based on TCAM or Bloom filter enhanced hash table to determine the forwarding strategy; The IPv4 network mode processing module and the IPv6 network mode processing module support bidirectional tunnel encapsulation conversion between IPv4 packets and IPv6 packets.

9. The multimodal network collaborative processing method as described in claim 2, characterized in that, The step of determining the forwarding strategy of the input packet through the target network modality processing module includes: When the target network mode processing module is the custom network mode processing module, the forwarding pipeline processing is performed according to the preset forwarding atomic operation IP core and user configuration file to determine the forwarding strategy; The user configuration file is used to define the forwarding pipeline of the custom network mode and write it into the configuration register of the custom network mode processing module, and / or to trigger the cooperative control module to update the hardware logic corresponding to the custom network mode processing module.

10. The multimodal network collaborative processing method as described in claim 1, characterized in that, The step of controlling the output of the target processing message through the collaborative control module based on the operating status of the multiple network modality processing modules includes: Obtain the buffer queue depth corresponding to each of the network modality processing modules; Based on the depth of each buffer queue, determine the scheduling weight and shared buffer allocation capacity corresponding to each network modality processing module; The target processing message is output and scheduled according to the scheduling weight; Specifically, when the depth of the buffer queue corresponding to the target network modality processing module exceeds a preset queue threshold, the scheduling weight corresponding to the target network modality processing module is increased, and / or the allocated capacity of the shared buffer corresponding to the target network modality processing module is increased.

11. The multimodal network cooperative processing method as described in claim 1, characterized in that, The multimodal network coexistence system includes multiple FPGA processing nodes, which are connected to each other via a chip interconnect module. The chip interconnect module is used to forward messages to be processed between different FPGA processing nodes; The collaborative control module determines the target FPGA processing node based on the operating status of each FPGA processing node, and controls the chip interconnect module to send the message to be processed to the target FPGA processing node.

12. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multimodal network collaborative processing method according to any one of claims 1 to 11.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the multimodal network collaborative processing method according to any one of claims 1 to 11.

Images