A message processing method and device
By setting packet filtering rules and DOH encapsulation on the detection interface of the head node, the problem of inconsistent packet statistics in flow detection is solved, the detection accuracy is improved and the workload of network troubleshooting is reduced.
Patent Information
- Application Number
- CN202411282995.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-13
- Publication Date
- 2025-10-10
- Estimated Expiration
- 2044-09-13
AI Technical Summary
In existing in-flow detection technologies, the coarse-grained traffic detection method leads to inconsistent packet statistics at the ingress and egress, resulting in packet loss and affecting network troubleshooting.
The first table entry is set on the detection interface of the head node to match the packet filtering rules, filter the packets that do not need to be detected by IFIT, and encapsulate the destination option extension header (DOH) for the packets that need to be detected to facilitate subsequent IFIT detection.
This achieves filtering out packets that affect the results of flow detection, reduces the workload of network troubleshooting, and improves the accuracy of detection results.
Smart Images

Figure CN119172747B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of communication technology, and in particular to a message processing method and device. Background Art
[0002] In-situ Flow Information Telemetry (IFIT) is an Operations, Administration, and Maintenance (OAM) monitoring technology used to monitor link quality. It analyzes the traffic flow at each node in the network to determine the transmission quality of service links. For example, IFIT directly measures packet count and time at the ingress and egress points of the network, measuring performance indicators such as the actual packet loss rate and latency, enabling real-time monitoring and diagnosis of service traffic.
[0003] The currently available IFIT technology can perform detection based on different feature detection granularities, such as quintuple-based detection granularity and MAC-based detection granularity. However, these detection methods are coarse-grained traffic detection methods, which can lead to inconsistent packet statistics at the ingress and egress on certain normal links, resulting in output packet loss. For example, when ICMP packets of the tracert protocol (non-business traffic) are transmitted between nodes in the network, some tracert packets are only transmitted within the network because the tracert protocol uses a time-to-live (TTL). Therefore, when a tracert packet enters IFIT flow detection, the number of packets counted by the analyzer at the egress will be lower than the number of packets at the ingress. As a result, the analyzer will output packet loss.
[0004] Therefore, one of the technical issues worth considering is how to filter out packets using protocols such as tracert that affect the results of in-flight detection and reduce network troubleshooting efforts. Summary of the Invention
[0005] In view of this, the present application provides a message processing method and apparatus for filtering out messages that affect the results of flow detection, thereby reducing network troubleshooting work.
[0006] Specifically, this application is implemented through the following technical solutions:
[0007] According to a first aspect of the present application, a message processing method is provided, which is applied to a head node in a target network, the method comprising:
[0008] When the detection interface bound to the IFIT instance in the head node obtains the first message, obtain a first table item configured on the detection interface, where the first table item includes a message filtering rule;
[0009] Matching the first message with the first table entry;
[0010] When the first entry is matched successfully, the first message is forwarded externally according to the execution action corresponding to the message filtering rule, where the execution action is an action of filtering the IFIT instance;
[0011] When the match with the first table item fails, the first message is matched with the second table item, where the second table item is an item bound to the IFIT instance, and the second table item includes a message rule that requires IFIT detection;
[0012] When a match is found with the second table entry, the first message is encapsulated with a destination option extension header DOH to obtain a second message, where the second message is used for IFIT detection;
[0013] When the match with the second entry fails, the first message is forwarded externally.
[0014] According to a second aspect of the present application, a message processing device is provided, which is applied to a head node in a target network, and the device includes:
[0015] a first acquiring unit, configured to acquire, when a detection interface bound to an IFIT instance in the head node acquires a first message, a first table entry configured on the detection interface, the first table entry including a message filtering rule;
[0016] a first matching unit, configured to match the first message with the first entry;
[0017] a forwarding unit configured to forward the first message externally according to an execution action corresponding to the message filtering rule when the matching result of the first matching unit is a successful match with the first table entry, wherein the execution action is an action of filtering the IFIT instance;
[0018] a second matching unit, configured to match the first message with a second entry when the matching result of the first matching unit is a match failure with the first entry, where the second entry is an entry bound to the IFIT instance, and the second entry includes a message rule requiring IFIT detection;
[0019] an encapsulation unit, configured to encapsulate the first message with a destination option extension header DOH to obtain a second message when the matching result of the second matching unit is a successful match with the second table entry, wherein the second message is used for IFIT detection;
[0020] The forwarding unit is further configured to forward the first message externally when the matching result of the second matching unit is that the match with the second entry fails.
[0021] According to the third aspect of the present application, an electronic device is provided, comprising a processor and a machine-readable storage medium, wherein the machine-readable storage medium stores a computer program that can be executed by the processor, and the processor is prompted by the computer program to execute the method provided in the first aspect of the embodiment of the present application.
[0022] According to the fourth aspect of the present application, a machine-readable storage medium is provided, which stores a computer program. When called and executed by a processor, the computer program prompts the processor to execute the method provided in the first aspect of the embodiment of the present application.
[0023] Beneficial effects of the embodiments of the present application:
[0024] In the message processing method and device provided by the embodiment of the present application, when the detection interface bound to the IFIT instance in the head node obtains the first message, the first table item configured on the detection interface is obtained, and the first table item includes the message filtering rule; the first message is matched with the first table item; when the match with the first table item is successful, the first message is forwarded externally according to the execution action corresponding to the message filtering rule, and the execution action is the action of filtering the IFIT instance; when the match with the first table item fails, the first message is matched with the second table item, and the second table item is the table item bound to the IFIT instance, and the second table item includes the message rule that needs to be IFIT detected; when the match with the second table item is successful, the first message is encapsulated with the destination option extension header DOH to obtain a second message, and the second message is used for IFIT detection; when the match with the second table item fails, the first message is forwarded externally.
[0025] By adopting the above-mentioned method, the present application obtains the first table item configured in the detection interface for filtering the messages that do not need IFIT detection. When the detection interface obtains the first message, the first message can be matched with the first table item, and the first message that hits the first table item can be directly forwarded, thereby achieving the purpose of filtering the messages that do not need IFIT detection; in addition, when the first table item is not hit, the second table item corresponding to the IFIT instance bound to the detection interface can be obtained, and DOH encapsulation processing can be performed on the first message that hits the second table item, so that when the IFTI detection is performed subsequently, only the second message encapsulated with DOH is detected. In this way, not only the purpose of filtering out the messages that affect the flow detection results is achieved, but also the workload of troubleshooting when a network failure occurs due to the failure of the flow detection result is reduced. That is, the problem of inaccurate statistical results caused by the analyzer counting all messages when performing IFIT detection is solved. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] Figure 1 This is a flow chart of a message processing method provided in an embodiment of the present application;
[0027] Figure 2 This is a schematic diagram of an application scenario of a message processing method provided in an embodiment of the present application;
[0028] Figure 3 This is a structural diagram of a message processing device provided in an embodiment of the present application;
[0029] Figure 4 This is a hardware structure diagram of an electronic device that implements a message processing method provided in an embodiment of the present application. DETAILED DESCRIPTION
[0030] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of the present application.
[0031] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms "a," "the," and "the" used in this application are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.
[0032] It should be understood that although the terms first, second, third, etc. may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".
[0033] The message processing method provided in this application is described in detail below.
[0034] See also Figure 1 , Figure 1 This is a flowchart of a message processing method provided by this application. This method can be applied to a head node in a target network. The target network can be any network requiring IFIT detection. The head node can be the first device in the target network, for example, the first device on which service traffic enters the target network. When implementing this method, the target node can include the following steps:
[0035] Step 101: When a detection interface bound to an IFIT instance in a head node obtains a first message, a first table entry configured on the detection interface is obtained, where the first table entry includes a message filtering rule.
[0036] In this step, the above-mentioned IFIT instance is an instance used for IFIT detection. One or more IFIT instances can be configured on each detection interface. When the detection interface is bound to multiple IFIT instances, each IFIT instance can correspond to a different IFIT detection method, so that the message that meets the message rules of the IFIT instance can be IFIT detected according to the detection method corresponding to the IFIT instance.
[0037] In order to solve the problem of inaccurate detection results caused by performing IFIT detection on all messages flowing through the head node, this embodiment proposes that the above-mentioned first table item is set on the detection interface, and the first table item is used to filter some messages that do not need to be tested by IFIT. Specifically, the first table item includes a message filtering rule, and based on the message filtering rule, the message that meets the message filtering rule is identified. The message is a message that does not need to be tested by IFIT. Based on this, when the detection interface of the head node receives the first message, the first table item can be obtained.
[0038] It should be noted that the detection interface is any interface in the head node that requires IFIT detection, and this embodiment does not specifically limit this. In addition, the first message can be a message entering the head node of the target network, a message generated by the head node that needs to be sent externally through the target network, or a message generated by the head node that needs to be transmitted within the target network.
[0039] Step 102: Match the first message with the first entry.
[0040] In this step, after obtaining the first table entry, the head node can match the first message with the message filtering rule in the first table entry. When the match is successful, it indicates that the message features included in the first message hit the message features included in the message filtering rule, and thus it can be confirmed that the first message does not need to participate in IFIT detection. Based on this, the first message can be forwarded, that is, step 103 is executed. When the match fails, it indicates that the message features included in the first message do not match the message features included in the message filtering rule, and thus it indicates that the first message does not need to be filtered, that is, IFIT in-flow detection is required, and step 104 is executed at this time.
[0041] Step 103: When the first entry is successfully matched, the first message is forwarded externally according to the execution action corresponding to the message filtering rule, where the execution action is an action of filtering the IFIT instance.
[0042] In this step, in addition to recording the message filtering rule, the first table entry also includes an execution action to facilitate subsequent processing of the first message. For example, when the execution action is to filter the IFIT instance, it can be directly determined that the first message does not need to undergo IFIT detection using the detection method indicated by the IFIT instance, and the first message can then be forwarded externally.
[0043] Step 104: When the match with the first table entry fails, the first message is matched with the second table entry, where the second table entry is an entry bound to the IFIT instance and includes a message rule requiring IFIT detection.
[0044] In this step, when the first message fails to match the first table entry, it indicates that the first message needs to be subjected to IFIT detection. Specifically, each IFIT instance corresponds to a detection method, and the IFIT instance also corresponds to a target flow, and different IFIT instances correspond to different target flows. When IFIT detection is required for the service message obtained based on the detection interface, which IFIT detection is to be performed specifically can be determined based on the table entry corresponding to the IFIT instance, that is, a table entry is generated for each IFIT instance, and the table entry can be generated based on the target flow corresponding to the IFIT instance. Specifically, feature extraction can be performed on the target flow, and then corresponding message rules can be created based on the features of the target flow, and then the table entry corresponding to the IFIT instance can be constructed based on the created message rules.
[0045] On this basis, when the first message fails to match the first table entry, the table entry corresponding to the IFIT instance bound to the detection interface can be obtained. For the sake of description, the obtained table entry is recorded as the second table entry. In this way, the head node can match the first message with the second table entry.
[0046] Step 105: When the first message is successfully matched with the second table entry, the first message is encapsulated with a destination option extension header to obtain a second message, and the second message is used for IFIT detection.
[0047] In this step, when the detection interface is bound to multiple IFIT instances, since each IFIT instance corresponds to a second table item, when matching, the table item matching can be performed according to the matching order between the IFIT instances. When the second table item of the target IFIT instance is successfully matched, the table item matching of other IFIT instances is no longer performed, and the first message is directly encapsulated with the destination option header (DOH). The DOH header is used to indicate that the second message needs to be IFIT detected. That is to say, when the analyzer in the network where the head node is located performs IFIT detection, it will only count the messages with the DOH header, and will not count the messages without the DOH header. In this way, since the first message that hits the first table item is directly forwarded, and since the first message is not encapsulated with the DOH header, the analyzer will not count the first message. In this way, the problem of inaccurate statistical results caused by the analyzer counting all messages when performing IFIT detection is solved.
[0048] Specifically, when encapsulating the DOH header for the first message, the flow identifier of the target flow corresponding to the IFIT instance of the IFIT detection to be performed can be encapsulated, so that when the subsequent analyzer performs IFIT detection, it can perform the corresponding IFIT detection based on the flow identifier in the DOH in the second message.
[0049] It should be noted that the matching order between each IFIT instance can be determined according to the priority of each IFIT instance. For example, the table item matching of the IFIT instance with a higher priority is executed first, and for the IFIT instance with a lower priority, the matching of the second table item of the IFIT instance with a lower priority is implemented only when the second table item of the IFIT instance with a high priority fails to match. Thus, the matching order between each IFIT instance is constituted.
[0050] It is worth noting that the multiple IFIT instances bound to the detection interface correspond to different detection methods. For example, the current detection methods include, but are not limited to, quintuple-based detection, locator-based detection, policy-based detection, APNID-based detection, etc. Accordingly, a corresponding target flow and IFIT instance are generated based on the different detection methods, and then a second table entry corresponding to the IFIT instance is generated based on the target flow.
[0051] It should be noted that different detection methods correspond to different types of second table entries. For example, for a detection method based on a five-tuple, the second table entry generated is an access control list (ACL), while for a detection method based on a locator, the second table entry generated is an NQA Identity table entry. For a detection method based on a policy, the second table entry generated is an SRv6 slice table entry (a table entry at the forwarding layer), and for a detection method based on an APNID, the second table entry generated is an IPv4 Tunnel End table entry. In actual applications, the method for generating table entries for each detection method can adopt currently existing technical means, and this embodiment does not limit this.
[0052] In addition, after generating the second table entry corresponding to each IFIT instance, the second table entry can be enabled for subsequent IFIT detection. Specifically, the head node may include a control layer, a forwarding layer, and a driver between the control layer and the forwarding layer. The control layer is provided with an upper-layer platform, and the forwarding layer is provided with a network chip, which has microcode. On this basis, the upper-layer platform generates a unique flow identifier for the target flow of each IFIT instance to identify the target flow corresponding to the IFIT instance. Afterwards, the upper-layer platform obtains the message rules based on the target flow corresponding to the IFIT instance, and the upper-layer platform can send the relevant information of the IFIT instance to the driver. The relevant information of the IFIT instance can include, but is not limited to, the flow information of the target flow, the instance information of the IFIT instance, etc. The instance information of the IFIT instance includes the detection method. After receiving the above-mentioned relevant information, the driver can generate the corresponding second table entry based on the detection method and message rules supported by the IFIT instance, and send the second table entry to the network chip so that the network chip can locally record the IFIT instance and the second table entry included in the detection interface.
[0053] In addition, the instance information of the above IFIT instance also includes a detection period, so that IFIT detection is performed in the detection mode indicated by the IFIT instance within the corresponding detection period.
[0054] Furthermore, each detection interface is bound to an IFIT instance by configuring the IFIT service in the instance view mode to bind the detection interface to the corresponding IFIT instance. The upper-layer platform and driver then collaborate to implement the aforementioned process of generating and distributing the second entry for the IFIT instance.
[0055] It should be noted that the traffic characteristics of the target flow configured by the IFIT instance may include quintuple, VPN, DSCP and other characteristics. In addition to the above characteristics, different target flows may also include other characteristics, such as characteristics that support corresponding detection methods, etc.
[0056] Step 106: When the match with the second entry fails, the first message is forwarded externally.
[0057] In this step, when the detection interface is bound to one IFIT instance, if the first message fails to match the second table entry corresponding to the IFIT instance, since the second table entry of each IFIT instance is generated based on the target flow of the IFIT instance, when the first message fails to match, it indicates that the message characteristics of the first message do not match the characteristics of the target flow. In this way, there is no need to perform IFIT flow detection on the first message based on the IFIT instance. Based on this, the head node can directly forward the first message to the outside.
[0058] When the detection interface is bound to multiple IFIT instances, the first message may be forwarded externally when the first message fails to match the second table entry corresponding to each IFIT instance.
[0059] It should be noted that in addition to implementing the message processing method provided in any embodiment of the present application, the head node itself may also provide other business services. Therefore, if it is necessary to perform related operations of other business services on the first message, it is necessary to perform these related operations first and then forward the first message externally.
[0060] In the message processing method provided in the present application, when the detection interface bound to the IFIT instance in the head node obtains the first message, the first table item configured on the detection interface is obtained, and the first table item includes the message filtering rule; the first message is matched with the first table item; when the match with the first table item is successful, the first message is forwarded externally according to the execution action corresponding to the message filtering rule, and the execution action is the action of filtering the IFIT instance; when the match with the first table item fails, the first message is matched with the second table item, and the second table item is the table item bound to the IFIT instance, and the second table item includes the message rule that requires IFIT detection; when the match with the second table item is successful, the first message is encapsulated with the destination option extension header DOH to obtain a second message, and the second message is used for IFIT detection; when the match with the second table item fails, the first message is forwarded externally.
[0061] By adopting the above-mentioned method, the present application obtains the first table item configured in the detection interface for filtering the messages that do not need IFIT detection. When the detection interface obtains the first message, the first message can be matched with the first table item, and the first message that hits the first table item can be directly forwarded, thereby achieving the purpose of filtering the messages that do not need IFIT detection; in addition, when the first table item is not hit, the second table item corresponding to the IFIT instance bound to the detection interface can be obtained, and DOH encapsulation processing can be performed on the first message that hits the second table item, so that when the IFTI detection is performed subsequently, only the second message encapsulated with DOH is detected. In this way, not only the purpose of filtering out the messages that affect the flow detection results is achieved, but also the workload of troubleshooting when a network failure occurs due to the failure of the flow detection result is reduced. That is, the problem of inaccurate statistical results caused by the analyzer counting all messages when performing IFIT detection is solved.
[0062] Optionally, in this embodiment, when generating the above-mentioned first table item, this embodiment introduces a modular quality of service configuration (MQC) strategy. On this basis, the first table item can be generated based on the above-mentioned MQC strategy according to the following process: parsing the MQC policy configured for the detection interface; obtaining the packet filtering rule from the class classifier in the MQC policy, and obtaining the execution action from the behavior behavior in the MQC policy; generating the first table item according to the packet filtering rule and the execution action.
[0063] Specifically, the operation and maintenance personnel can apply the MQC policy on the above-mentioned detection interface, and take the first table item generated as an MQCACL table item as an example. In this way, after detecting the application event of the above-mentioned MQC policy, the head node can parse and process the MQC policy. Since the MQC policy includes a class classifier and a behavior behavior, the class includes the message filtering rules written by the operation and maintenance personnel, and the behavior includes the execution action written by the operation and maintenance personnel. Based on this, the head node can obtain the above-mentioned message filtering rules and execution actions from the class and behavior respectively, and then generate an MQC ACL table item based on these two contents. Specifically, the message filtering rules can be used as the keyword key of the above-mentioned MQC ACL table item, and the execution action can be used as the result of the MQCACL table item to construct the MQC ACL, and the execution action is the action of filtering the IFIT instance.
[0064] It should be noted that the packets that need to be filtered are different, and accordingly, the packet filtering rules are also different. Accordingly, the above-mentioned MQC ACL table items can include filtering rules corresponding to multiple packets that need to be filtered, and can be configured according to actual conditions. For example, for tracert packets and ping packets, the packet filtering rules can be configured based on the protocol type. The protocols of these two packets are different, and filtering can be based on the protocol type. In addition, the tracert packet also includes the time to live (ttl), which is a proprietary feature of the tracert packet. Therefore, the packet filtering rules of the tracert packet can also include the time to live feature. In addition, it is necessary to distinguish between the packets that need to be filtered and the packets that need to be tested by IFTI, and configure the packet filtering rules based on the distinction.
[0065] Optionally, when matching the first message with the first table entry, a solution is provided that takes the IFIT instance into consideration. That is, in this embodiment, the first table entry also includes a flow identifier for the first target flow in the specified IFIT instance. For ease of description, the flow identifier can be referred to as flowID. Based on this, step 102 can be performed according to the following process: when the first message matches the message filtering rule, the flow identifier corresponding to the message filtering rule is obtained; a second table entry corresponding to the specified IFIT instance corresponding to the flow identifier is obtained; if the second table entry includes the flow identifier, it is determined that the match with the first table entry is successful.
[0066] Specifically, in order to avoid filtering out messages that require IFIT detection and affecting the IFIT flow detection results, this embodiment proposes to include the flowID of the target flow corresponding to the specified IFIT instance in the first table entry. The specific instance of the specified IFIT instance can be configured according to actual conditions, and this embodiment does not limit this.
[0067] On this basis, when the message characteristics of the first message match the message filtering rules in the first table item, the flowID is obtained from the first table item. Since different target flows correspond to different flowIDs, and the target flows configured in each IFIT instance are different, the corresponding IFIT instance, i.e., the above-mentioned specified IFIT instance, can be found based on the flowID. Then, the second table item corresponding to the specified IFIT instance can be obtained. The keyword of the second table item is the flowID of the target flow corresponding to the IFIT instance. Therefore, it can be determined whether the flowID extracted from the first table item is consistent with the keyword in the second table item. If they are consistent, it once again indicates that the first message does not need to perform the corresponding flow detection of the specified IFIT instance, that is, it indicates that the match with the first table item is successful, and then the first message can be forwarded. If they are inconsistent, it indicates that the match with the first table item failed, and step 104 is executed.
[0068] Furthermore, when generating a first table entry including a flowID, the step of generating the first table entry according to the message filtering rule and the execution action can be performed according to the following process: when the execution action in the behavior of the MQC policy is an action to filter the target IFIT instance, the flow identifier of the second target flow corresponding to the target IFIT instance is obtained; and the flow identifier of the second target flow is written into the first table entry.
[0069] Specifically, taking the target IFIT instance as the designated IFIT instance and the first entry as an MQC ACL entry as an example, to enable matching of the first message based on the designated IFIT instance, an action to filter the designated IFIT instance can be configured in the MQC policy's behavior. This allows the head node to not only obtain the message filtering rules and execute the action when parsing the MQC policy, but also obtain the instance identifier of the designated IFIT instance. Furthermore, based on the target flow corresponding to the designated IFIT instance, the head node can obtain the flowID of the target flow and then write the flowID into the MQC ACL entry.
[0070] Furthermore, in this embodiment, the first table entry may further include an IFIT field. On this basis, the following process may be performed: the value of the IFIT field is set to indicate that the query times of the first table entry is a set number.
[0071] Specifically, in actual applications, when the microcode performs message matching, the first table entry may need to be searched a set number of times. Therefore, to facilitate the microcode obtaining the desired number of searches, the value of the IFIT field in the first table entry can be set to 1. Optionally, the set number of searches can be three. In this way, the microcode can search the first message three times, and the search can be performed with reference to the current query method, which is not limited in this embodiment.
[0072] It should be noted that the second table entry may also include the above IFIT field, so that after the IFIT field is set, it is used to indicate the above set number of times that the second table entry may be queried.
[0073] Optionally, the generation process of the first table entry can be executed by the driver, and Figure 1 The implementation of the shown process can be performed by microcode in the network chip.
[0074] In order to better understand this embodiment, Figure 2 The transmission network (target network) application scenario diagram shown in the figure is used as an example to illustrate. Figure 2 The transmission network in the example includes a head node, several intermediate nodes, a tail node, and an analyzer, which is used to perform IFIT detection. Figure 2 The intermediate nodes included in the transmission network shown may be devices that support or do not support in-flight detection, depending on actual conditions.
[0075] In order to solve the problem of incorrect flow detection results caused by the analyzer performing IFIT detection on all messages passing through each node in the transmission network, this embodiment proposes to perform relevant configuration on the head node so that the head node can perform corresponding processing on the obtained messages according to the message processing method provided in any of the above embodiments of this application.
[0076] Specifically, the head node does not encapsulate packets matching the first entry with a DOH header, but instead directly forwards them to the intermediate node, ultimately reaching the egress node. Packets that do not match the first entry but match the second entry corresponding to the IFIT instance are encapsulated with a DOH header. This DOH encapsulation instructs the analyzer to perform IFIT detection on packets encapsulated with the DOH header. This allows the analyzer to only count packets encapsulated with the DOH header when performing IFIT detection on the head node, ignoring packets without the DOH header. This effectively filters out packets that could affect the results of in-flight detection.
[0077] In addition, since packets encapsulated with a DOH header are also transmitted from the head node to the intermediate and tail nodes, the analyzer only counts packets encapsulated with a DOH header when performing IFIT detection on the intermediate and tail nodes. This can filter out packets that affect the in-flight detection results, thereby ensuring the accuracy of the in-flight detection results.
[0078] Finally, if the packet encapsulated with the DOH header needs to be forwarded externally, the egress node can strip the DOH header from the packet after the analyzer completes the DOH packet statistics on the egress of the egress node to restore the original packet, and then perform packet forwarding processing, thereby not affecting the forwarding of the packet.
[0079] At this point, by applying message filtering rules on the detection interface, it is possible to filter out invalid detection traffic, thereby achieving effective monitoring and management of specific traffic (traffic that requires IFIT detection). Since invalid detection messages are filtered out, when the analyzer identifies a fault during IFIT detection, it reduces the troubleshooting time and provides higher quality services.
[0080] Based on the same inventive concept, the present application also provides a message processing device corresponding to the above message processing method. The implementation of the message processing device can be specifically referred to the above description of the message processing method, which will not be discussed here one by one.
[0081] See also Figure 3 , Figure 3 A message processing device provided by an exemplary embodiment of the present application is applied to a head node in a target network, and the device includes:
[0082] The first acquiring unit 301 is configured to acquire a first table entry configured on the detection interface when the detection interface bound to the IFIT instance in the head node acquires a first message, where the first table entry includes a message filtering rule;
[0083] A first matching unit 302 is configured to match the first message with the first entry;
[0084] a forwarding unit 303 configured to forward the first message externally according to an execution action corresponding to the message filtering rule when the matching result of the first matching unit 302 is a successful match with the first table entry, wherein the execution action is an action of filtering the IFIT instance;
[0085] a second matching unit 304 configured to match the first message with a second entry when the matching result of the first matching unit 302 is a match failure with the first entry, where the second entry is an entry bound to the IFIT instance and includes a message rule requiring IFIT detection;
[0086] an encapsulation unit 305 configured to encapsulate the first message with a destination option extension header DOH to obtain a second message when the matching result of the second matching unit 304 is a successful match with the second table entry, where the second message is used for IFIT detection;
[0087] The forwarding unit 303 is further configured to forward the first message externally when the matching result of the second matching unit 304 is that the match with the second entry fails.
[0088] Therefore, the present application obtains the first table item configured in the detection interface for filtering messages that do not require IFIT detection. When the detection interface obtains the first message, the first message can be matched with the first table item, and the first message that hits the first table item can be directly forwarded, thereby achieving the purpose of filtering messages that do not require IFIT detection; in addition, when the first table item is not hit, the second table item corresponding to the IFIT instance bound to the detection interface can be obtained, and DOH encapsulation processing can be performed on the first message that hits the second table item, so that when IFTI detection is performed subsequently, only the second message encapsulated with DOH is detected. In this way, not only the purpose of filtering out messages that affect the in-flow detection results is achieved, but also the workload of troubleshooting when network failures occur due to failure of in-flow detection results is reduced. That is, the problem of inaccurate statistical results caused by the analyzer counting all messages when performing IFIT detection is solved.
[0089] Optionally, in this embodiment, the first table entry further includes a flow identifier of the first target flow in the specified IFIT instance;
[0090] On this basis, the above-mentioned first matching unit 302 is specifically used to obtain the flow identifier corresponding to the message filtering rule when the first message matches the message filtering rule; obtain the second table item corresponding to the specified IFIT instance corresponding to the flow identifier; if the second table item includes the flow identifier, it is determined that the match with the first table item is successful.
[0091] Optionally, based on any of the above embodiments, the message processing device provided in this embodiment may further include:
[0092] A parsing unit (not shown in the figure) is used to parse the modular quality of service configuration MQC policy configured on the detection interface;
[0093] a second acquiring unit (not shown in the figure), configured to acquire the message filtering rule from the classifier in the MQC policy, and acquire the execution action from the behavior in the MQC policy;
[0094] A generating unit (not shown in the figure) is configured to generate the first entry according to the message filtering rule and the execution action.
[0095] Furthermore, in this embodiment, the above-mentioned generation unit is specifically used to obtain the flow identifier of the second target flow corresponding to the target IFIT instance when the execution action in the behavior of the MQC policy is the action of filtering the target IFIT instance; and write the flow identifier of the second target flow into the first table entry.
[0096] Furthermore, in this embodiment, the first table entry further includes an IFIT field;
[0097] On this basis, the generating unit is further configured to set the value of the IFIT field to indicate that the query times of the first table entry is a set number of times.
[0098] Based on the same inventive concept, an embodiment of the present application provides an electronic device, which can be a head node in the above-mentioned target network. Figure 4As shown, the electronic device may include a processor 401 and a machine-readable storage medium 402. The machine-readable storage medium 402 stores a computer program executable by the processor 401. The computer program prompts the processor 401 to execute the message processing method provided in any embodiment of the present application. In addition, the electronic device also includes a communication interface 403 and a communication bus 404. The processor 401, the communication interface 403, and the machine-readable storage medium 402 communicate with each other via the communication bus 404.
[0099] The communication bus mentioned in the electronic device mentioned above may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.
[0100] The communication interface is used for communication between the above electronic device and other devices.
[0101] The machine-readable storage medium 402 may be a memory, which may include random access memory (RAM), DDR SRAM (Double Data Rate Synchronous Dynamic Random Access Memory), or non-volatile memory (NVM), such as at least one disk storage. Optionally, the memory may be at least one storage device located remotely from the processor.
[0102] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.
[0103] In addition, this embodiment also provides a machine-readable storage medium, which stores a computer program. When called and executed by a processor, the computer program prompts the processor to execute the method provided by any embodiment of the present application.
[0104] As for the electronic device and machine-readable storage medium embodiments, since the method contents involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.
[0105] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.
[0106] The implementation process of the functions and effects of each unit / module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.
[0107] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely schematic, wherein the units / modules described as separate components may or may not be physically separated, and the components displayed as units / modules may or may not be physical units / modules, that is, they may be located in one place, or they may be distributed over multiple network units / modules. Some or all of the units / modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.
[0108] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.
Claims
1. A message processing method, characterized in that: Applied to a head node in a target network, the method includes: When the detection interface bound to the IFIT instance in the head node obtains the first message, obtain a first table item configured on the detection interface, where the first table item includes a message filtering rule; Matching the first message with the first table entry; When the first entry is matched successfully, the first message is forwarded externally according to the execution action corresponding to the message filtering rule, where the execution action is an action of filtering the IFIT instance; When the match with the first table item fails, the first message is matched with the second table item, where the second table item is an item bound to the IFIT instance, and the second table item includes a message rule that requires IFIT detection; When a match is found with the second table entry, the first message is encapsulated with a destination option extension header DOH to obtain a second message, where the second message is used for IFIT detection; When the match with the second entry fails, the first message is forwarded externally.
2. The method according to claim 1, characterized in that The first table entry further includes a flow identifier of a first target flow in a specified IFIT instance; Matching the first message with the first entry includes: When the first message matches the message filtering rule, obtaining a flow identifier corresponding to the message filtering rule; Obtain a second table entry corresponding to the specified IFIT instance corresponding to the flow identifier; If the second entry includes the flow identifier, it is determined that the second entry matches the first entry successfully.
3. The method according to claim 1, characterized in that The method for generating the first table entry is: Parsing the modular quality of service configuration MQC policy configured on the detection interface; Obtaining the message filtering rule from the classifier in the MQC policy, and obtaining the execution action from the behavior in the MQC policy; The first table entry is generated according to the message filtering rule and the execution action.
4. The method according to claim 3, characterized in that Generating the first entry according to the message filtering rule and the execution action includes: When the execution action in the behavior in the MQC policy is an action of filtering the target IFIT instance, obtaining the flow identifier of the second target flow corresponding to the target IFIT instance; The flow identifier of the second target flow is written into the first table entry.
5. The method according to claim 4, characterized in that The first table entry further includes an IFIT field; and the method further includes: The value of the IFIT field is set to indicate that the query times of the first table entry is a set number of times.
6. A message processing device, characterized in that: Applied to a head node in a target network, the device includes: a first acquiring unit, configured to acquire, when a detection interface bound to an IFIT instance in the head node acquires a first message, a first table entry configured on the detection interface, the first table entry including a message filtering rule; a first matching unit, configured to match the first message with the first entry; a forwarding unit configured to forward the first message externally according to an execution action corresponding to the message filtering rule when the matching result of the first matching unit is a successful match with the first table entry, wherein the execution action is an action of filtering the IFIT instance; a second matching unit, configured to match the first message with a second entry when the matching result of the first matching unit is a match failure with the first entry, where the second entry is an entry bound to the IFIT instance, and the second entry includes a message rule requiring IFIT detection; an encapsulation unit, configured to encapsulate the first message with a destination option extension header DOH to obtain a second message when the matching result of the second matching unit is a successful match with the second table entry, wherein the second message is used for IFIT detection; The forwarding unit is further configured to forward the first message externally when the matching result of the second matching unit is that the match with the second entry fails.
7. The device according to claim 6, characterized in that The first table entry further includes a flow identifier of a first target flow in a specified IFIT instance; The first matching unit is specifically used to obtain the flow identifier corresponding to the message filtering rule when the first message matches the message filtering rule; obtain the second table item corresponding to the specified IFIT instance corresponding to the flow identifier; if the second table item includes the flow identifier, determine that the match with the first table item is successful.
8. The device according to claim 6, characterized in that Also includes: A parsing unit, configured to parse the modular quality of service configuration MQC policy configured on the detection interface; a second acquiring unit, configured to acquire the message filtering rule from the classifier in the MQC policy, and acquire the execution action from the behavior in the MQC policy; A generating unit is configured to generate the first table entry according to the message filtering rule and the execution action.
9. The device according to claim 8, characterized in that The generating unit is specifically configured to obtain the flow identifier of the second target flow corresponding to the target IFIT instance when the execution action in the behavior of the MQC policy is an action of filtering the target IFIT instance; and write the flow identifier of the second target flow into the first table entry.
10. The device according to claim 9, characterized in that The first table entry further includes an IFIT field; The generating unit is further configured to set the value of the IFIT field to indicate that the query times of the first table entry is a set number of times.
Citation Information
Patent Citations
Multicast service flow detection method and related device
CN114430386A
Stream detection method and electronic equipment
CN115280745A