Network service platform access method and device

Abstract

The network service platform access method is applied to a P4 switch, and comprises the following steps: in response to a detection trigger condition, generating a cloned copy for a target host data packet; identifying a data packet of the cloned copy, and executing a truncation operation to form a probe packet; dynamically storing a host active timestamp and a last detection timestamp through a register; when the difference value between the current timestamp and the host active timestamp is greater than a first threshold value and the difference value between the current timestamp and the last detection timestamp is greater than a second threshold value, sending a detection packet to the target port; if the response is not received within a third threshold time after the probe packet is sent, recording an abnormal event and updating an abnormal counter; wherein the third threshold value is used for representing a difference value between the current timestamp and the timestamp of any data packet of the target host received by the switch last time; and when five times of exceptions are accumulated in the preset sliding window duration, judging that the target port has a fault and triggering redirection. The method can avoid control plane interaction delay.

Description

Technical Field

[0001] This invention relates to the field of computer network and cloud service technology, and in particular to a method and apparatus for accessing a network service platform. Background Technology

[0002] With the widespread application of cloud computing, large-scale data centers, and edge computing, cloud-based network service platforms have become the core support of modern network architecture. Network functions virtualization (NFV) and software-defined networking (SDN) virtualize and centrally manage the functions of traditional dedicated hardware, enabling on-demand scheduling and dynamic expansion of network resources, greatly reducing operational complexity and accelerating service deployment. Although this technology can improve resource utilization and deployment flexibility, it still faces bottlenecks in ensuring high reliability. Most existing fault recovery mechanisms focus on the detection and switching of link-level faults, such as fast reroute (FRR) based on data plane signals or path recalculation schemes coordinated by the control plane. However, they lack effective means of sensing and responding to host-level faults such as server crashes, making it difficult to trigger traffic redirection in a timely manner. In addition, although some studies have used P4 programmable switches to achieve link fault detection and fast switching on the data plane, they are mostly limited to single-switch scenarios and lack multi-switch collaborative working mechanisms. Furthermore, in the face of sudden high concurrency or host failures in edge scenarios, it is difficult to guarantee no packet loss and low-latency switching. Summary of the Invention

[0003] To address the problems existing in the prior art, embodiments of this application provide a method, apparatus, computing device, computer storage medium, and product containing computer programs for reliable access to a network service platform, which can reduce fault detection latency and avoid control plane interaction latency through the data plane of a programmable switch.

[0004] In a first aspect, an embodiment of the present application provides a reliable access method for a network service-oriented platform, which is applied to a P4 switch. The method includes: in the Egress pipeline, in response to a detection trigger condition, performing a clone3 operation on a target host data packet to generate a cloned copy; modifying the EtherType field of the cloned copy to a preset fault detection identifier 0x9998, and injecting it into the Ingress pipeline through the recirculate function; in the Ingress pipeline, identifying a data packet with an instance type of the cloned copy and EtherType = 0x9998, performing a truncation operation, and retaining a 42-byte protocol header to form a detection packet; dynamically storing the host active timestamp alive_timestamp and the last detection timestamp lastsend through a register; when the difference between the current timestamp and the host active timestamp is greater than a first threshold, and the difference between the current timestamp and the last detection timestamp is greater than a second threshold are both satisfied, sending a detection packet to a target port; if no response is received within a third threshold time after sending the detection packet, recording an abnormal event and updating an abnormal counter; where the third threshold is used to represent the difference between the current timestamp and the timestamp when the switch last received any data packet from the target host; when 5 abnormalities are accumulated within a preset sliding window duration, determining that the target port is faulty and triggering a redirection.

[0005] In some possible implementation manners, the construction of the detection packet specifically includes: in the Egress pipeline, performing a truncation operation on the data packet of the cloned copy, and retaining a 42-byte protocol header including an Ethernet header, an IPv4 header, and a UDP header; in the Ingress pipeline, performing secondary verification on the recirculated packet and discarding the payload field.

[0006] In some possible implementation manners, the updating of the abnormal counter includes: calculating the time interval Δt between the current abnormality and the previous abnormality; if Δt is less than or equal to the preset sliding window duration, incrementing the abnormal counter, otherwise resetting it to 1.

[0007] In some possible implementation manners, the redirection includes: updating the port status bitmap through bitwise operation: portStatus = portStatus & ~(1 << p), where p is the faulty port number; calculating the lowest available port mask: lowest_one_mask = portStatus & (-portStatus); converting the mask to a physical port and a MAC address through a preset mapping table.

[0008] In some possible implementation manners, the redirection further includes: modifying the target MAC address of the cached data packet to the standby port MAC; injecting a redirection flag redirectFlag into the data packet header; updating the port matching table PortMap, and mapping the faulty port to the standby port.

[0009] In some possible implementations, the method further includes service packet caching control: performing a clone3 operation on ordinary service packets to generate replicas and marking the metadata field metadata.is_recircPac of the replicas as 1; the original packets are forwarded normally, and the replicas are cached cyclically using recirculate; when the value of the recirculation counter is greater than the preset maximum recirculation value, the replicas are discarded; when the packet sequence number seqNo is less than the latest acknowledgment number ackNo of the target port, the replicas are cleared; and the ackNo register is updated with packets whose source MAC address is the target port.

[0010] In some possible implementations, the ackNo update rule is as follows: parse the data packet whose source MAC address matches the target port in the Ingress pipe; extract the sequence number of the data packet and update the ackNo register: ackNo = packet.seqNo.

[0011] In some possible implementations, the first threshold is 500ms and the second threshold is 100ms.

[0012] In some possible implementations, the sliding window duration is 500ms and the third threshold is 250ms.

[0013] Secondly, embodiments of this application provide a reliable access device for a network service platform, deployed on a P4 switch. The device includes: an acquisition module, configured to generate a clone copy by performing a clone3 operation on a target host data packet in response to a probe trigger condition in the Egress pipe; a processing module, configured to modify the EtherType field of the clone copy to a preset fault detection identifier 0x9998, and inject it into the Ingress pipe via the recirculate function; the processing module is further configured to identify data packets with the instance type of the clone copy and EtherType = 0x9998 in the Ingress pipe, perform a truncation operation, and retain a 42-byte protocol header to form a probe packet; the processing module is further configured to use registers... The processing module dynamically stores the host's active timestamp (alive_timestamp) and the last probe timestamp (lastsend). It is further configured to send a probe packet to the target port when the difference between the current timestamp and the host's active timestamp is greater than a first threshold, and the difference between the current timestamp and the last probe timestamp is greater than a second threshold. The processing module is also configured to record an abnormal event and update an abnormality counter if no response is received within a third threshold time after sending the probe packet. The third threshold is used to characterize the difference between the current timestamp and the timestamp of the last time the switch received any data packet from the target host. The processing module is also configured to determine a target port failure and trigger redirection when 5 abnormalities are accumulated within a preset sliding window duration.

[0014] Thirdly, embodiments of this application provide a computer-readable storage medium including computer-readable instructions that, when read and executed by a computer, cause the computer to perform the method as described in any of the first aspects.

[0015] Fourthly, embodiments of this application provide a computing device, including a processor and a memory, wherein the memory stores computer program instructions, which, when executed by the processor, perform the method as described in any of the first aspects.

[0016] Fifthly, embodiments of this application provide a product comprising a computer program that, when the computer program product is run on a processor, causes the processor to perform the method as described in any of the first aspects. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a reliable access method for a network service platform provided in an embodiment of this application;

[0019] Figure 2 This is a schematic diagram of a process for constructing a probe data packet provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of a probe packet transmission process provided in an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of a process for detecting corresponding anomalies provided in an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of a reflow cached data packet provided in an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of a data packet redirection process provided in an embodiment of this application;

[0024] Figure 7 This is a line graph illustrating the relationship between the number of data packets sent by host h3 and received by host h2 over time, as provided in an embodiment of this application.

[0025] Figure 8 This is a diagram showing the total data transmission and reception volume of each host during the testing process, provided in an embodiment of this application.

[0026] Figure 9 This is a schematic diagram of the structure of a network service platform access device provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0029] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. For example, "first response message" and "second response message," etc., are used to distinguish different response messages, not to describe a specific order of response messages.

[0030] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0031] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0032] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0033] For example, Figure 1 This illustration shows a flowchart of a reliable access method for a network service platform provided in an embodiment of this application. The method is applied to a P4 programmable switch. Figure 1 As shown, the method may include the following steps:

[0034] S11: In response to detection conditions, complete the construction of a lightweight detection packet.

[0035] In this embodiment, in the switch's Egress pipe, when the dynamic probing conditions are met, a clone3(CloneType.E2E) operation is performed on the target host's data packets to generate a clone copy; the EtherType field of the copy is modified to a preset identifier value TYPE_PROB, which in this embodiment can be 0x9998, and injected into the Ingress pipe through the recirculate(meta) function; when an instance of type PKT_INSTANCE_TYPE_INGRESS_RECTRC and EtherType = 0x9998 are detected in the Ingress pipe, a truncate operation is performed to discard the payload, retaining a 42-byte protocol header (Ethernet 14B + IPv4 20B + UDP 8B) to form a lightweight probe packet.

[0036] For details, please refer to Figure 2 , Figure 2 This is a schematic diagram illustrating a process for constructing a probe data packet according to an embodiment of this application. Figure 2 As shown, when the switch detects an abnormal host activity state, and the probe trigger condition is met, a probe mechanism is triggered in the switch's Egress pipe, executing the construction operation of probe packets. At this time, the switch performs a clone3(CloneType.E2E) operation on the packet originally intended for the target host, cloning an identical replica packet. The cloning operation ensures that the replica inherits the complete state of the original packet after processing in the egress pipe. Next, the system rewrites the EtherType field of the replica packet from its original value to a preset fault detection identifier 0x9998. This fault detection identifier is used to quickly identify the probe packet in subsequent pipe processing. Then, the system re-injects this marked cloned replica packet into the switch's Ingress pipe by calling the recirculate function. When the injected replica packet enters the Ingress pipe, the system confirms two key characteristics: first, the packet instance type must be PKT_INSTANCE_TYPE_INGRESS_RECIRC (indicating it belongs to a return packet); second, the EtherType field is confirmed to be 0x9998. When both conditions are met, the data packet is truncated, retaining only the basic 42-byte protocol header, including a 14-byte Ethernet header, a 20-byte IPv4 header, and an 8-byte UDP header, while discarding the rest of the payload. Truncating significantly reduces probe packet size and avoids additional bandwidth consumption.

[0037] In some possible embodiments, a truncation operation can be performed on the generated clone copy after it has been generated. Then, after confirming that the packet instance type and the EtherType field are both satisfied, a second truncation operation is performed. It is worth noting that although the second truncate operation nominally discards the payload again, since the first truncate operation already discarded the payload and retained only the header, the second truncate operation actually serves as a redundancy check, ultimately ensuring that the probe packet contains only a 42-byte pure protocol header, forming a minimal probe structure.

[0038] In this way, the Egress pipeline is responsible for generating tags and pruning, while the Ingress pipeline completes the final verification. The entire process is completed entirely in the data plane, without relying on the control plane, significantly reducing the latency of probe packet construction. The final lightweight probe packet is sent to the target host. Its minimalist structure significantly reduces interference with business traffic, while retaining sufficient network layer information (such as IP / UDP headers) to support end-to-end reachability verification.

[0039] S12: Fault determination is based on a preset sliding window.

[0040] In this embodiment, probe data packets are dynamically sent, and the host's active timestamp (alive_timestamp) and the last probe timestamp (lastsend) are stored in real time through registers. The system detects whether the current timestamp (currentTime) simultaneously satisfies the following two equations:

[0041] (currentTime-alive_timestamp) > first threshold t1

[0042] (currentTime - lastsend) > second threshold t2

[0043] If both conditions are met simultaneously, a probe data packet is sent. A sliding window is used to identify faults, avoiding misjudgments caused by single network anomalies. Probe data packets are dynamically sent. If no probe response is received from the target port within the anomaly judgment time difference threshold t3 after sending the probe data packet, it is considered an anomaly. After an anomaly is triggered, the current timestamp is obtained and the interval Δt between it and the previous anomaly timestamp is calculated. If this interval is less than the preset sliding window duration T, the anomaly counter is incremented. If the interval exceeds T, the anomaly counter is reset to its initial value of 1. When the anomaly counter within the window exceeds the set threshold 5, the target port is confirmed to be faulty.

[0044] In some possible embodiments, the first threshold t1 is 500ms and the second threshold t2 is 100ms.

[0045] For example, Figure 3 A schematic diagram of the probe packet transmission process is shown. For example... Figure 3As shown, the switch initializes two registers for each access host's port number: `alive_timestamp` to record the host's last active time and `lastsend` to record the last probe time. Both registers are initially set to the system startup timestamp. During switch operation, whenever a data packet is received from a host and enters the Ingress pipe, the system immediately checks the port number corresponding to its source MAC address and writes the current system timestamp to the `alive_timestamp` register corresponding to that port, proving that the host is still communicating normally. Simultaneously, the system continuously maintains the `lastsend` register set. Whenever a probe packet is sent to a specific host port, the system records the timestamp of the sending moment in the `lastsend` register corresponding to that port, forming the timestamp of the last active probe. In the switch's background processing loop, the system continuously extracts the current timestamp `currentTime` and calculates two key differences: `currentTime - alive_timestamp`, which reflects the host's inactivity duration and is recorded as the first difference. The other is `currentTime-lastsend`, which measures the time interval since the last probe. This difference is recorded as the second difference. When both the first and second differences exceed the first threshold, the host is determined to be inactive or in an abnormal state. At this point, the probe mechanism is immediately triggered, sending a lightweight probe packet to the target port. After the probe packet is sent, the system synchronously updates the `lastsend` register to the current timestamp, ensuring that subsequent probe intervals meet the requirements.

[0046] Figure 4 A flowchart illustrating the detection process for corresponding anomalies is shown. For example... Figure 4As shown, after a probe packet is successfully sent from the switch's Egress pipe, the system starts a timer and records the precise timestamp of the sending time in the `last_send_timestamp` register. Simultaneously, the system initializes another register, `last_recv_timestamp`, which stores the timestamp of the last time the switch received any packet from the host. If this register is not initialized, it can be filled with the system startup time or the most recent reception time as a reference. The system enters a listening state in the Ingress pipe, filtering probe response packets from the target port. If no response packet is received within the set anomaly detection time difference threshold `t3`, meaning the difference between the current timestamp `currentTime` and `last_recv_timestamp` exceeds the anomaly detection time difference threshold `t3` (i.e., `(currentTime – last_recv_timestamp) > t3`), the system marks this event as an anomaly. Timeout detection can effectively capture network latency or host unresponsiveness anomalies. Once an anomaly event is triggered, the system enters a dynamic counting phase. First, the timestamp of the last exception, `last_abnormal_time`, is read, and the interval Δt between the current time and the last exception is calculated (i.e., Δt = currentTime – last_abnormal_time). The system presets a sliding window duration T (e.g., 500ms) as a threshold. If Δt is less than or equal to 500ms, it means that the current exception occurred within the same time window as the last one, and the exception counter `exception_count` is automatically incremented by 1 (i.e., `exception_count = exception_count + 1`). Conversely, if Δt exceeds 500ms, it means that a new time window has been entered, and the system resets `exception_count` to its initial value of 1, ensuring that the counting logic focuses on densely occurring exception events rather than isolated incidents. Afterward, the system immediately updates the `last_abnormal_time` register to the current timestamp, providing the latest baseline for the next exception interval calculation and maintaining state consistency. When the cumulative value of the exception counter reaches or exceeds the preset fault determination threshold M (e.g., 5 times), the system confirms it as a persistent fault (e.g., host crash or link interruption) and immediately initiates the fault handling process. This ensures that interference from occasional failures (such as the loss of a single word) can be avoided.

[0047] S13: Packet backflow buffer.

[0048] In this embodiment, all input data packets are cloned to generate copies, and the copies are marked as recirculation packets; the original packets are forwarded normally, and the copies are circularly cached in the Ingress pipeline through the recirculate function, so that when a fault is detected, the data packet cache during the occurrence and detection of the fault can be redirected to the standby host to ensure data integrity. At the same time, the hardware pressure is reduced by discarding the cache through the following three conditions:

[0049] Discard when the recirculation counter loop_count > MAX_LOOP_COUNT. The value of MAX_LOOP_COUNT can be 3.

[0050] Clear when it is detected that the data packet sequence number seqNo < ackNo (the latest confirmation number of the target port). Among them, the latest confirmation number ackNo of the target port is updated by analyzing the data packets entering the switch and having the source MAC address of the target port.

[0051] Terminate recirculation and activate redirection when the host fault status is confirmed.

[0052] Specifically, Figure 5 shows a schematic diagram of the process of recirculation caching data packets. As Figure 5 shown, when a data packet enters the Ingress pipeline of the switch, the system first performs service packet filtering: check whether the EtherType field of the data packet is equal to the fault detection identifier TYPE_PROB (0x9998), and at the same time verify whether there is a redirection identifier redirectFlag. Only ordinary service data packets that completely exclude these two special tags will enter the subsequent caching process. The filtering mechanism can ensure that probe packets and redirected packets are not processed repeatedly, avoiding resource waste. For the qualified original service packets, the system executes the clone3(CloneType.I2E) operation to generate an exact copy. This cloning mode (Ingress-to-Egress) can ensure that the copy inherits the complete processing status of the original packet in the ingress pipeline. Set the metadata field metadata.is_recircPac of the copy to 1, that is, mark the data packet with a special identifier exclusive to recirculation caching, and mark it as a recirculation caching data packet. The original data packet continues the normal forwarding process without affecting real-time service transmission. The marked copy packet is re-injected into the Ingress pipeline entrance through the recirculate() function to achieve circular caching. Each time of recirculation, the recirculation counter loop_count maintained in the metadata by the system is automatically incremented by 1 (i.e., loop_count = loop_count + 1), recording the number of times the data packet circulates in the pipeline. At the same time, the system sets a triple termination mechanism to prevent infinite recirculation.

[0053] The first layer is forced counting termination. When the value of the return counter is greater than the preset maximum return value (loop_count > MAX_LOOP_COUNT), a discard operation is performed to forcefully discard the current return packet, avoiding excessive consumption of switch resources.

[0054] The second layer is sequence number-driven cleaning. The sequence number seqNo of the return packet is compared with the latest acknowledgment number ackNo of the target port in real time. When seqNo < ackNo, it indicates that the packet has been acknowledged and received by the target host, and a clear operation is immediately performed to clear the return packet. The update mechanism of the acknowledgment number ackNo of the target port is also completed in the Ingress pipeline. When a data packet with a source MAC address matching the target port is detected, its sequence number is extracted and the register ackNo = packet.seqNo is updated.

[0055] The third layer is fault linkage termination. When a host failure is confirmed, the return of all associated cached packets is automatically terminated, triggering redirection. When the host is not faulty, the return counter is incremented by 1 and enters the next round of loop caching.

[0056] S14: Perform traffic redirection.

[0057] In this embodiment, after confirming that the port p is connected to a host failure, the following operations are performed: Update the status of port p through bitwise operation:

[0058] portStatus = portStatus & ~(1 << p)

[0059] Calculate the lowest available port mask:

[0060] lowest_one_mask = portStatus & (-portStatus)

[0061] Convert the lowest available port mask to a physical port number through a preset mapping table, modify the destination MAC address of the cached data packet to the MAC address corresponding to the physical port number of the lowest available port, and inject a redirection flag into the data packet header. At the same time, update the port matching table. The matching table is used to map the original sending port to the actual sending port. After confirming the failure, map the original faulty port to a new standby port to switch the path for subsequent traffic.

[0062] Specifically, please refer to Figure 6, during fault handling, when the system confirms that port p has failed through the sliding window mechanism, it first performs port status bitmap update. By means of bit operation portStatus = portStatus & ~(1 << p), the status bit corresponding to the faulty port is cleared, and the status bits of other ports remain unchanged. For example, if the original status bitmap is 0b1101 (ports 0, 2, and 3 are active), when port 2 fails, the result after operation is 0b1001. Next, the system calculates the lowest available port mask. Using the complement code feature, it executes lowest_one_mask = portStatus & (-portStatus). This operation directly locates the lowest "1" in the status bitmap. For example, if portStatus = 0b1001, the calculation result is 0b0001, which corresponds to physical port 0. After obtaining the binary mask, the system queries the pre-set mapping table. First, it converts lowest_one_mask to a specific port number through the physical port mapping table (for example, mask 0b0001 is mapped to port 0), and then obtains the MAC address of the standby port according to the port-MAC address mapping table (for example, port 0 corresponds to MAC00:1a:4b:59:20). Then, the system modifies the data packets in the cache pool, replaces the destination MAC addresses of all service packets marked as return flow with the MAC of the just-obtained standby port, and injects a redirection identifier redirectFlag into the data packet header for subsequent pipeline to identify the redirected traffic. After completing the modification of the data packets, the system updates the mapping relationship of the port matching table PortMap, changes the mapping from the original faulty port p to the actual sending port to the new port (for example, the original mapping port 2 -> port 2 is updated to port 2 -> port 0). This table directly acts on the matching stage of the Ingress pipeline in the future, ensuring that all traffic directed to the faulty port automatically switches to the standby port, forming a permanent path switch. Finally, the switch normally sends out the modified data packets from the standby port, and at the same time clears the return flow status of this batch of cached packets to release resources.

[0063] The above is the reliable access method for the network service platform provided by the embodiments of this application. In order to verify the stability and fault handling ability of the system, the embodiments of this application construct a network simulation environment containing a P4 programmable switch to conduct fault-free and fault-switching scenario tests. Use the Mininet 3.0 network emulator to construct a network composed of two P4 bmv2 switches (s1, s2) and hosts (h1, h2, h3), where hosts h1 and h2 are connected to s1, host h3 is connected to s2, and switches s1 and s2 are connected. In the fault-free test scenario, host h3 continuously sends data packets to host h1 through iperf, and h1 can normally receive and timely reply to the probe data packets, and the switch status register maintains the host status as "normal". No error detection or redirection behavior is triggered in the whole process.

[0064] To simulate a host failure, the experiment interrupted the probe response script of host h1, causing the switch to not receive a probe response from h1 within a set time t3. Following its design logic, the system entered an anomaly counting mechanism, ultimately setting the h1 host status to failed (status value 0) and updating it in the port status register. Subsequently, the system automatically redirected traffic from the port originally destined for h1 to the preset backup port h2, and buffered and delayed the transmission of data packets originally sent to h1 but not successfully received.

[0065] Figure 7 The graph shows the relationship between the number of data packets sent by host h3 and received by host h2 over time. As can be seen from the graph, h2 did not receive any data in the initial stage of the downtime, but after the handover, its received data rapidly increased and closely matched the sending data of h3. Particularly during a certain time window in the early stages of the handover, the number of packets received by h2 was significantly higher than the real-time sending data of h3, indicating that the system successfully buffered and reverted the originally lost data packets. Figure 8 The total data transmission and reception volume of each host during the test was statistically analyzed. h3 sent 1858 data packets, h2 received 1855, and h1 received only 16. The overall data packet loss rate during the test was calculated to be approximately 0.16%, verifying the high availability of the system under the fault detection, data caching, and path switching mechanisms. In summary, the experiment fully demonstrates that the fault detection and data redirection scheme based on a programmable switch proposed in this invention possesses good accuracy, stability, and fault tolerance, meeting the high reliability requirements of network systems.

[0066] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. Furthermore, in some possible implementations, each step in the above embodiments may be selectively executed according to actual circumstances; it may be partially or fully executed, without limitation here. All or part of any feature of any embodiment of this application can be freely and arbitrarily combined without contradiction. The combined technical solutions are also within the scope of this application.

[0067] Based on the methods in the above embodiments, this application also provides a network service platform access device. For example, Figure 9 A schematic diagram of the network service platform access device is shown. Figure 9 As shown, the device 900 includes an acquisition module 901 and a processing module 902.

[0068] Among them, the acquisition module 901 is used to generate a clone copy by performing a cl one3 operation on the target host data packet in response to the probe triggering condition in the Egress pipeline;

[0069] Processing module 902 is used to modify the EtherType field of the cloned copy to a preset fault detection identifier 0x9998 and inject it into the Ingress pipeline through the recirculate function;

[0070] Processing module 902 is also used to identify the instance type of the cloned copy and the data packet with EtherType=0x9998 in the Ingress pipeline, perform a truncation operation, and retain a 42-byte protocol header to form a probe packet;

[0071] Processing module 902 is also used to dynamically store the host active timestamp (alive_timestamp) and the last probe timestamp (lastsend) through registers;

[0072] The processing module 902 is further configured to send a probe packet to the target port when the difference between the current timestamp and the host active timestamp is greater than a first threshold and the difference between the current timestamp and the last probe timestamp is greater than a second threshold.

[0073] The processing module 902 is further configured to record an abnormal event and update an abnormal counter if no response is received within a third threshold time after sending the probe packet; wherein, the third threshold is used to characterize the difference between the current timestamp and the timestamp of the last time the switch received any data packet from the target host;

[0074] The processing module 902 is also used to determine the target port failure and trigger redirection when five abnormalities are accumulated within a preset sliding window duration.

[0075] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0076] Based on the methods in the above embodiments, this application provides a computer program product that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0077] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0078] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0079] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0080] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. A method for accessing a network service platform, characterized in that, Applied to a P4 switch, the method includes: In the Egress pipeline, in response to a detection trigger condition, perform a clone3 operation on the target host packet to generate a cloned copy; Modify the EtherType field of the cloned copy to a preset fault detection identifier 0x9998, and inject it into the Ingress pipeline through the recirculate function; In the Ingress pipeline, identify packets with an instance type of the cloned copy and EtherType = 0x9998, perform a truncation operation, and retain a 42-byte protocol header to form a detection packet; Dynamically store the host active timestamp alive_timestamp and the last detection timestamp lastsend through registers; When the difference between the current timestamp and the host active timestamp is greater than a first threshold, and the difference between the current timestamp and the last detection timestamp is greater than a second threshold, send the detection packet to the target port; If no response is received within a third threshold time after sending the detection packet, record an abnormal event and update the anomaly counter; where the third threshold is used to represent the difference between the current timestamp and the timestamp of the last packet received from the target host by the switch; When 5 anomalies are accumulated within a preset sliding window duration, determine that the target port is faulty and trigger redirection.

2. The method according to claim 1, characterized in that, The specific construction of the detection packet includes: In the Egress pipeline, perform a truncation operation on the packet of the cloned copy, and retain a 42-byte protocol header including an Ethernet header, an IPv4 header, and a UDP header; In the Ingress pipeline, perform secondary verification on the recirculated packet and discard the payload field.

3. The method according to claim 1, characterized in that, The updating of the anomaly counter includes: Calculate the time interval Δt between the current anomaly and the previous anomaly; If Δt is less than or equal to the preset sliding window duration, increment the anomaly counter, otherwise reset it to 1.

4. The method according to claim 1, characterized in that, The redirection includes: Update the port status bitmap through bitwise operation: portStatus = portStatus & ~(1 << p), where p is the faulty port number; Calculate the lowest available port mask: lowest_one_mask = portStatus & (-portStatus); Convert the mask to a physical port and MAC address through a preset mapping table.

5. The method according to claim 4, characterized in that, The redirection further includes: Modify the target MAC address of the cached packet to the standby port MAC; Inject a redirection flag redirectFlag into the data packet header; Update the port matching table PortMap to map the faulty port to the standby port.

6. The method according to claim 1, characterized in that, The method further includes service packet cache control: Perform a clone3 operation on ordinary service packets, generate a copy, and mark the metadata field metadata.is_recircPac of the copy as 1; Forward the original packet normally, and cache the copy through recirculate; Discard the copy when the value of the recirculation counter is greater than the preset recirculation maximum value; Clear the copy when the packet sequence number seqNo is less than the latest acknowledgment number ackNo of the target port; The ackNo register is updated when a data packet with the source MAC address as the destination port is used.

7. The method according to claim 6, characterized in that, The ackNo update rule is as follows: The Ingress pipeline parses data packets whose source MAC address matches the target port; Extract the sequence number of the data packet and update the ackNo register: ackNo = packet.seqNo.

8. The method according to any one of claims 1-7, characterized in that, The first threshold is 500ms, and the second threshold is 100ms.

9. The method according to claim 1, characterized in that, The duration of the sliding window is 500ms, and the third threshold is 250ms.

10. A network service platform access device, characterized in that, Deployed on a P4 switch, the device includes: The acquisition module is used in the Egress pipeline to perform the cl one3 operation on the target host data packets in response to the probe triggering condition to generate clone copies; The processing module is used to modify the EtherType field of the cloned copy to a preset fault detection identifier 0x9998 and inject it into the Ingress pipeline through the recirculate function; The processing module is also used to identify data packets with instance type of cloned copy and EtherType=0x9998 in the Ingress pipeline, perform a truncation operation, and retain a 42-byte protocol header to form a probe packet; The processing module is also used to dynamically store the host active timestamp (alive_timestamp) and the last probe timestamp (lastsend) in a register; The processing module is further configured to send the probe packet to the target port when the difference between the current timestamp and the host active timestamp is greater than a first threshold and the difference between the current timestamp and the last probe timestamp is greater than a second threshold. The processing module is further configured to record an abnormal event and update an abnormal counter if no response is received within a third threshold time after sending the probe packet; wherein, the third threshold is used to characterize the difference between the current timestamp and the timestamp of the last time the switch received any data packet from the target host; The processing module is also used to determine the target port is faulty and trigger redirection when five anomalies are accumulated within a preset sliding window duration.

Images