EBPF-based VXLAN tunnel forward error correction method and device capable of being used for FTTR, equipment and medium

Abstract

The invention discloses an eBPF-based VXLAN (Virtual eXtensible Local Area Network) tunnel forward error correction method, an eBPF-based VXLAN tunnel forward error correction device, eBPF-based VXLAN tunnel The method comprises the following steps: dividing a plurality of continuous original data packets with the same flow identifier into a data group according to a preset packet size, allocating a group identifier to the data group, and allocating a continuous intra-group serial number to each original data packet in the group; generating a grouping context of the data group based on the load data of all the original data packets in the data group, and inserting a first forward error correction head into each original data packet; when the number of the data packets in the data group reaches the packet size, taking the packet context as load data, generating a redundant data packet, and inserting a second forward error correction header into the redundant data packet; and injecting the redundant data packet into which the second forward error correction header is inserted into a sending queue, so that the redundant data packet and the original data packet into which the first forward error correction header is inserted are subjected to VXLAN packaging and sent together, and reliable transmission of the VXLAN tunnel is realized.

Description

Technical Field

[0001] This article relates to network communication technologies, and in particular to a method, apparatus, device and medium for forward error correction of VXLAN tunnels based on eBPF that can be used for FTTR. Background Technology

[0002] With the continuous expansion of cloud computing and data center networks, Virtual Extended Local Area Network (VXLAN), as a mainstream overlay network tunneling technology, has been widely used to achieve multi-tenant isolation and network expansion in large-scale virtual networks. VXLAN encapsulates data at the transport layer based on the User Datagram Protocol (UDP), and does not inherently provide reliable transmission guarantees. In real-world network environments, especially within cloud computing data centers where network congestion, transient link jitter, or partial equipment failures exist, data packets transmitted via VXLAN tunnels may be lost.

[0003] The loss of data packets can directly impact various critical applications running on overlay networks. For example, synchronization operations in distributed databases may be delayed or fail due to packet loss, data processing pipelines in real-time computing frameworks (such as Spark Streaming and Flink) may experience interruptions, and order synchronization and confirmation in financial trading systems may time out. These impacts manifest as decreased application performance, increased transaction processing latency, and reduced overall system stability.

[0004] To enhance the reliability of data transmission, the industry has proposed several solutions based on forward error correction (FEC) technology, mainly including the following: 1. Application-layer FEC scheme: This scheme implements the FEC encoding and decoding logic within the user-space application. Data packets need to be copied and context-switched multiple times between kernel space and user space to complete FEC processing. This method introduces significant performance overhead and processing latency, making it difficult to meet the stringent throughput and latency requirements of modern data center high-speed network forwarding.

[0005] 2. Hardware Offloading FEC Solution: This solution relies on smart network interface cards or switching chips equipped with dedicated FEC codec engines to offload FEC computing tasks to hardware execution. While offering high performance, this solution is costly, and its functionality is typically fixed in the hardware, lacking deployment flexibility and unable to adapt to rapidly changing network policies and diverse business needs in cloud-native environments.

[0006] 3. Kernel Module FEC Solution: This solution implements FEC functionality in kernel space by writing a Linux kernel module. Although its performance is superior to application-layer solutions, the development, debugging, and maintenance of kernel modules are extremely difficult. Furthermore, kernel modules are strongly coupled to specific Linux kernel versions; upgrading the kernel may render the module unusable, posing a risk to system stability. They also typically do not support dynamic loading and unloading, resulting in insufficient flexibility.

[0007] In summary, existing VXLAN tunnel reliability enhancement solutions have shortcomings in terms of performance overhead, deployment flexibility and cost, system stability, and dynamic maintainability. Therefore, a new technical solution is urgently needed to address these issues. Summary of the Invention

[0008] This application provides an eBPF-based VXLAN tunnel forward error correction method, apparatus, device, and medium that can be used for FTTR.

[0009] A forward error correction method based on eBPF for FTTR in a VXLAN tunnel is applied to a first eBPF functional unit in the transmitting end of the VXLAN tunnel, wherein the first eBPF functional unit is attached to a hook point at the flow control (TC) exit of the VXLAN network device, the hook point being located before VXLAN encapsulation. The method includes: According to the preset group size, multiple consecutive raw data packets with the same flow identifier are divided into a data group, a group identifier is assigned to the data group, and a consecutive intra-group sequence number is assigned to each raw data packet in the group. The packet context of the data group is generated based on the payload data of all the original data packets in the data group, and a first forward error correction header is inserted after the network layer header of each original data packet. The type field of the first forward error correction header identifies the data packet as an original data packet and includes its group identifier and the sequence number within the group. When the number of data packets in the data group reaches the group size, the group context is used as the payload data to generate redundant data packets. A second forward error correction header is inserted after the network layer header of the redundant data packet. The type field of the second forward error correction header identifies the data packet as a redundant data packet and includes its group identifier. The redundant data packet with the second forward error correction header is injected into the transmission queue, and then encapsulated and transmitted together with the original data packet with the first forward error correction header.

[0010] A forward error correction method for tunnels in VXLAN based on eBPF, applicable to FTTR, is applied to a second eBPF functional unit in the receiver of a VXLAN tunnel. This second eBPF functional unit is located in the Linux kernel and is mounted to a hook point at the flow control (TC) entry point of the VXLAN network device, located after VXLAN decapsulation. The method includes: Identify whether the received data packet contains a forward error correction header; If the received data packet carries a first forward error correction header with a type field that identifies the data packet as an original data packet, then the group identifier and the sequence number within the group are obtained from the first forward error correction header, and the arrival status and storage location corresponding to the sequence number within the group are recorded in the reassembly context corresponding to the group identifier. If the received data packet carries a type field that identifies the data packet as a redundant data packet, then its group identifier is obtained from the second forward error correction header, and the storage location of the redundant data packet is recorded in the reassembly context corresponding to the group identifier. Monitor the number of cached original data packets and redundant data packets in the reassembly context. When the total number of cached original data packets and redundant data packets is greater than or equal to the total number of original data packets, check whether there are original data packets with missing group sequence numbers. If there are data packets with missing group sequence numbers, perform decoding operations based on the cached original data packets and redundant data packets to restore the original payload of the missing original data packets. The packets are reconstructed based on the recovered original payload, and the reconstructed packets are then re-injected into the kernel network protocol stack.

[0011] A tunnel forward error correction device in a VXLAN based on eBPF that can be used for FTTR includes a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described above.

[0012] A storage medium storing a computer program, wherein the computer program is configured to execute the method described above when run.

[0013] A tunnel forward error correction device in VXLAN based on eBPF that can be used for FTTR includes: The sending module is used to execute the methods described above; The receiving module is used to execute the method described above.

[0014] This application's embodiments attach a lightweight eBPF functional unit to the TC egress point, performing real-time processing at the optimal time before packet VXLAN encapsulation. This avoids the huge overhead of user-mode-kernel-mode switching and effectively solves the performance bottleneck problem of application-layer FEC schemes. Utilizing the dynamic loading and security verification characteristics of eBPF technology, it eliminates the need to modify the Linux kernel source code or restart the system, completely overcoming the systemic risks of difficult development and maintenance of kernel module FEC schemes and strong coupling with kernel versions. By inserting a customized FEC header at the IP layer and ensuring that all processing is completed before the standard VXLAN encapsulation process, neither upper-layer applications nor the underlying physical network need to be aware of the existence of this reliability enhancement mechanism, providing a seamless user experience and eliminating the high cost and architectural rigidity problems caused by hardware offloading FEC schemes.

[0015] The lightweight eBPF functional unit is mounted on the TC ingress hook point of the VXLAN network device and immediately identifies, classifies, and manages the status of data packets after VXLAN decapsulation. Real-time recovery is triggered based on the number of arriving packets, ensuring that packet loss detection, recovery decisions, and decoding operations are all completed in-situ on the last kernel path before the data packet reaches the application, avoiding the latency caused by sending data packets to user space for processing. The quantity-triggered mechanism enables recovery to start as soon as sufficient information is received, minimizing recovery waiting time, thus achieving near real-time packet loss masking and data recovery. This significantly reduces the end-to-end latency jitter and performance impact of packet loss on upper-layer applications (such as distributed databases and real-time computing), fundamentally overcoming... Overcoming the shortcomings of slow recovery and delayed response in application-layer FEC schemes, the second eBPF functional unit carries the complete FEC decoding, state management, and packet reconstruction logic on the receiving side, significantly reducing the development and maintenance complexity of kernel-mode functions on the receiving side. It completely avoids the stability risks and strong version coupling problems that also exist in traditional kernel modules on the receiving end. Identification and state management are performed by parsing the FEC header inline in the data packet. After recovery, the data packet with the standard protocol header is reconstructed and re-injected into the kernel network protocol stack for subsequent processing. The recovery process relies entirely on the FEC header information and reconstructing context carried by the data packet itself, without relying on any dedicated hardware.

[0016] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0017] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0018] Figure 1 A flowchart illustrating a tunnel forward error correction method in a VXLAN based on eBPF that can be used for FTTR, provided in an embodiment of this application; Figure 2 A flowchart illustrating another tunnel forward error correction method in VXLAN based on eBPF that can be used for FTTR, provided in an embodiment of this application. Figure 3 This is a schematic diagram of the structure of a tunnel forward error correction device in a VXLAN based on eBPF that can be used for FTTR, as provided in an embodiment of this application. Detailed Implementation

[0019] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0020] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0021] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0022] In existing technologies, VXLAN tunnels, being based on UDP, lack reliable transmission guarantees, and packet loss can severely impact critical upper-layer applications. Whether it's application-layer FEC introducing significant latency, costly and fixed hardware FEC, or kernel module FEC with its difficult development and maintenance, none can achieve a satisfactory balance between high performance, high flexibility, deployment transparency, and low cost. The fundamental reason is that traditional solutions fail to organically combine dynamically programmable processing logic, critical processing timings in the kernel protocol stack, and lightweight encapsulation that is transparent to business logic.

[0023] Therefore, the VXLAN tunnel forward error correction method based on Extended Berkeley Packet Filter (eBPF) described in this application is fundamentally based on constructing a transparent, high-performance, and dynamically adjustable kernel-mode reliability enhancement layer. The specific implementation of this method relies on the following synergistic technical framework and features, which directly address and aim to resolve the various deficiencies pointed out in the background art: 1. Functional unit implementation based on eBPF technology: The method is executed by a "first eBPF functional unit" and a "second eBPF functional unit" running in the Linux kernel. eBPF technology allows user-defined, rigorously security-verified bytecode programs to be dynamically loaded and run in kernel mode without modifying the kernel source code or restarting the system. This feature directly solves the problems faced by the "kernel module FEC solution," such as high development and maintenance difficulty, strong coupling with kernel versions, stability risks, and inability to hot-upgrade. Implementing FEC logic using eBPF achieves high performance similar to kernel modules while gaining development flexibility and deployment security similar to user-mode programs, supporting dynamic loading, unloading, and updates, thus achieving a balance between stability and flexibility.

[0024] 2. Mount at a specific hook point in the Traffic Control (TC) subsystem: The first eBPF functional unit at the sending end is precisely mounted at the TC egress hook point of the VXLAN network device, and this point is located before the VXLAN encapsulation operation; the second eBPF functional unit at the receiving end is mounted at the TC ingress hook point, and is located after the VXLAN decapsulation operation. This precise mounting position design fundamentally solves the problem of huge performance overhead and processing latency caused by application layer FEC schemes due to packets crossing the kernel / user space boundary multiple times. All FEC processing (encoding, decoding, packet recovery) is completed in-situ on the critical path of packet flow in the kernel protocol stack, realizing zero-copy or minimal-copy in-kernel processing, thereby meeting the extreme requirements of throughput and latency for high-speed data forwarding.

[0025] 3. Transparent embedding of the VXLAN tunnel encapsulation / decapsulation process: The method explicitly limits FEC processing to "before VXLAN encapsulation" and "after VXLAN decapsulation." This means that the FEC encoding process operates on the original, unencapsulated inner data packets, while the FEC decoding and recovery process operates on the decapsulated, original inner data packets. This design ensures that the entire FEC mechanism is completely transparent to upper-layer applications using VXLAN tunnels. Applications can achieve enhanced transmission reliability without being aware of or making any modifications, effectively solving the deployment complexity and business intrusion issues faced by solutions relying on "hardware offloading FEC schemes" or those requiring application-layer cooperation.

[0026] In summary, this application constructs an innovative solution by organically combining eBPF kernel programmable technology, precise mount points at the TC layer, transparent VXLAN encapsulation timing embedding, and software-defined programmable control. This solution aims to simultaneously address core issues in existing technologies, such as high latency and performance degradation, high cost and insufficient flexibility, complex development and maintenance, system stability risks, and lack of transparency to applications. Therefore, it provides a practical and feasible technical path for achieving high-performance, highly flexible, and low-cost transparent VXLAN tunnel reliability enhancement.

[0027] In an eBPF-based forward error correction system, core data structures for recording and processing packet states are maintained at the system level. This embodiment defines two core context structures: packet context and reassembly context. They are stored in the eBPF mappings at the sending and receiving ends, respectively, and together with the FEC header, they achieve stateful and efficient streaming forward error correction processing.

[0028] Explanation regarding the grouping context: The packet context is a state record maintained by the first eBPF functional unit at the sender for each data group undergoing FEC encoding. This packet context contains the following fields to support basic streaming redundancy calculations: Cumulative Redundancy Check Value Field: A variable (e.g., an integer or byte array) used to temporarily store and update intermediate redundancy check results. This field is updated in real time as each raw data packet within the group is processed.

[0029] Packet count field: A counter used to record the number of raw packets that have been processed and sent within the current data group.

[0030] To improve performance, support more complex algorithms, or enhance reliability, the grouping context may also include the following optional fields: Hash storage array: An array used to store the hash value of the payload of each processed raw packet within the group. This can be used for fast consistency checks or to assist debugging.

[0031] Timestamp field: Records the time when this context was created or last updated, used to implement a timeout cleanup mechanism to prevent memory leaks.

[0032] Its role and workflow on the sending side: State storage and iterative calculation: When a packet arrives at the TC egress hook point, the first eBPF functional unit looks up the corresponding packet context in the eBPF mapping. Using the redundancy check value accumulation field in this context as a basis, iterative calculation is performed in conjunction with the current packet load, and the new result is written back to this field. At the same time, the packet count field is incremented.

[0033] Triggering Redundant Packet Generation: Continuously check the packet count field. When the count reaches the preset packet size K, the processing of that group of data is considered complete. At this point, the redundancy check value accumulation field stores the complete redundancy check value of that group of data. This final value is then read and used to generate redundant data packets, where K is an integer greater than or equal to K.

[0034] Lifecycle management: After redundant data packets are generated and sent, the corresponding packet context has completed its mission. User-space management processes or kernel-timed tasks can safely clean up these contexts to release memory resources based on timestamp fields or direct deletion policies.

[0035] Please explain the context of the reorganization: The reassembly context is a state record maintained by the receiver's second eBPF functional unit for each data group to be recovered. This context contains the following fields to support basic packet reassembly and loss detection: Packet arrival status record field: A data structure used to record whether each raw packet in a group has arrived successfully. For example, a bitmap of length K (group size), where each bit corresponds to a sequence number (seq), and setting it to 1 indicates that the packet has arrived.

[0036] Packet cache reference field: A mechanism for temporarily holding or referencing the payload data of arriving packets. For example, an array of pointers where the index corresponds to the sequence number and the elements point to the location of the cached packet payload in the kernel.

[0037] To support efficient recovery, resource management, or advanced features, the reorganization context may also include the following optional fields: Redundant Packet Cache Reference Field: A field specifically used to store references to the payloads of arrived redundant packets.

[0038] Arrival packet counter: A field that counts the arrival of raw and redundant data packets separately or in aggregate, used to quickly determine whether the recovery conditions are met.

[0039] Timestamp field: Records the time when this context was created or when it last received a data packet from within the group, used to implement a timeout cleanup mechanism.

[0040] Its role and workflow on the receiving side: Status Tracking and Data Convergence: When a packet carrying an FEC header arrives at the TC ingress point, the second eBPF functional unit looks up or creates the corresponding reassembly context in the eBPF mapping of type BPF_MAP_TYPE_LRU_PERCPU_HASH based on its group_id. Based on the packet type (type field) and sequence number (seq field, for the original packet), the corresponding position is marked in the packet arrival status record field, and a pointer to the packet payload is stored in the corresponding slot of the packet buffer reference field.

[0041] Packet loss detection and recovery decision-making: Continuously check the packet arrival status record field. By analyzing the bitmap, it is possible to immediately identify which sequence numbers of original packets have not yet arrived (i.e., lost). At the same time, based on the number of arrived original packets and redundant packets, it is determined in real time whether enough information has been received (e.g., the total number of valid packets received ≥ K) to trigger the recovery process.

[0042] Provides a data source for recovery operations: When recovery conditions are met, the recovery logic directly retrieves the payload pointers of all arriving packets from the packet cache reference field and the redundant packet cache reference field. The kernel data buffers pointed to by these pointers will serve as input for decoding operations, eliminating the need for expensive data copying.

[0043] Efficient resource management and eviction: Using BPF_MAP_TYPE_LRU_PERCPU_HASH mapping to store the reorganization context enables the system to automatically evict the least recently used entry. Combined with proactive timeout cleanup of the timestamp field, this ensures that limited kernel memory resources are used efficiently, preventing memory exhaustion caused by waiting for packets that will never arrive, and guaranteeing long-term system stability.

[0044] To achieve accurate identification, state management, and collaborative encoding and decoding of data packets, this embodiment defines a fixed-length forward error correction header (FEC Header) optimized for the kernel eBPF environment. This header is inserted by the first eBPF functional unit at the sending end and parsed by the second eBPF functional unit at the receiving end.

[0045] The forward error correction header is a fixed-format data structure containing the following fields to ensure that the most basic stream packetization, packet identification, and recovery functions are implemented: Type field: A fixed-length field used to uniquely identify the type of data packet. In this embodiment, at least two type values ​​are defined: a first type value (e.g., 0) is used to identify the original data packet; a second type value (e.g., 1) is used to identify redundant data packets. This field is the primary basis for the receiving end to distinguish processing logic.

[0046] Group ID (group_id): A unique identifier used to mark the logical group to which a data packet belongs. All original data packets belonging to the same data group and their corresponding redundant data packets must carry the same group ID. This field is crucial for the receiving end to reassemble discretely arriving data packets.

[0047] Sequence Number (seq) Field: This field is required for headers of raw data packets and indicates the packet's sequential position within its group (e.g., consecutive numbering starting from 0). For headers of redundant data packets, this field is optional and can be set to a fixed value or omitted depending on the protocol's simplification design.

[0048] To support more efficient decoding algorithms or provide more contextual information, the forward error correction header may also optionally include the following fields: The flow identifier field (flow_id) can directly carry the flow identifier calculated from the 5-tuple. Although the receiver can recalculate it by parsing the original IP / UDP header, carrying this field directly avoids repeated calculation by the receiver's eBPF functional unit, further improving processing performance.

[0049] Total Length (L): Records the total length of the payload of all original data packets within this data group. This allows the receiving end to accurately restore the padded data to its original length when recovering lost packets.

[0050] Count fields: For example, the total number of original packets (K), the total number of redundant packets (M), etc. These can be used for more flexible FEC strategies or more robust receiver verification.

[0051] This header is designed to be of fixed length and is inserted after the network layer (such as IP) header of the data packet and before the transport layer header. The fixed length facilitates fast and secure memory access (fixed offset) for eBPF functional units, meeting the requirements of the eBPF verifier; while the specific insertion position ensures its complete transparency to upper-layer applications (transport layer and above) and lower-layer encapsulation (VXLAN, etc.).

[0052] At the sending end, the first eBPF functional unit inserts an FEC header into each data packet at the TC egress hook point. Its core function is as follows: Injecting packet and sequence semantics: For raw data packets, by setting type=raw data packet, group_id=current group ID, and seq=current sequence number, the originally stateless and independent IP data packets are labeled with explicit group and sequence labels. This essentially artificially constructs logically reliable transport blocks on a connectionless UDP stream through header information.

[0053] Identifying redundant data: For generated redundant data packets, by setting type=redundant packet and group_id=corresponding group ID, it is clearly declared to the receiving end that this packet is not application data, but redundant information used for error correction. This is the foundation for implementing forward error correction.

[0054] Key parameters of the transport algorithm: If a header containing a total length field (L) is used, the sender will fill the calculated total length L of the original data in this group into the header when generating redundant data packets. This allows complex encoding and decoding information that depends on group-level parameters to be transmitted in-band along with the data packets without needing to be synchronized through out-of-band channels, greatly simplifying system design.

[0055] Achieving transparency in the processing flow: Because the header is inserted after the IP header, the standard VXLAN encapsulation process treats it as part of the inner IP packet and encapsulates it accordingly. Therefore, the entire FEC enhancement mechanism is invisible to all subsequent standard network processing flows, achieving true transparent deployment.

[0056] At the receiving end, the second eBPF functional unit parses the FEC header at the TC ingress hook point, and its core function is as follows: Rapid classification and routing: First, the `type` field is read. Based on this field value, the subsequent processing branch can be immediately determined: if it is a raw data packet, the `seq` field is extracted and cached in the corresponding location; if it is a redundant data packet, it is saved as dedicated checksum data. This rapid classification based on a fixed field avoids the overhead of deep data packet parsing and is key to ensuring high-performance kernel processing.

[0057] The index key for the reassembly context: the `group_id` field is the primary key used by the receiver to find or create the corresponding reassembly context (`rx_group_ctx`) in the eBPF Map. The receiver relies on this field to associate data packets arriving at different times that belong to the same logical group, and aggregate them into the same reassembly context for unified management.

[0058] Packet loss detection and recovery are driven by the seq field, which sequence numbers of the original data packets have arrived in the reassembly context. Combined with the known group size (K) and the number of arriving original and redundant data packets (type=redundant data packets), the receiver can determine in real time whether the decoding conditions are met and trigger the recovery process. Header information directly drives the receiver's automated recovery decisions.

[0059] Provides parameters required for decoding: If the header contains a total length field (L), the receiver can directly use this value to accurately extract the actual payload of each original data packet when recovering lost packets, so as to guide the decoding operation and ensure the accuracy of the recovery.

[0060] Example 1 Following the aforementioned technical framework, this embodiment aims to specifically illustrate how to implement a high-performance, transparent VXLAN tunnel forward error correction transmission method through the first eBPF functional unit.

[0061] See Figure 1 The method in this embodiment includes steps 11 to 14.

[0062] Step 11: According to the preset group size, divide multiple consecutive raw data packets with the same flow identifier into a data group, assign a group identifier to the data group, and assign a consecutive intra-group sequence number to each raw data packet in the group.

[0063] The purpose of this step is to establish logical data transmission units, providing an organizational foundation for subsequent collaborative encoding and decoding. Specifically, when a data packet arrives at the TC egress hook point, the first eBPF functional unit first extracts its five-tuple (source / destination IP, port, protocol) and calculates a unique flow identifier (flow_id) to distinguish different application flows or connections. Subsequently, based on a preset fixed number (i.e., packet size K), consecutively arriving data packets belonging to the same flow identifier are grouped into the same group. A unique group identifier (group_id) is generated for this group, and each data packet arriving within the group is sequentially assigned a consecutive intra-group sequence number (seq, such as 0, 1, 2, ..., K-1).

[0064] This step leverages eBPF's high-efficiency execution capabilities to achieve refined flow identification and dynamic packetization on the critical path of packet forwarding with almost zero additional overhead. This avoids the overhead of user-mode to kernel-mode switching and eliminates dependence on specific hardware.

[0065] Through the above steps, an ordered, state-marked transmission context is established for out-of-order kernel network packets. Flow identifiers ensure the isolation of different service flows, while group identifiers and sequence numbers provide precise coordinates for subsequent redundancy calculations and packet loss recovery, laying the structural foundation for the entire forward error correction process.

[0066] Step 12: Generate the packet context of the data group based on all the original data packets in the data group, and insert a first forward error correction header after the network layer header of each original data packet.

[0067] This step accumulates redundant information for the data set and identifies each raw data packet, ensuring the receiver can correctly identify and reassemble them. The implementation involves two parallel processing parts: Generate packet context: As each raw data packet arrives within a group, its payload data is processed in real time, and the intermediate results are accumulated and stored in a memory structure called "packet context".

[0068] Insert a first forward error correction header: After the IP header and before the transport layer header of each raw data packet, insert a first forward error correction header with a fixed format. This header contains at least the following: a type field (identifying that this is a raw data packet), a group_id (group identifier), and a seq (sequence number).

[0069] Unlike existing technologies that place FEC metadata within the application layer payload or rely on hardware encapsulation, this step creatively inserts a lightweight control header specifically designed for eBPF processing at a precise location in the kernel protocol stack (after the IP header). This header has a fixed structure and concise fields, making FEC processing completely transparent to upper-layer protocols with extremely low processing overhead.

[0070] Through the above steps, on the one hand, the streaming computation of redundant information is completed simultaneously with packet forwarding, preparing for the generation of redundant data packets; on the other hand, each original data packet is given a clear identifier. This allows the receiving end to obtain all packet and sequence information of the data packet simply by looking at this header, without the need for deep parsing of the payload, providing key input for efficient and transparent receiver recovery.

[0071] Step 13: When the number of data packets in the data group reaches the group size, the group context is used as the payload data to generate redundant data packets, and a second forward error correction header is inserted after the network layer header of the redundant data packets.

[0072] This step generates redundant data for error correction based on accumulated group information and assigns it an identifier. Specifically, when it detects that K raw data packets have been collected within a group (i.e., the group size has been reached), it first reads the final calculation result (i.e., the complete redundancy check value) of the "packet context" generated for the group in step 12. Then, it uses the packet context as payload data to generate one or at least two redundant data packets. Finally, after the IP header of each redundant data packet, a "second forward error correction header" is inserted, whose type field identifies it as a redundant data packet and includes the group_id.

[0073] Compared to the application layer's requirement to construct entirely new packets or the need for hardware solutions to solidify functionality when generating redundant data packets, this step fully utilizes the eBPF program's ability to directly manipulate the data packet buffer in the kernel. It uses the packet context as payload data to generate redundant data packets and inserts a special type of header into the redundant data packets, enabling the receiving end to clearly distinguish them from the original data packets and manage them equally.

[0074] Through the above steps, redundant data packets carrying error correction information for the entire data set are efficiently generated. After this packet is sent together with the original data packets, at the receiving end, if any original data packets are lost, the payload data of the lost data packets can be recovered based on the redundant data packets corresponding to the lost data packets and the original data packets associated with the redundant data packets. This gives it the ability to withstand a certain packet loss rate and realizes the core function of forward error correction.

[0075] Step 14: Inject the redundant data packet with the second forward error correction header into the transmission queue, so that it is encapsulated together with the original data packet with the first forward error correction header and sent.

[0076] The purpose of this step is to seamlessly integrate the processed original data packets and newly generated redundant data packets into the standard network transmission process. Specifically, the redundant data packets are "injected" back into the original transmission path where they were intercepted. Afterward, both the original data packets with the first forward error correction header and the redundant data packets with the second forward error correction header will be treated as ordinary IP data packets. These packets will then be encapsulated by the subsequent kernel network stack using standard VXLAN encapsulation (adding VXLAN headers, outer UDP / IP headers, etc.) and sent out through the physical network interface.

[0077] Unlike solutions that require independent channels or special queues to send redundant data packets, this step leverages the "intercept-process-allow" characteristic of TC hooks, making the FEC processing invisible to the VXLAN encapsulation layer, physical driver, and even the entire network. This ultimately achieves completely transparent integration of forward error correction (FEC) into the existing VXLAN tunnel architecture. Other devices in the network require no modifications, and the receiving host only needs to deploy the corresponding eBPF receiver program to enjoy the enhanced reliability. This significantly reduces deployment complexity and coordination costs, achieving plug-and-play reliability improvements.

[0078] By employing the aforementioned eBPF-based VXLAN tunnel forward error correction transmission method, this embodiment mounts a lightweight eBPF functional unit to the TC egress point, performing real-time processing at the optimal time before VXLAN packet encapsulation. This avoids the significant overhead of user-mode-kernel mode switching and effectively solves the performance bottleneck problem of application-layer FEC schemes. Utilizing the dynamic loading and security verification characteristics of eBPF technology, it eliminates the need to modify the Linux kernel source code or restart the system, completely overcoming the difficulties in developing and maintaining kernel module FEC schemes and the systemic risks of strong coupling with kernel versions. By inserting a customized FEC header at the IP layer and ensuring that all processing is completed before the standard VXLAN encapsulation process, neither upper-layer applications nor the underlying physical network are aware of this reliability enhancement mechanism, providing a seamless user experience and eliminating the high costs and architectural rigidity issues associated with hardware-offloaded FEC schemes.

[0079] In one specific embodiment, the method for determining the redundant checksum value stored in the checksum field of the transmission packet context is described.

[0080] In this embodiment, the redundancy check value is a calculation result with a preset data length, wherein the calculation result is obtained by performing a bitwise XOR operation on the intermediate data of all original data in the data group, and wherein the intermediate data is the data obtained by filling the payload data of the original data packet to the data length.

[0081] When data packets are transmitted in the physical network within a VXLAN tunnel, if the inner data packet lengths are inconsistent, direct bitwise operations (such as XOR) will fail due to data length misalignment. Therefore, the payload data of each original data packet is padded to a preset length to ensure that the payloads of all data packets within the same data group have the same length during redundancy calculations, allowing the bitwise XOR operation to be executed correctly. Furthermore, based on the Maximum Transmission Unit (MTU) limit configured in the VXLAN network interface (or underlying physical interface), the expected lengths of the VXLAN outer encapsulation header, UDP header, IP header, and the FEC header defined in this invention are subtracted to calculate the maximum service data length that the inner service data packets in the VXLAN tunnel can carry without triggering fragmentation. This ensures that the total length of the padded data packet, after adding the FEC header and completing VXLAN encapsulation, will not exceed the MTU of the underlying link, preventing data packet fragmentation during transmission and eliminating the additional overhead and latency caused by fragmentation and reassembly.

[0082] For each arriving raw data packet, its payload data is filled in as described above. Then, a bitwise XOR operation is performed between the filled complete data block and the current value of the "Cumulative Redundancy Check Value Field" in the packet context. The result is written back to the "Cumulative Redundancy Check Value Field," thereby updating the field. This process iterates with the arrival of each data packet.

[0083] The XOR operation is a fundamental bitwise operation that executes extremely quickly on a CPU with a computational complexity of O(n), linearly dependent on the data length, minimizing the overhead of redundant calculations. Furthermore, the XOR operation satisfies the associative law ((A XOR B) XOR C = A XOR (B XOR C)) and the commutative law (A XOR B = B XOR A). This means that at the sending end, the processing order of data packets (i.e., the order in which they arrive at the TC egress point) does not affect the final accumulated result of the "checksum field".

[0084] Based on the properties of the XOR operation, if a data group contains K original data packets D1, D2, …, DK, its accumulated checksum P = D1 XOR D2 XOR … XOR DK. If the receiver loses any one of these data packets Di, but successfully receives the remaining K-1 original data packets and the checksum P, the lost Di can be recovered by calculating: Di = D1 XOR … XOR Di-1 XOR Di+1 XOR … XOR DK XOR P. This is the mathematical basis for the recovery operation at the receiver, enabling the recovery of any lost original data packet within the group with only one redundant data packet, providing effective single-packet loss fault tolerance.

[0085] In the above embodiments, XOR operation is used for streaming redundancy calculation, which enables the method to complete FEC encoding synchronously with the normal forwarding process of data packets with almost no additional latency, thus achieving a balance between high performance and enhanced functionality.

[0086] The "XOR encoding" described in the foregoing embodiments is a preferred implementation after careful consideration, and it is particularly suitable for implementing low-overhead, streaming forward error correction in the eBPF kernel environment. However, those skilled in the art can use other encoding and decoding methods to process the payload data to generate redundant check information based on the same architecture. The following describes feasible alternative embodiments: For example, linear encoding methods based on table lookup: Implementation: Linear encoding based on finite field (GF) operations is employed, such as a simplified version of Reed-Solomon encoding. In the eBPF program, a small-scale finite field operation lookup table (such as GF(2...)) can be predefined. 8 (multiplication and addition tables), and store these tables as read-only data in eBPF mappings or program code segments.

[0087] Processing flow: The first eBPF functional unit at the sending end maintains an encoding matrix state for each data group. For each arriving raw data packet, its padded payload data is treated as a set of coefficients, and the global redundancy check value is updated by performing finite-field multiplication and addition operations (implemented through table lookup) with a predefined encoding vector. When N redundant data packets need to be generated, N different encoding vectors can be used for calculation to obtain N different redundancy check blocks.

[0088] Correlation and Trade-offs with the Optimal Solution: This method still falls under "streaming processing" and utilizes table lookups to transform complex operations into memory accesses, adapting to the computational limitations of eBPF. Compared to a single XOR encoding, it can generate multiple independent redundant data packets (M>1), providing stronger error correction capabilities (e.g., recovery of multiple lost packets). However, table lookup operations introduce additional memory access overhead, making its computational complexity higher than that of a simple XOR.

[0089] In one specific embodiment, the storage method and index structure of the transmitted packet context are described.

[0090] In this embodiment, the group context is stored in an eBPF mapping of per-CPU hash type, and the key of the eBPF mapping is a composite key generated based on the group identifier and the stream identifier.

[0091] In high-speed network processing, multiple CPU cores may simultaneously process packets from different streams or groups. Using per-CPU hash mapping, the kernel maintains an independent hash table instance for each CPU core. When eBPF functional units execute concurrently on different CPUs, they access their respective core's local hash table, completely eliminating lock contention that may arise when multiple CPU cores access and modify the same context, thus ensuring the linear scalability of FEC processing performance in high-concurrency scenarios.

[0092] Different data flows (e.g., connections between different virtual machines or containers) may independently use the same or similar group number sequences. Including the flow identifier as part of the composite key ensures that the key value uniquely corresponds to a specific data group within a specific network connection, fundamentally avoiding contextual errors or conflicts between different flows.

[0093] In the above embodiments, a precise positioning of grouping contexts and an indexing mechanism for isolating different data flow contexts in eBPF mapping are achieved.

[0094] In one specific embodiment, the specific steps for generating redundant data packets are described.

[0095] In this embodiment, generating redundant data packets includes steps 131 to 134. The purpose is to dynamically construct a redundant data packet carrying the redundancy check information of the entire data group in a near-zero replication manner without deviating from the standard kernel network protocol stack processing flow, and seamlessly re-inject it into the normal transmission path.

[0096] Step 131: Clone the last arriving original data packet within the data group.

[0097] This step provides a ready-made, correctly formatted "template" packet for constructing redundant packets. Specifically, it calls eBPF helper functions such as bpf_skb_clone(). This function takes a pointer to the original packet kernel buffer (struct sk_buff *) as an argument and returns a pointer to the newly cloned packet buffer. The cloning operation copies the original packet's metadata, protocol headers, and references to the payload data, but the newly cloned buffer shares the actual payload data pages with the original buffer (copy-on-write).

[0098] Compared to constructing a complete data packet from scratch in user space, or requesting and assembling a data packet through a complex kernel API, this step utilizes the kernel cloning mechanism provided by eBPF, which is optimized for network processing. Based on the characteristic that the cloned packet inherits all protocol headers (such as Ethernet header, IP header, UDP header, etc.) of the original data packet, this avoids the large amount of memory allocation and copying overhead required to create a brand new data packet.

[0099] Step 132: Replace the payload data of the cloned packet with the updated packet context.

[0100] The purpose of this step is to inject the calculated redundancy information into the data packet, making it a data unit with actual error correction capabilities. Specifically, it first accesses the packet context corresponding to the current data group. The redundancy check value is stored in the cumulative field of this packet context. Then, auxiliary functions such as bpf_skb_store_bytes() are called to update the content of the cloned packet's payload area with this redundancy check value. Simultaneously, as mentioned earlier, an FEC header (type=1) identifying the packet as redundant is inserted after the IP header.

[0101] Unlike out-of-band schemes that require independent storage and transmission of redundancy check information, this step directly inlines the redundant information into the standard data packet structure. By leveraging the ability of eBPF programs to directly modify the data packet buffer in kernel mode, standardized encapsulation of redundant data is achieved.

[0102] Step 133: Update the IP header length and checksum of the cloned packet. This step ensures that the modified data packet conforms to the IP protocol specifications and can be correctly forwarded by network devices. Since step 132 replaces the payload data, the total length of the data packet may change (e.g., the length of the redundancy check value differs from the original payload length). The "Total Length" field of the IP header needs to be recalculated based on the new payload length and IP header length; and the IP "Header Checksum" also needs to be recalculated. This update can be quickly performed, for example, using the helper function bpf_l3_csum_replace() or a similar method.

[0103] This step ensures that the generated redundant data packets are legal and complete at the network layer, avoiding the risk of them being discarded by intermediate routers due to incorrect protocol fields, and ensuring the reliable delivery of redundant information.

[0104] Step 134: Redirect the cloned data packet to the sending queue.

[0105] This step seamlessly "pushes" the newly generated redundant data packet back into the intercepted transmission queue, achieving transparent injection. Specifically, it calls the `bpf_redirect()` helper function, which takes the cloned data packet and the index of the original network device as parameters. After the call, the cloned data packet will be re-entered into the transmission queue (qdisc) of the specified network device.

[0106] Through redirection, redundant data packets are merged with the original K data packets in the sending queue. These packets then undergo the exact same standard kernel processing flow, including VXLAN encapsulation, route lookup, and queuing, before being sent out by the physical network interface card (NIC). This achieves zero-intrusion and complete transparency of the FEC function within the existing network stack.

[0107] The aforementioned redundant data packet generation mechanism utilizes kernel cloning and redirection to avoid expensive data copying and context switching between user space and kernel space, as well as the overhead of constructing entirely new data packets. It proactively updates necessary protocol fields (such as IP length and checksum) to ensure that the generated data packets conform to standards and are not mishandled by network devices. The generated redundant data packets are sent through standard paths and are no different from ordinary data packets to the VXLAN encapsulation layer, the physical network, and the receiving end protocol stack.

[0108] Example 2 Based on the transparent forward error correction (FEC) data stream constructed at the sending end, the receiving end needs to perform corresponding identification, reassembly, recovery, and re-injection processes after the data packets are decapsulated by VXLAN. This embodiment describes the receiving method executed by the second eBPF functional unit. Its core lies in proposing an asynchronous packet reassembly and real-time recovery mechanism based on eBPF. By intelligently identifying and managing the state of data packets carrying FEC headers on the critical path after VXLAN decapsulation, automatic packet loss detection and transparent recovery are achieved, thereby providing a continuous and complete data stream to upper-layer applications.

[0109] See Figure 2 The method in this embodiment includes steps 21 to 25.

[0110] Step 21: Identify whether the received data packet contains a forward error correction header.

[0111] This step acts as an entry point and filter for the entire receiving end processing flow, distinguishing between packets requiring FEC processing and ordinary packets. When a packet passes through the TC ingress hook point, the second eBPF functional unit first checks whether an FEC header conforming to a preset format exists after its network layer (IP) header. This is typically done by checking the protocol field in the IP header or the data pattern at a specific offset. This check logic is simple and fast, ensuring that only packets participating in FEC enter the subsequent complex processing flow, while ordinary packets are directly allowed to pass, minimizing performance impact.

[0112] This step utilizes the FEC header as an explicit, lightweight marker, making the judgment operation extremely efficient.

[0113] Step 22: If the received data packet carries a first forward error correction header with a type field identifying the data packet as an original data packet, then obtain the group identifier and the sequence number within the group from the first forward error correction header, and record the arrival status and storage location corresponding to the sequence number within the group in the reassembly context corresponding to the group identifier.

[0114] This step precisely locates the original data packets carrying application data, laying the foundation for reassembly. Specifically, after parsing the FEC header and confirming that the type field corresponds to the original data packet, the group_id and seq fields are extracted. Subsequently, in kernel space, eBPF mapping, a highly efficient shared memory, enables precise state tracking at the group level. Each data packet, through its built-in group_id and seq fields, autonomously determines its position within the reassembly context, achieving zero-copy temporary storage (only storing pointers) and atomic updates to the arrival status of the original data packets.

[0115] Step 23: If the received data packet carries a type field that identifies the data packet as a redundant data packet, then obtain its group identifier from the second forward error correction header and record the storage location of the redundant data packet in the reassembly context corresponding to the group identifier.

[0116] This step involves receiving and storing redundant information for error correction. If the `type` field identifies a redundant data packet, its `group_id` is extracted. Similarly, the reassembly context corresponding to the `group_id` is used, and a pointer to the payload of that redundant data packet is stored within the reassembly context.

[0117] Steps 22 and 23 are associated with the same reassembly context through the same group_id, ensuring that the redundancy check information can be correctly associated with the corresponding original data packet group, thus preparing the data for decoding and recovery based on the redundancy information.

[0118] Step 24: Monitor the number of cached original data packets and redundant data packets in the reassembly context. When the total number of cached original data packets and redundant data packets is greater than or equal to the total number of original data packets, check whether there are any original data packets with missing group sequence numbers. If there are data packets with missing group sequence numbers, perform decoding operations based on the cached original data packets and redundant data packets to restore the original payload of the missing original data packets.

[0119] This step intelligently determines the recovery timing and performs error correction calculations. When the number of valid packets (original data packets + redundant data packets) received within a data group reaches the total number of original data packets K, the theoretical condition for resolving all lost packets is met. Once this condition is satisfied, the location of the missing sequence number (seq) is identified. For each missing seq, based on the payload data of all arriving packets recorded in the reassembly context, decoding operations are performed to directly calculate the original payload of the lost data packet.

[0120] Compared to timer-based delayed recovery or retransmission mechanisms requiring application layer requests, this step achieves immediate recovery based on real-time arrival status. Its decisions are entirely based on packet arrival, requiring no waiting. It can repair the data stream almost in real-time, the instant packets are submitted to the upper-layer protocol stack after network packet loss occurs, making the packet loss event virtually imperceptible to the upper-layer layer. This effectively solves the core problem of performance degradation and instability in upper-layer applications caused by VXLAN / UDP packet loss in the background technology.

[0121] Step 25: Reconstruct the data packets based on the recovered original payload and re-inject the reconstructed data packets into the kernel network protocol stack.

[0122] The purpose of this step is to reconstruct the recovered data into a data packet that conforms to the protocol standard and can be received by the upper layer, and then send this new packet into the subsequent processes of the protocol stack.

[0123] Simply recovering the payload data in memory is not enough. It must be encapsulated into a kernel object (sk_buff) that is consistent with the original packet that was not dropped, and ensure that it can be passed up the protocol stack (to the application layer socket) or forwarded according to the routing table. This makes packet loss recovery completely transparent to other parts of the system.

[0124] Unlike schemes that require reassembling and retransmitting packets in user space, this step completes the recovery of lost packets locally in kernel space, on the original receive path after the packets are decapsulated by VXLAN. This avoids the huge overhead of routing the recovered data back to user space and then back to the kernel, and also ensures that the context of the recovered packet (such as network namespace and routing information) is completely consistent with the original flow. For the application, network packet loss events are completely masked, and the transmission appears continuous and reliable, all achieved with near-zero additional latency and CPU overhead.

[0125] Through the aforementioned eBPF-based VXLAN tunnel forward error correction reception method, this embodiment mounts a lightweight eBPF functional unit to the TC ingress hook point of the VXLAN network device, and immediately identifies, classifies, and manages the status of data packets after VXLAN decapsulation. Real-time recovery is triggered based on the number of arriving packets, ensuring that packet loss detection, recovery decisions, and decoding operations are all completed in-situ on the last kernel path before the data packet arrives at the application, avoiding the latency caused by sending data packets to user space for processing. The quantity-triggered mechanism enables recovery to start immediately upon receiving sufficient information, minimizing recovery waiting time, thereby achieving near real-time packet loss masking and data recovery. This significantly reduces the end-to-end latency jitter and performance impact of packet loss on upper-layer applications (such as distributed databases and real-time computing), fundamentally overcoming... Overcoming the shortcomings of slow recovery and delayed response in application-layer FEC schemes, the second eBPF functional unit carries the complete FEC decoding, state management, and packet reconstruction logic on the receiving side, significantly reducing the development and maintenance complexity of kernel-mode functions on the receiving side. It completely avoids the stability risks and strong version coupling problems that also exist in traditional kernel modules on the receiving end. Identification and state management are performed by parsing the FEC header inline in the data packet. After recovery, the data packet with the standard protocol header is reconstructed and re-injected into the kernel network protocol stack for subsequent processing. The recovery process relies entirely on the FEC header information and reconstructing context carried by the data packet itself, without relying on any dedicated hardware.

[0126] In one specific embodiment, the storage method and index structure of the reorganization context are described.

[0127] In this embodiment, the reorganization context is stored in an eBPF mapping of per-CPU hash type, and the key of the eBPF mapping is a composite key generated based on the group identifier and the stream identifier.

[0128] In high-speed network processing, multiple CPU cores may simultaneously process packets from different streams or groups. Using per-CPU hash mapping, the kernel maintains an independent hash table instance for each CPU core. When eBPF functional units execute concurrently on different CPUs, they access their respective core's local hash table, completely eliminating lock contention that may arise when multiple CPU cores access and modify the same context, thus ensuring the linear scalability of FEC processing performance in high-concurrency scenarios.

[0129] Different data flows (e.g., connections between different virtual machines or containers) may independently use the same or similar group number sequences. Including the flow identifier as part of the composite key ensures that the key value uniquely corresponds to a specific data group within a specific network connection, fundamentally avoiding contextual errors or conflicts between different flows.

[0130] In the above embodiments, a precise location of the reorganized context in the eBPF mapping and an indexing mechanism for isolating different data stream contexts are achieved.

[0131] Efficient resource management and eviction: Using BPF_MAP_TYPE_LRU_PERCPU_HASH mapping to store the reorganization context enables the system to automatically evict the least recently used entry. Combined with proactive timeout cleanup of the "timestamp field," this ensures that limited kernel memory resources are used efficiently, preventing memory exhaustion caused by waiting for packets that will never arrive, and guaranteeing long-term system stability.

[0132] In one specific embodiment, the specific steps for recovering the lost original data packet payload are described.

[0133] In this embodiment, generating redundant data packets includes steps 241 to 244. The core of this step is to reconstruct the lost data content based on the received partial data packets through reverse calculation.

[0134] Step 241: Collect the payload data of the cached raw data packets and redundant data packets.

[0135] This step prepares a complete input dataset for the decoding operation. Specifically, it retrieves all valid pointers recorded in the packet cache reference field and redundant packet cache reference field of the reassembly context corresponding to the current data group. These pointers point to the memory locations where the payload data of the original packets and redundant packets that have been successfully received and temporarily cached in the kernel are located. These memory areas are accessed through safe eBPF helper functions, and the payload data is read into local variables or temporary buffers to form the data set to be decoded. This set should contain exactly K valid data units (i.e., K-1 original packet payloads and 1 redundant packet payload, or K original packet payloads partially replaced by redundant packets).

[0136] Compared to existing technologies that perform packet reassembly and copying in user space or rely on hardware reassembly engines, this step is completed entirely in kernel space using eBPF programs to directly manipulate cached packet data pointers. With zero data copying, it prepares the data for subsequent core decoding calculations, avoiding the performance overhead of copying packet content from kernel space to user space, and requiring no hardware support, achieving highly efficient data aggregation purely in software.

[0137] Step 242: Determine the actual payload length of each raw data packet based on the total length field in the forward error correction header.

[0138] The purpose of this step is to obtain the precise length information needed to recover the original payload, guiding subsequent padding and truncation operations. Specifically, from any received data packet carrying a complete FEC header (whether an original packet or a redundant packet), the "Total Length Field (L)" within the Forward Error Correction header is parsed. The value of this field is calculated and inserted by the sender during encoding, representing the sum of the actual payload lengths of all original packets within that data group. Combining this total length L with the known total number of original packets K, the average payload length of each original packet can be calculated, or a specific length allocation strategy can be determined based on the sequence number distribution (under the equal-length padding assumption, this can be directly used for subsequent calculations).

[0139] Traditional FEC schemes often rely on external protocols or fixed packet parameters to infer length, or carry length information in the application layer payload. This step creatively utilizes an inline field (L) in the FEC header, specifically designed for this case. This field is precisely calculated and inserted by the first eBPF functional unit at the sending end when generating redundant data packets. The receiving end can directly obtain it without any out-of-band negotiation or complex inference, making it an efficient, accurate, and lightweight signaling delivery method.

[0140] The above operations ensured the accuracy of the recovery process. The receiving end clearly knew the total amount of original data to be recovered, providing a key parameter for accurately restoring the padded data to the original application data and avoiding protocol stack parsing failures caused by incorrect recovered data length.

[0141] Step 243: After filling each load data to the preset length, perform an XOR operation to obtain the recovered data.

[0142] This step executes the core decoding algorithm, calculating an intermediate representation of the complete data set, including any missing data, from the partial data. The specific operation consists of two steps: Uniform Length Padding: Each of the K payload data collected in step 241 (each length may vary depending on the actual data) is padded (e.g., trailed with zeros) to a uniform "preset length". This preset length is the same as the padding length used during encoding at the sending end, and is typically the maximum service data length calculated based on the MTU. This operation ensures that all data units involved in the calculation have consistent lengths.

[0143] XOR decoding calculation: Perform a bitwise XOR operation on these K data blocks that have been padded to a uniform length. Based on the properties of XOR (A ⊕ B ⊕ B = A), and since the redundant data packet payload generated by the sender is the XOR result of the payloads of all original data packets (after padding) within the group, performing an XOR operation on the padded payloads of any K received packets (original data packets and redundant data packets) will yield a result equivalent to the XOR result of the padded payloads of all K original data packets. If all K original data packets have been received, this result is zero; if any packets are lost, this result encodes information about the lost packets.

[0144] Compared to the complex general FEC decoding based on matrix inversion, the padded XOR decoding used in this step is an extremely simplified algorithm optimized specifically for the "single redundant packet" scenario. Its computational complexity is O(n), involving only simple bit operations and memory copying, making it highly suitable for execution in the computationally limited and instruction cycle-sensitive kernel eBPF environment. Furthermore, it is perfectly symmetrical with the "padded XOR encoding" at the sending end, forming a complete and efficient codec pair.

[0145] Through the above calculations, a portion of the received data was successfully converted into an intermediate data block that reflects the information of the complete data set. This data block is a crucial intermediate state before the original lost payload can be recovered, and the algorithm's efficiency ensures low latency in the recovery process.

[0146] Step 244: Extract the payload portion corresponding to the missing original data packet from the recovered data.

[0147] This step extracts specific, lost original application data from the intermediate data obtained through decoding. Specifically, based on the total length L determined in step 242, the known total number of original data packets K, and the sequence number of each packet, the actual payload length of each original data packet can be calculated (in the case of equal-length allocation or known distribution). Since the portion corresponding to the missing packet in the XOR operation is the original payload before padding (because the XOR effect of other received packets is canceled out), the corresponding byte sequence of the appropriate length is precisely extracted from the corresponding position in the "recovered data" block obtained in step 243, based on the sequence number of the missing packet and its corresponding length and offset. This byte sequence is the recovered, unpadded original payload data.

[0148] Unlike general decoders that require complete decoding of all data to extract a specific packet, this step, after obtaining intermediate recovered data, can perform targeted extraction only on known missing packets. This reduces unnecessary data manipulation and further optimizes the processing flow. Its accuracy directly depends on the precise length information (L) carried in the FEC header.

[0149] Through the above interception operations, the final payload content is completely identical to the original data sent by the sending application. At this point, packet loss is transparently repaired at the receiving end, and to the upper-layer application, the network appears as a lossless channel.

[0150] Through the complete decoding and recovery steps described above, this embodiment successfully achieves real-time packet loss repair based on partial data at the receiving end. The entire process is completed entirely in kernel space by the eBPF program, which is symmetrical and efficient with the encoding process at the sending end, forming a closed loop from encoding, sending, receiving, and recovery. This not only effectively combats random packet loss in VXLAN tunnels, but its pure software implementation, lack of additional data copying, and extremely low computational overhead ensure that enhanced reliability will not become a new performance bottleneck, perfectly meeting the needs of high-performance data center networks.

[0151] In one specific embodiment, the implementation of the reconstruction and injection process is described.

[0152] This embodiment includes steps 251 to 255, which are designed to efficiently and securely complete the regeneration of data packets within the kernel.

[0153] Step 251: Create a new packet buffer.

[0154] Calling a helper function provided by eBPF (such as bpf_skb_create()) allocates a new sk_buff data structure buffer in the kernel. This buffer is the standard carrier for processing packets in the Linux kernel network subsystem, ensuring the security and compliance of operations and passing the eBPF verifier's checks. The newly allocated buffer is empty, waiting to be filled with the header and payload.

[0155] Step 252: Copy the network layer header and the first forward error correction header from the cached raw data packet to the new data packet buffer.

[0156] From any successfully received original data packet belonging to the same data group and cached in the reconstructing context, its network layer (e.g., IPv4 / IPv6) header and the immediately following first forward error correction header are completely copied into the newly created packet buffer. This ensures that the reconstructed packet is formatted identically to other normally arriving original data packets in the same group, a key detail for guaranteeing transparency. This operation avoids the computation of reconstructing complex headers and also ensures compatibility with the original flow state.

[0157] Step 253: Fill the new packet buffer with the recovered original payload.

[0158] This step fills in the original payload, ensuring that the reconstructed data packet is identical in length and content to the original packet sent by the sending application at the bit level, fully meeting the expectations of the upper-layer protocol.

[0159] Step 254: Update the network layer header length and checksum of the new packet buffer.

[0160] Because of the payload being written, the total length of the data packet changes. The program needs to recalculate and update the "Total Length" field in the network layer (IP) header. Subsequently, based on the updated header, the IP header checksum is recalculated. For transport layer checksums (such as TCP / UDP), since they cover the payload, they typically also need to be updated or recalculated using eBPF helper functions. This step ensures that the reconstructed data packet is syntactically correct and acceptable to standard network stack hardware checksum logic. In the eBPF environment, these update operations are performed through specific helper functions, ensuring the efficiency and correctness of the calculation and preventing packets from being dropped by the kernel due to checksum errors.

[0161] Step 255: Redirect the new packet buffer to the target network interface. Calling an eBPF redirection helper function (such as bpf_clone_redirect()) sends a newly reconstructed packet buffer, containing the correct header and payload, to a specified target network interface. This interface is typically handled locally by netif_receive_skb for either delivery or forwarding.

[0162] By redirecting it to the appropriate local virtual interface, the packet undergoes the same complete protocol stack processing from the link layer to the transport layer (and even to the socket) as a normal packet just received from the network card. Thus, the recovery process is identical to receiving a delayed normal packet for the rest of the kernel and upper-layer applications.

[0163] Through the meticulous operations described in steps 251 to 255, this embodiment implements a closed-loop, self-contained packet recovery and injection pipeline in the receiver kernel. It fully utilizes the security primitives (create, read, write, redirect) provided by eBPF to seamlessly "stitch" the recovered data back into the active data stream with near-zero copying, while ensuring system security and stability. This not only achieves forward error correction functionally but also achieves ultimate performance and transparency in engineering.

[0164] Example 3 This application provides an embodiment of a device that embodies the aforementioned method. This device can be deployed at both ends of a VXLAN tunnel (typically a virtualized host or a physical server), and its core consists of two functional modules that work collaboratively in kernel mode, achieving end-to-end transparent forward error correction.

[0165] See Figure 3 The device includes a transmitting module and a receiving module.

[0166] The sending module physically corresponds to the first eBPF functional unit loaded and running in the sending Linux kernel. This functional unit is compiled into eBPF bytecode and mounted to the egress hook point of the flow control (TC) subsystem of the sending VXLAN tunnel interface (such as vxlan0) via a first mounting unit (which can be manifested as the loading logic of a user-space management process or the kernel's loading interface). This hook point is located on the critical path before the data packet undergoes VXLAN encapsulation.

[0167] This module is configured to execute the methods described above on the sending side. Its core function is to intercept outgoing raw data packets, perform flow identification and dynamic packetization, add an FEC header containing information such as type, group identifier, and sequence number to each data packet, calculate packet redundancy check values ​​in a streaming manner, and generate and inject redundant data packets when packetization is complete. All operations are completed before the data packets are encapsulated by VXLAN, making them transparent to upper-layer applications and the lower layers of the network protocol stack.

[0168] The receiving module physically corresponds to the second eBPF functional unit loaded and running in the receiving end's Linux kernel. This program is also compiled into eBPF bytecode and mounted to the ingress hook point of the flow control (TC) subsystem of the receiving end's VXLAN tunnel interface via the second mounting unit. This hook point is located on the critical path after the data packet is decapsulated by VXLAN and handed over to the upper-layer protocol.

[0169] This module is configured to execute the methods described above on the receiving side. Its core function is to identify data packets carrying FEC headers (including original data packets and redundant data packets), cache and manage the reassembly context in the eBPF mapping based on the header information, detect packet loss in real time, and decode and recover the lost original data packet payload when conditions are met, thereby reconstructing the complete data packet and re-injecting it into the protocol stack.

[0170] The sending and receiving modules are connected to external devices via physical network links (carrying VXLAN tunnels) and communicate with external devices through in-band signaling via FEC headers carried in data packets. Together, these two modules constitute a complete, distributed forward error correction message processing device.

[0171] This device achieves high-performance and reliable transmission enhancement in a general-purpose Linux kernel through pure software, avoiding the cost of dedicated hardware; it features dynamic loading, secure verification, and easy upgrades, solving the stability and maintainability problems of traditional kernel module solutions; the entire processing flow is embedded in the TC layer of the standard network protocol stack, requiring zero modification to applications and network infrastructure, and providing excellent deployment flexibility.

[0172] Optionally, the device may also include user-space processes, thereby giving each network device the ability to be dynamically configurable and adaptively optimized.

[0173] The user-mode process is a daemon or management program running in the operating system's user space. It communicates with the send and receive modules in the kernel through eBPF mapping and the bpf() system call. This process constitutes the device's control and management planes.

[0174] One of the core responsibilities of user-space processes is to send management parameters to the sending and / or receiving modules. This is achieved by writing key-value pairs to a specific eBPF mapping associated with these modules (e.g., a BPF_MAP_TYPE_ARRAY or BPF_MAP_TYPE_HASH). The management parameters include, but are not limited to: Packet size (K): Controls the number of raw data packets contained in each FEC group.

[0175] Total number of redundant data packets (M): Controls the number of redundant data packets included in each FEC group. Bypass flag: A boolean switch that indicates whether performance optimization mode is enabled.

[0176] In addition, user-space processes can also obtain metrics such as module running status, packet loss rate, and recovery success rate by reading other eBPF mappings (such as statistical mappings), providing a basis for decision-making to dynamically adjust parameters.

[0177] At least one of the sending and receiving modules (usually both) reads these management parameters from the shared eBPF mapping periodically or before performing critical operations during runtime, and adjusts its behavior based on the parameter values.

[0178] When a new packet size K is read, the sending module adjusts the packet logic accordingly, and the receiving module adjusts the expected size of its reassembly context.

[0179] When the bypass flag is detected as enabled, the module will enter optimization mode. Specifically, when the bypass flag indicates that the network quality meets preset conditions, the module only adds or checks the forward error correction header without performing redundant calculations.

[0180] In the sending module, an FEC header (containing information such as stream, group, and sequence number) is still inserted into the data packet, but the streaming XOR calculation and redundant data packet generation are skipped, which greatly reduces the CPU computing overhead.

[0181] In the receiving module, the FEC header is still checked to maintain basic stream and packet states (for quick switching back to FEC mode), but complex logic such as redundant packet buffering, packet loss detection, and decoding recovery is skipped.

[0182] The above operations resolve the issue of unnecessary computational resource consumption caused by the FEC mechanism in an ideal network environment. By monitoring network quality (such as continuous zero packet loss) through user-space processes and enabling bypass mode when the link is confirmed to be excellent, the device can dynamically save CPU resources while maintaining architectural consistency and state, and ensuring rapid recovery of FEC functionality. This demonstrates the device's intelligence and its ability to finely manage system resources, further optimizing the overall performance-to-power ratio.

[0183] When a new, increased total number of redundant data packets M (M>1) is read from the shared eBPF mapping, the behavior of the sending module will undergo the following key changes: The encoding algorithm and context structure will be adjusted: the sending module will switch to an encoding algorithm mode that supports generating multiple redundant data packets. For example, it will switch from a simple single XOR encoding to a multi-XOR encoding that can generate multiple independent redundant units, or an encoding based on finite field operations (such as Cauchy Reed-Solomon). Specifically, the internal data structure of the sending packet context needs to be expanded. The field that previously only stored a single fec_checksum needs to be expanded into a redundancy check value array of length M (e.g., redundancy_vector[M]). The program needs to update all or part of the elements in this vector for each arriving raw data packet according to the requirements of the new algorithm.

[0184] The redundant packet generation logic is adjusted: when the number of original data packets within a data group reaches K, the sending module no longer generates only one redundant data packet, but instead needs to generate M redundant data packets. Specifically, this is done M times in a loop. In each loop, the operations performed include: cloning a template data packet (such as the last packet in the group); replacing its payload with a corresponding redundancy check value from the `redundancy_vector` array (e.g., index i corresponds to the i-th redundant data packet); in the inserted FEC header, in addition to setting `type=redundant data packet` and `group_id`, an additional field (such as `redundancy_index`) may be needed to identify which of the M redundant data packets it is, ensuring the receiver can correctly distinguish and process them; and finally, injecting the generated redundant data packets into the sending queue.

[0185] This adjustment enables the device to dynamically improve the link's resilience to packet loss. By increasing the number of redundant data packets M, the system can tolerate a higher degree of random or burst packet loss. For example, when M=2, as long as the receiver successfully receives any K packets (which could be K original data packets, K-1 original data packets plus 1 redundant data packet, or K-2 original data packets plus 2 redundant data packets), all the original data can be recovered. This allows the system to proactively adapt to scenarios where network quality deteriorates.

[0186] When the receiver reads the new parameter M, its behavior will be adjusted accordingly to correctly decode the multiple redundant data packets sent by the sender: Adjusting the expectations and structure of the reconstitution context: The receiving module needs to know that it may receive up to M redundant data packets. Specifically, the data structure of the reconstitution context needs to be expanded to be able to buffer up to M redundant data packets. For example, the redundant data packet pointer field needs to be expanded from a single pointer to an array of pointers (e.g., redundancy_ptrs[M]). At the same time, the logic used to determine the recovery conditions also needs to be updated to incorporate the value of M into the calculation.

[0187] Adjusting the redundant data packet identification and caching logic: The receiving module needs to be able to correctly identify and classify different redundant data packets. Specifically, when parsing the FEC header, in addition to checking for redundant data packets with the type=redundancy value, the program also needs to read the field identifying the sequence number of the redundant data packet (such as `redundancy_index`). Then, based on this index value, the redundant data packet is cached at the corresponding position in the reassembly context `redundancy_ptrs` array, instead of overwriting the same pointer.

[0188] Adjustments to recovery condition judgment and decoding logic: Recovery condition: The formula for determining whether the recovery condition is met has changed from "(number of arriving original data packets + number of arriving redundant data packets) >= K" to implicitly requiring that the arriving redundant data packets can be multiple packets with different indices. Decoding operation: The decoding algorithm needs to match the multi-redundancy encoding algorithm used by the sending end (such as multiple XOR or Reed-Solomon decoding). The program needs to collect the payloads of all arriving original data packets and multiple redundant data packets with different indices, and perform the corresponding decoding operations (which may involve solving a system of linear equations) to recover the lost original data packets.

[0189] This adjustment ensures that the receiver can correctly understand and utilize the enhanced redundancy information provided by the sender. It enables the receiver module to parse and process multiple redundant data packets, thereby realizing the improved error correction level from the sender. This is a crucial closed loop for achieving dynamic adaptive reliability, ensuring the correctness of backend-to-end functionality after configuration changes.

[0190] By introducing a user-space process as a control entity, the static functional modules are upgraded into a dynamically configurable, monitorable, and optimizable intelligent system. This enables network operators to flexibly adjust FEC strategies based on actual network conditions and business needs, achieving an optimal balance between reliability, performance, and resource consumption. This signifies that the device is not merely a communication enhancement tool, but a modern network data plane component with observability and controllability.

[0191] The solution provided in this application, due to its core characteristics of high performance, transparency, software definition and easy deployment, is not only suitable for general cloud computing data center networks, but can also effectively meet the stringent requirements of various emerging network scenarios for transmission reliability and low latency.

[0192] Let's take its application in a Fiber to the Room (FTTR) network as an example: FTTR is a next-generation all-optical networking solution for homes and businesses. Its core feature is the use of optical fiber to replace traditional network cables, enabling gigabit or even 10-gigabit broadband access in every room. In an FTTR architecture, the home gateway (master optical modem) connects multiple slave optical terminals (slave optical modems) via optical fiber, forming a point-to-multipoint optical network. Applying this invention in this scenario can significantly improve user experience and network stability. However, it faces unique challenges: Fiber optic splitting and long-distance transmission: The presence of optical splitters in FTTR networks may introduce minor optical signal loss and jitter; factors such as fiber optic bending and connector aging in the room may also cause fluctuations in link quality, which may lead to packet loss when transmitting high-bandwidth, low-latency sensitive services (such as 8K video, cloud gaming, VR / AR).

[0193] Protocol transparency requirement: FTTR networks carry a wide variety of user services using diverse protocols. Any reliability enhancement mechanisms should not require modification of user terminal devices (such as mobile phones, computers, and smart TVs) or the applications they run.

[0194] Equipment cost and ease of deployment: The cost of home network equipment needs to be strictly controlled, and installation and maintenance should be easily completed by non-professionals.

[0195] The solutions and adaptations provided in this application are as follows: Deployment Nodes: The transmitting module is integrated into the Linux operating system kernel of the FTTR home gateway (main optical modem), and the receiving module is integrated into the slave optical terminals in each room. Alternatively, in symmetrical service scenarios, complete transmitting and receiving modules are deployed at both ends.

[0196] Tunnel adaptation: VXLAN tunnels are established between the home gateway and each slave optical terminal to carry all user service flows. The FEC processing logic of this solution is precisely attached to these VXLAN tunnel interfaces.

[0197] Enhanced Transparency: This solution's ability to process VXLAN tunnel data at the kernel TC layer perfectly meets the protocol transparency requirements of FTTR. All of the user's upper-layer services (TCP, UDP, ICMP, etc.) can seamlessly obtain forward error correction protection without any terminal-side modifications.

[0198] Dynamic jitter mitigation: By monitoring the signal quality (such as optical power and bit error rate) of each room link through user-mode processes, FEC parameters (such as redundancy M) are dynamically adjusted. When a slight degradation of the optical signal of a room link is detected, the FEC protection strength of that link can be automatically enhanced to effectively combat sudden packet loss caused by fiber micro-bending or loose connectors, ensuring the smoothness of VIP users or critical services (such as high-definition video conferencing in a study room).

[0199] Low cost and easy deployment: This solution is a pure software solution, eliminating the need for a dedicated FEC hardware chip in the optical modem, effectively controlling equipment costs. Functionality can be deployed to existing and new equipment via software upgrades (such as remote OTA), greatly simplifying network upgrade and maintenance processes.

[0200] As can be seen from the above description, applying this solution to an FTTR network can provide a carrier-grade, reliable indoor fiber optic network experience for high-quality home broadband, enterprise offices, small studios, and other scenarios without changing existing home network cabling, replacing user terminals, or increasing costs significantly. It reduces issues such as video stuttering and game latency fluctuations, and is an effective technical means to improve the quality of service (QoS) and user satisfaction (QoE) of all-optical networks.

[0201] Furthermore, this solution is designed for versatility and can be widely applied to any network environment based on IP / UDP tunneling technology that requires both reliability and low latency, including but not limited to: 5G Mobile Bearer Network and Edge Computing: Between 5G UPF (User Plane Function) and edge servers, or between different edge nodes, tunneling technologies such as VXLAN / GRE are commonly used to achieve service isolation and flexible orchestration. This solution can be deployed in these network elements to provide highly reliable fronthaul or backhaul links for uRLLC (Ultra-Reliable Low-Latency Communication) services, vehicle-to-everything (V2X), etc., meeting stringent latency and reliability requirements.

[0202] Cloud Data Center Interconnection and Hybrid Cloud: Overlay networks built via VXLAN tunnels between different public cloud availability zones, or between public and private clouds, may traverse complex WAN paths at their underlying layers. Deploying this solution can effectively mitigate the impact of WAN link jitter and packet loss on critical operations such as virtual machine migration, storage replication, and distributed database synchronization, thereby improving the continuity of hybrid cloud services.

[0203] Industrial Internet and Time-Sensitive Networking (TSN): In factory automation scenarios, tunneling technology is often used to carry time-sensitive data to ensure compatibility with traditional IP devices and achieve deterministic transmission. This solution can serve as a supplement or adaptation layer to the TSN mechanism, providing additional reliability guarantees for critical data streams such as motion control and machine vision on non-ideal physical links (such as industrial wireless), without affecting the existing industrial control protocol stack.

[0204] In summary, this solution provides a network transmission reliability enhancement scheme that is applicable to a variety of application scenarios.

[0205] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A forward error correction method for VXLAN tunnels based on eBPF that can be used in FTTR, characterized in that, A first eBPF functional unit applied to the transmitting end of a VXLAN tunnel, wherein the first eBPF functional unit is attached to a hook point at the flow control TC exit of the VXLAN network device, the hook point being located before VXLAN encapsulation, the method comprising: According to the preset group size, multiple consecutive raw data packets with the same flow identifier are divided into a data group, a group identifier is assigned to the data group, and a consecutive intra-group sequence number is assigned to each raw data packet in the group. The packet context of the data group is generated based on the payload data of all the original data packets in the data group, and a first forward error correction header is inserted after the network layer header of each original data packet. The type field of the first forward error correction header identifies the data packet as an original data packet and includes its group identifier and the sequence number within the group. When the number of data packets in the data group reaches the group size, the group context is used as the payload data to generate redundant data packets. A second forward error correction header is inserted after the network layer header of the redundant data packet. The type field of the second forward error correction header identifies the data packet as a redundant data packet and includes its group identifier. The redundant data packet with the second forward error correction header is injected into the transmission queue, and then encapsulated and transmitted together with the original data packet with the first forward error correction header.

2. The method according to claim 1, characterized in that: The grouping context includes a packet count field and a redundancy check value accumulation field; or, The packet context includes at least one of a hash storage array and a timestamp field, a packet count field, and a redundancy check value accumulation field; The packet count field stores the number of original data packets within the data group; The redundancy check value accumulation field stores the redundancy check value calculated based on the load data of all original data packets in the data group. The hash storage array stores the hash value of each processed raw data packet payload within the group; The timestamp field records the time when the context was created or last updated, in order to trigger a timeout and clean up the group context.

3. The method according to claim 2, characterized in that, The redundancy check value is the result of an XOR operation with a preset data length. The XOR result is obtained by performing a preset operation on the intermediate data of all the original data in the data group bit by bit. The intermediate data is the data obtained by filling the payload data of the original data packet to the data length.

4. The method according to any one of claims 1 to 3, characterized in that, The group context is stored in an eBPF mapping of per-CPU hash type, and the key of the eBPF mapping is a composite key generated based on the group identifier and the stream identifier.

5. The method according to claim 1, characterized in that, The first forward error correction header and the second forward error correction header further include at least one of the following: Stream identifier; Total length, used to record the total payload length of all raw data packets within the data group; Total number of raw data packets; Total number of redundant data packets.

6. The method according to claim 1, characterized in that, The generation of redundant data packets includes: Clone the last arriving original data packet within the data group; Replace the payload data of the cloned packet with the updated packet context; Update the IP header length and checksum of the cloned packet; The cloned data packets are redirected to the sending queue.

7. A tunnel forward error correction method in VXLAN based on eBPF that can be used for FTTR, characterized in that, A second eBPF functional unit is applied in the receiver of a VXLAN tunnel, wherein the second eBPF functional unit is located in the Linux kernel. The second eBPF functional unit is attached to a hook point at the flow control (TC) entry point of the VXLAN network device, which is located after VXLAN decapsulation. The method includes: Identify whether the received data packet contains a forward error correction header; If the received data packet carries a first forward error correction header with a type field that identifies the data packet as an original data packet, then the group identifier and the sequence number within the group are obtained from the first forward error correction header, and the arrival status and storage location corresponding to the sequence number within the group are recorded in the reassembly context corresponding to the group identifier. If the received data packet carries a type field that identifies the data packet as a redundant data packet, then its group identifier is obtained from the second forward error correction header, and the storage location of the redundant data packet is recorded in the reassembly context corresponding to the group identifier. Monitor the number of cached original data packets and redundant data packets in the reassembly context. When the total number of cached original data packets and redundant data packets is greater than or equal to the total number of original data packets, check whether there are original data packets with missing group sequence numbers. If there are data packets with missing group sequence numbers, perform decoding operations based on the cached original data packets and redundant data packets to restore the original payload of the missing original data packets. The packets are reconstructed based on the recovered original payload, and the reconstructed packets are then re-injected into the kernel network protocol stack.

8. The method according to claim 7, characterized in that: The reassembly context includes a packet arrival status record field and a packet cache reference field; or, The reassembly context includes the packet arrival status record field and the packet cache reference field, as well as at least one of the following fields: redundant packet cache reference field, arrival packet count field, and timestamp field; The data packet arrival status record field is used to record whether each original data packet in the group has arrived successfully; The packet cache reference field is used to point to the location of the payload data of the cached original packet in the kernel; The redundant packet cache reference field is used to point to the location of the payload data of the arrived redundant packets in the kernel; The arrival packet count field is used to record the total number of original data packets and redundant data packets that have arrived; The timestamp field is used to record the last update time of the data packets within the group corresponding to the reorganization context, so as to trigger timeout cleanup of the reorganization context.

9. The method according to claim 7 or 8, characterized in that, The group context is stored in an eBPF mapping of per-CPU hash type, and the key of the eBPF mapping is a composite key generated based on the group identifier and the stream identifier.

10. The method according to claim 7, characterized in that, The decoding operation based on the cached original data packets and redundant data packets to restore the original payload of the missing original data packets includes: Collect payload data of cached raw data packets and redundant data packets; The actual payload length of each raw data packet is determined based on the total length field in the forward error correction header; After filling each load data to a preset length, perform an XOR operation to obtain the recovered data; Extract the payload portion corresponding to the missing original data packet from the recovered data.

11. A tunnel forward error correction device in a VXLAN based on eBPF that can be used for FTTR, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 10.

12. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 10 when it is run.

13. A tunnel forward error correction device in a VXLAN based on eBPF that can be used for FTTR, characterized in that, include: The sending module is configured to perform the method according to any one of claims 1 to 6; A receiving module is configured to perform the method according to any one of claims 7 to 10.

14. The device according to claim 13, characterized in that, The device further includes a user-mode process, wherein the user-mode process is used to send management parameters to at least one of the sending module and the receiving module in the device. At least one of the sending module and the receiving module performs corresponding processing according to the management parameters; The management parameters include at least one of the following: packet size, total number of redundant data packets, and bypass flag for enabling forward error correction. The bypass flag indicates that when the network quality meets preset conditions, only the forward error correction header is added or checked without performing redundant calculations.

Images