Message processing method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of communication, and provides a message processing method and device, electronic equipment and a storage medium. A periodic dynamic decision-making mechanism is introduced into an SDN controller; the SDN controller comprehensively judges and generates a new compression strategy based on the real-time detection result of the service flow reported by the source node, the SID number in the segment list of the current forwarding path and the service demand of the service flow, when the new compression strategy is consistent with the current compression strategy, the existing configuration is kept unchanged, and when the new compression strategy is not consistent with the current compression strategy, the new compression strategy is not changed. And updating the segment list of the current forwarding path according to the new compression strategy to generate a new forwarding path, and issuing the new forwarding path to the source node for execution, so that the source node can dynamically adjust the compression strategy according to real-time network states (such as congestion and time delay) and service requirements (such as low time delay and high bandwidth). Dynamic matching between network resources and service requirements is realized, and the overall network efficiency is optimized while the service experience is guaranteed.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a message processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of 5G networks, data centers, and computing networks, SRv6 (Segment Routing over IPv6) technology has been widely adopted due to its advantages of flexible path control and simplified network architecture. In SRv6, a forwarding path is represented by a segment list consisting of one or more SIDs (Segment Identifiers), which is typically configured in the source node. G-SRv6 (Generalized SRv6) is an extension of SRv6 that reduces packet overhead and improves network efficiency by compressing the SIDs in the segment list. However, existing G-SRv6 compression technologies are mostly statically pre-configured and cannot dynamically adjust compression strategies based on real-time network conditions (such as congestion and latency) and service requirements (such as low latency and high bandwidth). This results in the overhead reduction from compression not being able to offset processing latency in some scenarios, and even leading to performance degradation. Summary of the Invention

[0003] The purpose of this application is to provide a message processing method, apparatus, electronic device, and storage medium to improve the above-mentioned problems.

[0004] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a packet processing method applied to a software-defined network (SDN) controller, the packet processing method comprising: Receive real-time detection results of the service flow sent by the source node, wherein the real-time detection results are generated based on performance data obtained by performing flow-following detection on the service flow; At the arrival of each preset decision cycle, a new compression strategy is generated based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. If the new compression strategy is different from the current compression strategy, the segment list of the current forwarding path is updated according to the new compression strategy to generate a new forwarding path, and the new forwarding path is sent to the source node to update the forwarding configuration of the service flow.

[0005] Optionally, the real-time detection results include end-to-end latency, path packet loss rate, and link bandwidth utilization. The step of generating a new compression strategy based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow includes: If the number of SIDs is less than or equal to a set number and the end-to-end delay is less than or equal to a set delay, then the new compression strategy is determined to be in non-compression mode. If the end-to-end delay is greater than the set delay and the path packet loss rate is greater than the set packet loss rate, then the new compression strategy is determined to be in non-compression mode. If the number of SIDs is greater than the set number, the end-to-end delay is less than or equal to the set delay, and the path packet loss rate is less than or equal to the set packet loss rate, then it is determined that the general IPv6 segment routing G-SRv6 compression is enabled, and the compression algorithm of the G-SRv6 compression is selected according to the link bandwidth utilization to obtain the new compression strategy.

[0006] Optionally, the G-SRv6 compression algorithm includes a 32-bit compression algorithm and a 16-bit compression algorithm; The step of selecting the G-SRv6 compression algorithm based on the link bandwidth utilization includes: If the link bandwidth utilization is greater than the set value, then the 32-bit compression algorithm is selected; If the link bandwidth utilization is less than or equal to the set value, then the 16-bit compression algorithm is selected.

[0007] Optionally, before the step of receiving the real-time detection results of the service flow sent by the source node, the message processing method further includes: Based on the currently acquired network topology information, link status, SID capability information of each node, and service requirements of the service flow, a segment list of the initial forwarding path is generated, and the compression strategy of the segment list of the initial forwarding path is configured to be uncompressed. The initial forwarding path is sent to the source node so that when the source node receives the service flow, it encapsulates the message in the uncompressed mode and forwards it along the initial forwarding path. A configuration instruction is issued to the source node, which instructs the source node to embed probe information during the encapsulation of the service flow to start flow detection, and to receive performance data returned by each measurement node on the current forwarding path, generate real-time probe results of the service flow and send them to the SDN controller.

[0008] Secondly, embodiments of this application provide a message processing method applied to a source node, the message processing method comprising: Based on the performance data obtained by performing flow detection on the service flow, the real-time detection results of the service flow are generated and sent to the software-defined network (SDN) controller. The system receives a new forwarding path generated by updating the segment list of the current forwarding path according to the new compression strategy issued by the SDN controller. The new compression strategy is generated by the SDN controller at the time of each preset decision period based on real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. The service flow is encapsulated according to the segment list of the new forwarding path and forwarded along the new forwarding path.

[0009] Optionally, before the step of generating real-time detection results of the service flow based on the performance data obtained from flow-based detection of the service flow and sending them to the SDN controller, the packet processing method further includes: The initial forwarding path is received from the SDN controller. The initial forwarding path is a segment list generated by the SDN controller based on the currently acquired network topology information, link status, SID capability information of each node, and service requirements of the service flow. The compression strategy of the segment list of the initial forwarding path is uncompressed mode. Upon receiving the service flow, the message is encapsulated in the uncompressed mode and forwarded along the initial forwarding path.

[0010] Optionally, the step of generating real-time detection results of the service flow based on the performance data obtained from flow-based detection of the service flow and sending them to the SDN controller includes: In response to the flow detection start command issued by the SDN controller, probe information is embedded during the encapsulation of the service flow to start flow detection of the service flow; The system receives performance data returned by each measurement node on the current forwarding path, generates real-time detection results for the service flow, and sends the real-time detection results to the SDN controller.

[0011] Thirdly, embodiments of this application provide a packet processing apparatus applied to a software-defined network (SDN) controller, the packet processing apparatus comprising: The detection result receiving module is used to receive the real-time detection results of the service flow sent by the source node, wherein the real-time detection results are generated based on the performance data obtained by performing flow-following detection on the service flow; A periodic decision-making module is used to generate a new compression strategy based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow when each preset decision period arrives. If the new compression strategy is different from the current compression strategy, the segment list of the current forwarding path is updated according to the new compression strategy to generate a new forwarding path, and the new forwarding path is sent to the source node to update the forwarding configuration of the service flow.

[0012] Fourthly, embodiments of this application provide a message processing apparatus applied to a source node, the message processing apparatus comprising: The detection result sending module is used to generate real-time detection results of the service flow based on the performance data obtained by performing flow-following detection on the service flow and send them to the software-defined network (SDN) controller. The decision result receiving module is used to receive the new forwarding path generated by the SDN controller based on the segment list of the current forwarding path updated according to the new compression strategy. The new compression strategy is generated by the SDN controller at the time of each preset decision period based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. The decision result execution module is also used to encapsulate the service flow according to the segment list of the new forwarding path and forward it along the new forwarding path.

[0013] Fifthly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory is used to store a program, and the processor is used to implement the message processing method in the first aspect above, or the message processing method in the second aspect above, when executing the program.

[0014] In a sixth aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the message processing method in the first aspect above, or the message processing method in the second aspect above.

[0015] Compared to existing technologies, the message processing method, apparatus, electronic device, and storage medium provided in this application introduce a periodic dynamic decision-making mechanism in the SDN controller. At the arrival of each preset decision period, the SDN controller comprehensively judges and generates a new compression strategy based on the real-time detection results of the service flow reported by the source node, the number of SIDs in the segment list of the current forwarding path, and the service requirements of the service flow. When the new compression strategy is consistent with the current compression strategy, the existing configuration remains unchanged. When they are inconsistent, the segment list of the current forwarding path is updated according to the new compression strategy to generate a new forwarding path, which is then sent to the source node for execution. This enables the source node to dynamically adjust the compression strategy according to real-time network conditions (such as congestion and latency) and service requirements (such as low latency and high bandwidth), achieving dynamic matching between network resources and service requirements, and optimizing overall network efficiency while ensuring service experience. Attached Figure Description

[0016] Figure 1 A schematic diagram of an application scenario provided by an embodiment of this application is shown.

[0017] Figure 2 This application provides a flowchart illustrating a packet processing method for an SDN controller. Figure 1 .

[0018] Figure 3 This application provides a flowchart illustrating a packet processing method for an SDN controller. Figure 2 .

[0019] Figure 4 This application provides a flowchart illustrating a message processing method applied to a source node. Figure 1 .

[0020] Figure 5 This application provides a flowchart illustrating a message processing method applied to a source node. Figure 2 .

[0021] Figure 6 The diagram shows a block illustration of a packet processing apparatus for an SDN controller provided in an embodiment of this application.

[0022] Figure 7 The diagram shows a block illustration of a message processing apparatus applied to a source node according to an embodiment of this application.

[0023] Figure 8 A block diagram of an electronic device provided in an embodiment of this application is shown.

[0024] Icons: 100, 200 - Message processing device; 101 - Initial configuration module; 102 - Detection result receiving module; 103 - Periodic decision module; 201 - Configuration execution module; 202 - Detection result sending module; 203 - Decision result receiving module; 204 - Decision result execution module; 10 - Electronic device; 11 - Processor; 12 - Memory; 13 - Communication module. Detailed Implementation

[0025] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0026] Please refer to Figure 1 , Figure 1 The diagram illustrates an application scenario, including an SDN (Software Defined Networking) controller, a source node, intermediate forwarding nodes, a destination node, a source host, and a destination host.

[0027] It should be noted that the intermediate forwarding nodes in the figure are only examples. Those skilled in the art should understand that in reality there may be one or more intermediate forwarding nodes, depending on the forwarding path generated by the SDN controller. Different forwarding paths contain different intermediate forwarding nodes.

[0028] The SDN controller is deployed in the control plane and connects to other components across the network via logical or physical links. In practical applications, administrators pre-configure the SLA (Service Level Agreement) requirements for various services through the SDN controller, such as requiring a maximum allowable latency of ≤20ms for "low-latency transaction services." Simultaneously, they configure the mapping relationship between services and IP address ranges, specifying which source / destination IP addresses correspond to specific service types (such as video conferencing, data backup, etc.).

[0029] When new service requirements arise, the SDN controller collects network topology information, link status (such as available bandwidth, latency, node load, etc.), and SID (Segment Identifier) ​​capability information of each node through the BGP-LS (Border Gateway Protocol - LinkState) protocol. It then generates an initial forwarding path using standard SIDs (uncompressed) based on the service SLA requirements. After generating the initial forwarding path, the SDN controller distributes it to the source node. Simultaneously, the controller triggers a flow-following detection mechanism for the relevant service flow, instructing the source node to embed probe information into data packets matching the service characteristics. This information is used to collect performance metrics such as latency and packet loss during actual transmission.

[0030] Meanwhile, the SDN controller has a built-in intelligent policy engine that, during the service flow forwarding process, comprehensively determines whether to enable G-SRv6 compression based on the real-time probe results sent by the source node, the number of SIDs in the segment list of the current forwarding path, and service requirements. When it is determined that G-SRv6 compression should be enabled, an appropriate compression algorithm (16-bit or 32-bit) is selected, and finally the new forwarding path after updating the segment list through BGP-SR-Policy (Border Gateway Protocol Segment Routing Policy) is sent to the source node for execution.

[0031] The source node, intermediate forwarding node, and destination node are all network devices that support the SRv6 / G-SRv6 protocol stack. They also support flow detection, which can embed timestamps and sequence numbers into real service flows to achieve lossless measurement of key performance indicators such as end-to-end latency, jitter, and packet loss rate.

[0032] The source node connects to the source host and is used to encapsulate and forward service flows from the source host using SRv6 according to instructions issued by the SDN controller. When the source node receives a service flow from the source host for the first time, it forwards it according to the initial forwarding path issued by the SDN controller. During the forwarding process, the path information is not compressed, and the complete hop-by-hop forwarding sequence is preserved. At the same time, probe information is embedded in the process of encapsulating the service flow to initiate flow-following detection. Subsequently, it receives performance data returned by each measurement node (including intermediate forwarding nodes and destination nodes), periodically summarizes the data to generate real-time probe results, and sends them to the SDN controller.

[0033] Intermediate forwarding nodes are located between the source node and the destination node. During the service flow forwarding process, they collect performance data and send it to the source node, which then aggregates the data and sends it to the SDN controller.

[0034] The destination node connects to the destination host. When it receives a service flow from the last intermediate forwarding node, it collects performance data and sends it to the source node, while simultaneously forwarding the service flow to the destination host.

[0035] During service flow forwarding, the source node aggregates the performance data sent by each measurement node according to a set sampling period, generates real-time probe results, and sends them to the SDN controller. At the arrival of each preset decision period (e.g., 30 seconds), the SDN controller, based on the real-time probe results reported by the source node, the number of SIDs in the segment list of the current forwarding path of the service flow, and the service requirements corresponding to the service flow, comprehensively judges and generates a new compression strategy. When the new compression strategy is consistent with the current compression strategy, the existing configuration remains unchanged. When they are inconsistent, the segment list of the current forwarding path is updated according to the new compression strategy to generate a new forwarding path, and the new forwarding path is sent to the source node for execution. This allows the source node to dynamically adjust the compression strategy according to real-time network conditions (such as congestion and latency) and service requirements (such as low latency and high bandwidth), achieving dynamic matching between network resources and service requirements, and optimizing overall network efficiency while ensuring service experience.

[0036] The message processing method provided in the embodiments of this application will be described in detail below.

[0037] Please refer to Figure 2 , Figure 2 A schematic flowchart of a message processing method provided in an embodiment of this application is shown. This message processing method is applied to... Figure 1 The SDN controller in the system may include the following steps: S101, Receive the real-time detection results of the service flow sent by the source node, wherein the real-time detection results are generated based on the performance data obtained by performing flow detection on the service flow; S102, when each preset decision cycle arrives, a new compression strategy is generated based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. S103. If the new compression strategy is different from the current compression strategy, the segment list of the current forwarding path is updated according to the new compression strategy to generate a new forwarding path, and the new forwarding path is sent to the source node to update the forwarding configuration of the service flow.

[0038] In step S101, the real-time detection result is generated by the source node based on the performance data obtained by performing flow detection on the service flow. The performance data is collected by each measurement node on the service flow forwarding path during the forwarding process and uniformly transmitted back to the source node. The source node summarizes the performance data from different nodes according to the set sampling period, generates the real-time detection result, and sends it to the SDN controller.

[0039] Optionally, real-time detection results may include, but are not limited to, end-to-end latency, path packet loss rate, and link bandwidth utilization. End-to-end latency can be the average latency calculated by embedding timestamps in the service flow and sampling at a set period (e.g., 500ms). Path packet loss rate can be the packet loss rate of the service flow statistically analyzed at a set sampling period (e.g., 1s). Link bandwidth utilization can be obtained from the source node using a telemetry model at a set sampling period (e.g., 1s).

[0040] In step S102, a periodic dynamic decision-making mechanism is introduced into the SDN controller. At the end of each preset decision period (e.g., 30 seconds), the SDN controller comprehensively judges and generates a new compression strategy based on the real-time detection results of the service flow, the number of SIDs in the segment list of the current forwarding path, and the service requirements of the service flow. The real-time detection results reflect the actual service quality performance of the service flow under the current forwarding path. The number of SIDs in the segment list of the current forwarding path refers to the number of SIDs actually used on the current forwarding path in G-SRv6. For example, if the segment list is [1,2,3], then the number of SIDs is 3. A higher number of SIDs usually means a more detailed path description but also higher header overhead. The service requirements of the service flow are pre-configured by the administrator and typically include SLA constraints such as bandwidth, maximum allowable latency, jitter tolerance, and reliability level. The SDN controller generates a new compression strategy through joint analysis of the above three types of information. This new compression strategy indicates whether to compress the current forwarding path and the corresponding degree of compression.

[0041] Optionally, the SDN controller is equipped with an intelligent policy engine. By inputting the real-time detection results of flow detection, the number of SIDs in the current forwarding path, and the service requirements of the service flow into the intelligent policy engine, the intelligent policy engine makes a comprehensive judgment and dynamic adjustment, and finally outputs a new compression policy.

[0042] In one possible implementation, step S102, which generates a new compression strategy based on real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow, may include: If the number of SIDs is less than or equal to the set number and the end-to-end latency is less than or equal to the set latency, then the new compression strategy is determined to be non-compression mode. If the end-to-end latency is greater than the set latency and the path packet loss rate is greater than the set packet loss rate, then the new compression strategy is determined to be uncompressed mode. If the number of SIDs is greater than the set number, the end-to-end delay is less than or equal to the set delay, and the path packet loss rate is less than or equal to the set packet loss rate, then the G-SRv6 compression of the general IPv6 segment route is enabled, and the compression algorithm of G-SRv6 compression is selected according to the link bandwidth utilization to obtain a new compression strategy.

[0043] Optionally, the number can be set to 3. The set latency can be determined based on industry experience with network performance fluctuations (typically network latency fluctuations are within 5%) and service experience guarantees (avoiding unnecessary compression decisions due to slight latency fluctuations). It is usually taken as 95% of the maximum allowable latency required by the service SLA. For example, if the maximum allowable latency is 20ms, then the set latency is 19ms. The set packet loss rate can be 0.1%.

[0044] In other words, if the number of SIDs is ≤3 and the end-to-end latency is ≤SLA×95%, where SLA represents the maximum allowable latency required by the service SLA, it indicates that the current forwarding path is a low SID path. Enabling compression may introduce processing jitter, causing the SLA to fail to meet the standard. Therefore, the new compression strategy is determined to be non-compression mode.

[0045] If the end-to-end latency is greater than SLA×95% and the path packet loss rate is greater than 0.1%, it indicates that the latency is close to the SLA limit and the packet loss rate is high. Enabling compression may further deteriorate the forwarding performance. Therefore, the new compression strategy is determined to be non-compression mode.

[0046] If the number of SIDs is greater than 3, the end-to-end latency is less than or equal to 95% of the SLA, and the path packet loss rate is less than or equal to 0.1%, it indicates that the latency is within acceptable limits and the network condition allows it. Enabling compression can improve bandwidth utilization. Since the number of SIDs is relatively large, enabling compression can effectively save bandwidth, and the latency and packet loss rate are within acceptable ranges. Therefore, it is determined to enable G-SRv6 compression. At this point, it is necessary to further decide on the specific compression algorithm. That is, after deciding to enable compression, the compression algorithm of G-SRv6 compression is selected according to the link bandwidth utilization, resulting in a new compression strategy that includes enabling G-SRv6 compression and the compression algorithm.

[0047] Optionally, the G-SRv6 compression algorithm can include a 32-bit compression algorithm and a 16-bit compression algorithm. The 32-bit compression algorithm has a compression efficiency of approximately 75% (saving 96 bits / message) and low processing overhead (device processing time of approximately 5μs), making it suitable for scenarios with limited bandwidth (utilization > 90%). The 16-bit compression algorithm has a compression efficiency of approximately 87.5% (saving 112 bits / message) and high processing overhead (device processing time of approximately 15μs), making it suitable for scenarios with bandwidth utilization ≤ 90%, as network resources are relatively abundant at this point, and higher processing overhead can be acceptable to achieve greater compression benefits.

[0048] Therefore, based on a trade-off analysis of device processing performance and compression benefits, if the link bandwidth utilization rate is greater than a set value (e.g., 90%), a 32-bit compression algorithm is selected. In this high-bandwidth scenario, 32-bit compression achieves the best balance between compression efficiency and processing performance. If the link bandwidth utilization rate is less than or equal to the set value (e.g., 90%), a 16-bit compression algorithm is selected. In this case, the bandwidth utilization rate is lower, and 16-bit compression maximizes bandwidth resource savings.

[0049] In step S103, after determining the new compression strategy as described above, the SDN controller further compares the consistency between the new compression strategy and the currently executed compression strategy. If they are the same, it means that the existing forwarding path and compression method can still meet the service quality requirements, and no configuration change is required. The source node maintains the current compression strategy and its corresponding forwarding path unchanged, thereby avoiding control plane oscillations and state synchronization overhead caused by frequent reconfiguration.

[0050] If the new compression policy differs from the current compression policy, it indicates that the current forwarding path or compression method is no longer suitable for the current network status or changes in service requirements, and adjustments are necessary. If the current compression policy is in uncompressed mode and the new compression policy is in compressed mode, the controller updates the SID in the segment list of the original forwarding path to an SID with compression capabilities (including compression algorithm, compression prefix length, etc.). Subsequently, the SDN controller distributes the new forwarding path to the source node via BGP-SR-Policy, triggering an update operation on the service flow forwarding configuration. Upon receiving the new policy, the source node seamlessly switches forwarding policies and performs compression operations based on the segment list information of the new forwarding path, ensuring that subsequent data packets matching the characteristics of this service flow are transmitted according to the new forwarding path.

[0051] It should be noted that when the SDN controller compares the consistency between the new compression strategy and the current compression strategy, it means comparing whether the new compression strategy and the current compression strategy are completely identical. As described above, there are two compression strategies: one is a non-compression mode, in which G-SRv6 compression is not activated; the other is a compression mode, which includes activating G-SRv6 compression plus a compression algorithm (such as 32-bit compression or 16-bit compression). Therefore, if both the current compression strategy and the new compression strategy are in compression mode, it is necessary to compare whether their compression algorithms are the same. If they are different, it is determined that the current compression strategy and the new compression strategy are different.

[0052] In this embodiment, a periodic dynamic decision-making mechanism is introduced into the SDN controller. At the arrival of each preset decision period, the SDN controller combines real-time network status, the number of SIDs in the segment list of the current forwarding path, and service requirements to make a comprehensive decision on whether to compress and the specific compression algorithm. This enables dynamic decision-making and on-demand updates of forwarding paths and compression strategies. This not only ensures the stability of service quality for service flows but also improves the utilization efficiency of network resources.

[0053] To enhance the flexibility and observability of network control, when a new service requirement is added, the SDN controller establishes an initial forwarding path using a standard SID (uncompressed) and distributes it to the source node. After the initial forwarding path is distributed, the SDN controller immediately starts the flow detection function on each network node in the forwarding path to perform real-time performance monitoring of the service flow.

[0054] Therefore, in Figure 2 Based on this, please refer to Figure 3 Before step S101, the message processing method for SDN controllers provided in this application embodiment further includes steps S10A to S10C.

[0055] S10A generates a segment list for the initial forwarding path based on the currently acquired network topology information, link status, SID capability information of each node, and service requirements of the service flow, and configures the compression strategy of the segment list for the initial forwarding path to be uncompressed. S10B sends the initial forwarding path to the source node so that when the source node receives the service flow, it encapsulates the message in uncompressed mode and forwards it along the initial forwarding path. S10C sends configuration instructions to the source node. The configuration instructions are used to instruct the source node to embed probe information during the encapsulation of service flow to start flow detection, and to receive performance data returned by each measurement node on the current forwarding path, generate real-time probe results of service flow and send them to the SDN controller.

[0056] In this embodiment, when a new service requirement is added, the SDN controller collects network topology information, link status, and SID capability information of each node through the BGP-LS protocol. Combined with the service requirement, it generates a segment list for the initial forwarding path. The network topology information reflects the connectivity and reachability between nodes in the network. Link status includes, but is not limited to, dynamic indicators such as link bandwidth utilization, latency, and packet loss rate, used to assess the actual carrying capacity of each physical or logical link. The SID capability information of each node is used to confirm whether the corresponding node supports source routing forwarding and the number and type of SIDs that can be allocated. Service requirements may include link bandwidth requirements, maximum hop count limits, latency requirements, etc. For example, "low-latency transaction service" requires a maximum allowable latency of ≤20ms.

[0057] Meanwhile, the initial forwarding path is configured with an uncompressed forwarding strategy. Uncompressed mode means that during the packet encapsulation stage, the SID of each intermediate node in the path is explicitly encoded into the segment list in the packet header, allowing each forwarding node to directly parse the next-hop information without relying on additional mapping or lookup mechanisms. Although uncompressed mode increases packet header overhead to some extent, it has good compatibility and traceability, making it particularly suitable for the initial deployment phase of probing functions. It ensures that measurement nodes accurately identify and process data packets belonging to this service flow.

[0058] Based on this, the SDN controller distributes the initial forwarding path to the source node, thereby completing the pre-configuration of forwarding rules. When the source node receives a service flow, it performs packet encapsulation operations according to the distributed forwarding configuration. During this process, the source node writes each SID into the packet header sequentially according to the node sequence specified in the segment list of the initial forwarding path, and encapsulates the packet using an uncompressed method. Then, it forwards the encapsulated packet hop-by-hop along the predetermined path.

[0059] Simultaneously, the SDN controller issues configuration commands to each network node in the initial forwarding path to activate the flow-following detection mechanism. The configuration commands instruct the source node to embed specific probe information during the encapsulation of service flows. This probe information may include detection period definitions, measurement field templates, sampling ratio parameters, or trigger conditions, guiding each measurement node (i.e., each network node in the initial forwarding path) on how to perform performance data collection. During this process, upon receiving a packet carrying probe information, each measurement node on the current forwarding path performs real-time measurements on the traffic passing through it, collecting performance data such as timestamps, queue depths, forwarding delays, and coloring tags, and then transmits this data back to the source node. Based on this performance data from multiple measurement nodes, the source node performs aggregated analysis, generates real-time probe results for the service flow, and sends them to the SDN controller.

[0060] The following describes the message processing method provided in the embodiments of this application, taking "low-latency transaction business scenario" and "video on demand business scenario" as examples.

[0061] For "low-latency transaction business scenarios", the following processes may be included: When a new "low-latency transaction service" is added, the SDN controller collects the entire network topology, link status, and SID and capability information of each node through BGP-LS. Combined with the requirements of the "low-latency transaction service" (e.g., maximum allowable latency of 20ms), it generates an initial forwarding path using a standard SID (uncompressed) and sends it to the source node for execution through the BGP-SR-Policy protocol.

[0062] After the initial forwarding path is established, the SDN controller immediately starts the flow detection function to monitor the performance of the "low-latency transaction service" in real time. It obtains the real-time detection results of the current forwarding path according to the set sampling period (e.g., 1 second), such as end-to-end latency of 18ms, jitter of 5ms, path packet loss rate of 0%, and link bandwidth utilization of 70%.

[0063] Then, the SDN controller inputs the real-time detection results from the flow detection, the number of SIDs in the segment list of the initial forwarding path (e.g., 4), and the service's SLA requirements (e.g., maximum allowable latency of 20ms) into the intelligent policy engine. Since the current latency is 18ms, which is close to the SLA limit, the SDN controller decides to maintain the uncompressed mode, because enabling compression may introduce processing jitter, causing the SLA to fail to meet the requirements.

[0064] Next, the SDN controller uses the BGP-SR-Policy update mechanism to send the uncompressed policy to the source node. The source node does not need to switch the forwarding policy, and the service flow continues to be transmitted according to the initial uncompressed forwarding path.

[0065] In this way, the SDN controller completes the compression strategy decision for one decision cycle. After that, the SDN controller continues to obtain the real-time detection results of the current forwarding path according to the set sampling period (e.g., 1 second), and executes the compression strategy decision again when the next decision cycle arrives. This process is repeated, so that the compression strategy can be dynamically adjusted according to the real-time network status and service requirements.

[0066] For the "video-on-demand service scenario", the following process can be included: When a new "video on demand service" is added, the SDN controller collects the entire network topology, link status, and SID and capability information of each node through BGP-LS. Combined with the requirements of the "video on demand service" (e.g., high bandwidth, maximum allowable latency of 100ms), it generates an initial forwarding path using a standard SID (uncompressed) and sends it to the source node for execution through the BGP-SR-Policy protocol.

[0067] After the initial forwarding path is established, the SDN controller immediately starts the flow detection function to monitor the performance of the "low-latency transaction service" in real time. It obtains the real-time detection results of the current forwarding path according to the set sampling period (e.g., 1 second). For example, the end-to-end latency is 80ms, the jitter is 10ms, the path packet loss rate is 0.5%, and the link bandwidth utilization rate is 92%.

[0068] Then, the SDN controller inputs the real-time detection results from the flow detection, the number of SIDs in the segment list of the initial forwarding path (e.g., 5), and the service's SLA requirements (e.g., high bandwidth, maximum allowable latency of 100ms) into the intelligent policy engine. Since the current link bandwidth utilization is higher than 90%, but the latency has not exceeded the limit, the SDN controller decides that the source node should use the G-SRv6 compression algorithm to compress the SIDs in the segment list of the initial forwarding path. After deciding to enable compression mode, the SDN controller further selects a compression algorithm. Because the link bandwidth utilization is >90%, a 32-bit compression algorithm is selected to achieve the best balance between compression efficiency and device processing performance.

[0069] Next, the SDN controller updates the segment list of the current forwarding path according to the new compression policy to generate a new forwarding path. Through the BGP-SR-Policy update mechanism, the new forwarding path is sent to the source node. The source node seamlessly switches the forwarding policy, and the service flow is transmitted according to the new forwarding path corresponding to the optimized segment list.

[0070] In this way, the SDN controller completes the compression strategy decision for one decision cycle. After that, the SDN controller continues to obtain the real-time detection results of the current forwarding path according to the set sampling period (e.g., 1 second), and executes the compression strategy decision again when the next decision cycle arrives, so as to dynamically adjust the compression strategy according to the real-time network status and service requirements.

[0071] Please refer to Figure 4 , Figure 4 A schematic flowchart of a message processing method provided in an embodiment of this application is shown. This message processing method is applied to... Figure 1 The source node in the data may include the following steps: S201, based on the performance data obtained from the flow detection of service flows, generates real-time detection results of service flows and sends them to the software-defined network (SDN) controller. S202, Receive the new forwarding path generated by the segment list of the current forwarding path updated according to the new compression policy issued by the SDN controller. The new compression policy is generated by the SDN controller at the time of each preset decision period based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. S203, encapsulate the service flow according to the segment list of the new forwarding path, and forward it along the new forwarding path.

[0072] In this embodiment, if the source node receives a new forwarding path generated by updating the segment list of the current forwarding path according to the new compression policy issued by the SDN controller, the source node encapsulates the service flow according to the segment list of the new forwarding path and forwards it along the new forwarding path. This switching process involves replacing the original encapsulation parameters and loading the new path information, requiring the source node to have multi-policy configuration management capabilities and a fast switching mechanism to ensure that the service flow is not interrupted or out of order during the policy change process.

[0073] If the source node does not receive a new forwarding path from the SDN controller, the source node continues to use the current forwarding path to encapsulate the service flow and forward it along the current forwarding path. This situation usually occurs when the current forwarding path still meets the service requirements and there is no significant performance degradation, thus avoiding system jitter and processing overhead caused by frequent switching.

[0074] In one possible implementation, a reliable and reasonable default configuration is provided for the initial transmission of service flows by introducing an initial forwarding path and compression strategy uniformly planned by the SDN controller. Therefore, in Figure 4 Based on this, please refer to Figure 5 Before step S101, the message processing method applied to the source node provided in this application embodiment further includes steps S20A to S20B.

[0075] S20A: Receive the initial forwarding path issued by the SDN controller. The initial forwarding path is a segment list generated by the SDN controller based on the currently acquired network topology information, link status, SID capability information of each node, and service requirements of the service flow. The compression strategy of the segment list of the initial forwarding path is uncompressed mode. When S20B receives a service flow, it encapsulates the message in uncompressed mode and forwards it along the initial forwarding path.

[0076] In this embodiment, the network topology information reflects the connection relationship between each node in the network, the link status includes dynamic indicators such as bandwidth utilization, latency, and packet loss rate, while the SID capability information characterizes the degree of support of each node for the G-SRv6 encoding format, such as whether it supports compressed SIDs of a specific length or specific types of processing instructions.

[0077] Based on this, the SDN controller, combining the aforementioned multi-dimensional inputs, calculates an initial forwarding path that meets the service requirements of the service flow. It's important to note that the compression strategy for the segment list of the initial forwarding path is explicitly set to uncompressed mode; that is, it does not use the G-SRv6 compression algorithm for encapsulation, but rather uses the standard SRv6 format or a format with a complete SID compatible with conventional processing logic. This design helps mitigate forwarding risks arising from uncertain compression format compatibility in the initial stage, especially when there are intermediate nodes in the path with unknown capabilities or that only support standard SRv6, ensuring the reachability and stability of the service flow.

[0078] When the source node receives the actual arriving service flow, it immediately encapsulates the service flow in uncompressed mode and performs forwarding operations along the initial forwarding path. Optionally, the encapsulation process involves writing the SIDs of each hop in the initial forwarding path into the packet header in uncompressed form, forming a standard SRv6 packet structure that can be correctly parsed by each node in the forwarding path. This packet then enters the data plane hop-by-hop transmission process, ensuring that the service flow can still complete end-to-end transmission in a deterministic and secure manner before actual performance feedback is obtained.

[0079] Meanwhile, to achieve subsequent dynamic optimization, continuous monitoring of the service flow's operational status needs to be initiated. Optionally, the process in step S201 of generating real-time detection results of the service flow based on the performance data obtained from the flow-following detection and sending them to the SDN controller may include: S2011, in response to the flow detection start command issued by the SDN controller, embeds probe information during the encapsulation of service flow to start flow detection of service flow; S2012 receives performance data returned by each measurement node on the current forwarding path, generates real-time detection results of the service flow, and sends the real-time detection results to the SDN controller.

[0080] In this embodiment, probe information refers to special fields or markers used to trigger and identify detection behavior. These are placed in the packet header or the reserved area of ​​the payload, enabling each measurement node on the current forwarding path to identify and perform corresponding performance sampling actions upon receiving the packet. This process does not require sending additional dedicated probe packets; instead, it utilizes the actual service traffic itself to carry the detection intent, improving detection efficiency and the authenticity of the status information.

[0081] In this process, flow-based detection relies on network nodes along the path that have measurement capabilities. Upon receiving a packet carrying probe information, these measurement nodes collect performance data related to the service flow, such as per-hop forwarding latency, queue depth, timestamp information, or coloring markers, and then transmit the collected data back to a designated collection node (such as the source node) or directly report it to the SDN controller. The source node, as the initiator of the detection, is responsible for receiving performance data returned from each measurement node along the current forwarding path. This returned data, after being aggregated and processed, constitutes a quantitative description of the overall transmission quality of the service flow, i.e., the real-time network status.

[0082] Based on the performance data returned by each measurement node, the source node generates real-time detection results of the service flow and sends them to the SDN controller, which serves as an important basis for the SDN controller to determine whether to adjust the forwarding path or compression strategy.

[0083] Compared with the prior art, the message processing method provided in this application has the following advantages: First, the SDN controller makes dynamic and integrated intelligent decisions on the G-SRv6 compression strategy based on multi-dimensional input information, including the number of SIDs in the segment list of the current forwarding path of the service flow, real-time network status, and service requirements. This breaks through the traditional technical mode of static configuration or single-condition judgment and realizes dynamic matching between network resources and service requirements. Secondly, by deeply integrating the centralized control capabilities of SDN with G-SRv6 compression technology, an adaptive mechanism linking perception, decision-making, and execution was constructed, effectively solving the problem that static configuration is difficult to respond to dynamic changes, and achieving significant results in optimizing network efficiency and ensuring service experience. Third, it has good practicality and can be implemented on existing network devices and SDN controllers that support G-SRv6 through software upgrades without changing the hardware architecture. It can be directly applied to scenarios such as 5G bearer networks, data centers and computing power networks, with low deployment costs and clear industrialization prospects. Fourth, on paths with a small number of SIDs (e.g., ≤3 SIDs), this solution avoids performance degradation (latency increase of 5-10ms) caused by enabling compression. In scenarios with tight link bandwidth (e.g., utilization >90%), by dynamically selecting compression algorithms, it improves network resource utilization by about 15-20%, thereby providing refined protection for differentiated services and meeting the SLA requirements of different services.

[0084] In order to perform the corresponding steps in the above method embodiments and various possible implementations, the following provides an implementation of a packet processing device 100 applied to an SDN controller and a packet processing device 200 applied to a source node.

[0085] Please refer to Figure 6 , Figure 6 A block diagram of a message processing apparatus 100 provided in an embodiment of this application is shown. The message processing apparatus 100 is applied to an SDN controller and includes: a probe result receiving module 102 and a periodic decision module 103.

[0086] The detection result receiving module 102 is used to receive the real-time detection results of the service flow sent by the source node. The real-time detection results are generated based on the performance data obtained by performing flow-following detection on the service flow.

[0087] The periodic decision module 103 is used to generate a new compression strategy based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow when each preset decision period arrives. If the new compression strategy is different from the current compression strategy, the segment list of the current forwarding path is updated according to the new compression strategy to generate a new forwarding path, and the new forwarding path is sent to the source node to update the forwarding configuration of the service flow.

[0088] Optionally, the real-time detection results include average latency, path packet loss rate, and link bandwidth utilization. The periodic decision module 103 executes a method to generate a new compression strategy based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. This includes: if the number of SIDs is less than or equal to a set number and the end-to-end latency is less than or equal to a set latency, then the new compression strategy is determined to be uncompressed mode; if the end-to-end latency is greater than a set latency and the path packet loss rate is greater than a set packet loss rate, then the new compression strategy is determined to be uncompressed mode; if the number of SIDs is greater than a set number and the end-to-end latency is less than or equal to a set latency and the path packet loss rate is less than or equal to a set packet loss rate, then the generic IPv6 segment routing G-SRv6 compression is enabled, and the compression algorithm of G-SRv6 compression is selected according to the link bandwidth utilization to obtain a new compression strategy.

[0089] Optionally, the G-SRv6 compression algorithm includes a 32-bit compression algorithm and a 16-bit compression algorithm; the periodic decision module 103 executes the method of selecting the G-SRv6 compression algorithm according to the link bandwidth utilization, including: if the link bandwidth utilization is greater than a set value, then the 32-bit compression algorithm is selected; if the link bandwidth utilization is less than or equal to the set value, then the 16-bit compression algorithm is selected.

[0090] Optionally, the message processing apparatus 100 provided in this application embodiment further includes an initial configuration module 101.

[0091] The initial configuration module 101 is used to generate a segment list of the initial forwarding path based on the currently acquired network topology information, link status, SID capability information of each node, and service requirements of the service flow, and configure the compression strategy of the segment list of the initial forwarding path to be uncompressed mode; it sends the initial forwarding path to the source node so that when the source node receives the service flow, it encapsulates the packets in uncompressed mode and forwards them along the initial forwarding path; it sends a configuration instruction to the source node, which is used to instruct the source node to embed probe information during the process of encapsulating the service flow to start flow detection, and receives the performance data returned by each measurement node on the current forwarding path, generates real-time probe results of the service flow and sends them to the SDN controller.

[0092] Please refer to Figure 7 , Figure 7 A block diagram of a message processing apparatus 200 provided in an embodiment of this application is shown. The message processing apparatus 200 is applied to a source node and includes: a probe result sending module 202, a decision result receiving module 203, and a decision result execution module 204.

[0093] The detection result sending module 202 is used to generate real-time detection results of the service flow based on the performance data obtained by performing flow-following detection on the service flow and send them to the software-defined network (SDN) controller.

[0094] The decision result receiving module 203 is used to receive the new forwarding path generated by the SDN controller based on the segment list of the current forwarding path updated according to the new compression policy. The new compression policy is generated by the SDN controller at the time of each preset decision period based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow.

[0095] The decision result execution module 204 is used to encapsulate the service flow according to the segment list of the new forwarding path and forward it along the new forwarding path.

[0096] Optionally, the message processing apparatus 200 provided in this application embodiment further includes a configuration execution module 201.

[0097] The configuration execution module 201 is used to receive the initial forwarding path issued by the SDN controller. The initial forwarding path is a segment list generated by the SDN controller based on the currently acquired network topology information, link status, SID capability information of each node, and service requirements of the service flow. The compression strategy of the segment list of the initial forwarding path is uncompressed mode. When a service flow is received, the packet is encapsulated in uncompressed mode and forwarded along the initial forwarding path.

[0098] Optionally, the detection result sending module 202 executes a method of generating real-time detection results of the service flow based on the performance data obtained from the flow-following detection of the service flow and sending them to the SDN controller, including: responding to the flow-following detection start command issued by the SDN controller, embedding detection information during the process of encapsulating the service flow to start the flow-following detection of the service flow; receiving the performance data returned by each measurement node on the current forwarding path, generating real-time detection results of the service flow, and sending the real-time detection results to the SDN controller.

[0099] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the message processing device 100 and message processing device 200 described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0100] Please refer to Figure 8 , Figure 8 A block diagram of an electronic device 10 provided in an embodiment of this application is shown. The electronic device 10 may be... Figure 1 The SDN controller or source node is located within the device. Electronic device 10 includes a processor 11, a memory 12, and a communication module 13. These components are electrically connected directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected via one or more communication buses or signal lines. The processor 11 is responsible for control and management, the memory 12 is responsible for storing instructions and data, and the communication module 13 is responsible for sending and receiving network packets.

[0101] The memory 12 is used to store programs. After receiving an execution instruction, the processor 11 executes the programs to implement the packet processing method for an SDN controller disclosed in the above embodiments, or the packet processing method for a source node.

[0102] The memory 12 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0103] Processor 11 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed through integrated logic circuits in the hardware of processor 11 or through software instructions. Processor 11 can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Complex Programmable Logic Device (CPLD), a Field Programmable Gate Array (FPGA), embedded ARM chips, etc.

[0104] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by the processor 11, it implements the packet processing method for an SDN controller disclosed in the above embodiments, or the packet processing method for a source node.

[0105] In summary, the packet processing method, apparatus, electronic device, and storage medium provided in this application introduce a periodic dynamic decision-making mechanism in the SDN controller. At the arrival of each preset decision cycle, the SDN controller comprehensively judges and generates a new compression strategy based on the real-time detection results of the service flow reported by the source node, the number of SIDs in the segment list of the current forwarding path, and the service requirements of the service flow. When the new compression strategy is consistent with the current compression strategy, the existing configuration remains unchanged. When the two are inconsistent, the segment list of the current forwarding path is updated according to the new forwarding strategy to generate a new forwarding path, and the new compression strategy is then applied to the SDN controller. The forwarding path is sent to the source node for execution, which enables dynamic adjustment of the compression strategy based on real-time network conditions (such as congestion and latency) and business requirements (such as low latency and high bandwidth). This effectively avoids the problem of increased processing latency and decreased service quality caused by blind compression in scenarios with a small number of SIDs or when the network is close to its performance limit (such as high latency and high packet loss). At the same time, the appropriate compression method is activated in a timely manner on paths with tight bandwidth but sufficient latency margin, which significantly improves the utilization rate of network resources. This achieves dynamic matching between network resources and business requirements, optimizing overall network efficiency while ensuring business experience.

[0106] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A message processing method, characterized in that, The packet processing method, applied to a software-defined networking (SDN) controller, includes: Receive real-time detection results of the service flow sent by the source node, wherein the real-time detection results are generated based on performance data obtained by performing flow-following detection on the service flow; At the arrival of each preset decision cycle, a new compression strategy is generated based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. If the new compression strategy is different from the current compression strategy, the segment list of the current forwarding path is updated according to the new compression strategy to generate a new forwarding path, and the new forwarding path is sent to the source node to update the forwarding configuration of the service flow.

2. The message processing method as described in claim 1, characterized in that, The real-time detection results include end-to-end latency, path packet loss rate, and link bandwidth utilization. The step of generating a new compression strategy based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow includes: If the number of SIDs is less than or equal to a set number and the end-to-end delay is less than or equal to a set delay, then the new compression strategy is determined to be in non-compression mode. If the end-to-end delay is greater than the set delay and the path packet loss rate is greater than the set packet loss rate, then the new compression strategy is determined to be in non-compression mode. If the number of SIDs is greater than the set number, the end-to-end delay is less than or equal to the set delay, and the path packet loss rate is less than or equal to the set packet loss rate, then it is determined that the general IPv6 segment routing G-SRv6 compression is enabled, and the compression algorithm of the G-SRv6 compression is selected according to the link bandwidth utilization to obtain the new compression strategy.

3. The message processing method as described in claim 2, characterized in that, The G-SRv6 compression algorithm includes a 32-bit compression algorithm and a 16-bit compression algorithm; The step of selecting the G-SRv6 compression algorithm based on the link bandwidth utilization includes: If the link bandwidth utilization is greater than the set value, then the 32-bit compression algorithm is selected; If the link bandwidth utilization is less than or equal to the set value, then the 16-bit compression algorithm is selected.

4. The message processing method as described in claim 1, characterized in that, Prior to the step of receiving the real-time detection results of the service flow sent by the source node, the message processing method further includes: Based on the currently acquired network topology information, link status, SID capability information of each node, and service requirements of the service flow, a segment list of the initial forwarding path is generated, and the compression strategy of the segment list of the initial forwarding path is configured to be uncompressed. The initial forwarding path is sent to the source node so that when the source node receives the service flow, it encapsulates the message in the uncompressed mode and forwards it along the initial forwarding path. A configuration instruction is issued to the source node, which instructs the source node to embed probe information during the encapsulation of the service flow to start flow detection, and to receive performance data returned by each measurement node on the current forwarding path, generate real-time probe results of the service flow and send them to the SDN controller.

5. A message processing method, characterized in that, Applied to the source node, the message processing method includes: Based on the performance data obtained by performing flow detection on the service flow, the real-time detection results of the service flow are generated and sent to the software-defined network (SDN) controller. The system receives a new forwarding path generated by updating the segment list of the current forwarding path according to the new compression strategy issued by the SDN controller. The new compression strategy is generated by the SDN controller at the time of each preset decision period based on real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. The service flow is encapsulated according to the segment list of the new forwarding path and forwarded along the new forwarding path.

6. The message processing method as described in claim 5, characterized in that, Before the step of generating real-time detection results of the service flow based on the performance data obtained from flow-based detection of the service flow and sending them to the SDN controller, the packet processing method further includes: The initial forwarding path is received from the SDN controller. The initial forwarding path is a segment list generated by the SDN controller based on the currently acquired network topology information, link status, SID capability information of each node, and service requirements of the service flow. The compression strategy of the segment list of the initial forwarding path is uncompressed mode. Upon receiving the service flow, the message is encapsulated in the uncompressed mode and forwarded along the initial forwarding path.

7. The message processing method as described in claim 5, characterized in that, The step of generating real-time detection results of the service flow based on the performance data obtained by performing flow-based detection on the service flow and sending them to the SDN controller includes: In response to the flow detection start command issued by the SDN controller, probe information is embedded during the encapsulation of the service flow to start flow detection of the service flow; The system receives performance data returned by each measurement node on the current forwarding path, generates real-time detection results for the service flow, and sends the real-time detection results to the SDN controller.

8. A message processing apparatus, characterized in that, The packet processing device, applied to a software-defined networking (SDN) controller, includes: The detection result receiving module is used to receive the real-time detection results of the service flow sent by the source node, wherein the real-time detection results are generated based on the performance data obtained by performing flow-following detection on the service flow; The periodic decision module is used to generate a new compression strategy based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow when each preset decision period arrives. If the new compression strategy is different from the current compression strategy, the segment list of the current forwarding path is updated according to the new compression strategy to generate a new forwarding path, and the new forwarding path is sent to the source node to update the forwarding configuration of the service flow.

9. A message processing apparatus, characterized in that, Applied to the source node, the message processing device includes: The detection result sending module is used to generate real-time detection results of the service flow based on the performance data obtained by performing flow-following detection on the service flow and send them to the software-defined network (SDN) controller. The decision result receiving module is used to receive the new forwarding path generated by the SDN controller based on the segment list of the current forwarding path updated according to the new compression strategy. The new compression strategy is generated by the SDN controller at the time of each preset decision period based on the real-time detection results, the number of segment identifiers (SIDs) in the segment list of the current forwarding path of the service flow, and the service requirements of the service flow. The decision result execution module is also used to encapsulate the service flow according to the segment list of the new forwarding path and forward it along the new forwarding path.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory being used to store a program, and the processor being used to implement the message processing method as described in any one of claims 1-4, or the message processing method as described in any one of claims 5-7, when executing the program.

11. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the message processing method as described in any one of claims 1-4, or the message processing method as described in any one of claims 5-7.

Images